What is User-Based Versioning?

A better version control system than Git

In a user-based version control system, changes are tied directly to individual users rather than branches. Each user has their own isolated workspace where they make and track their changes. Instead of creating multiple branches for each task or feature, users apply context tags to their work, which act as lightweight markers to organize their changes.

User version control unburdened by what has been

How User-Based Versioning with Context Tags Works

The core concept of user-based versioning revolves around simplicity and flexibility. Here’s how it can work in practice:

1. User Workspaces: Each developer works in their own private workspace, where all changes are attributed to them. This eliminates the need for constant branch switching or creation.
2. Context Tags: Instead of creating separate branches, developers apply context tags to their work. These tags represent different purposes, such as “Feature A,” “Bug Fix 101,” or “Release v1.2.” Context tags allow users to separate and organize their work without needing to fragment the codebase into multiple branches.
3. Unified History: The user’s entire change history is unified in their workspace. Instead of reviewing different branch histories, users can filter their changes by context tags to see their work on specific features or fixes.
4. Collaboration: When ready, a user’s context tag (e.g., “Feature A”) can be merged into the main codebase. This process is similar to merging branches, but because tags are lightweight, there is less complexity involved in the merge, and fewer conflicts are likely.
5. Parallel Development: Users can apply multiple context tags within the same workspace. For example, a developer might be working on both “Feature A” and “Bug Fix 101” simultaneously. Instead of switching branches, they simply tag their changes accordingly.

Why Context Tags Are Simpler than Branches

Now you might be wondering: How are context tags any different from branches? Let’s dive into the key benefits of user-based versioning and why context tags offer a more streamlined alternative to traditional branching.

1. No Branch Switching

With traditional branches, developers must switch contexts by moving between different branches. This can lead to confusion, especially when developers forget to switch back or mistakenly make changes on the wrong branch. In a user-based version control system, there’s no need to switch branches. All work is done within a unified workspace, and context tags allow you to segment and filter changes by task without leaving your workspace.

2. Less Overhead

Creating, managing, and merging branches takes time and effort. For each new feature or bug fix, developers must explicitly create a new branch and track its state. Over time, this can lead to “branch sprawl” where the repository becomes cluttered with short-lived or abandoned branches. Context tags are lightweight and tied to the user, meaning you can easily create and discard tags without impacting the repository structure.

3. Granularity Without Fragmentation

Branches offer a certain level of granularity for different development tasks, but they also fragment the codebase. User-based versioning with context tags allows for the same level of granularity without the fragmentation. Tags provide a flexible way to organize your work without duplicating the entire repository.

4. Parallel Workflows

Developers often need to work on multiple features or fixes simultaneously. With branch-based systems, this requires creating separate branches for each task and switching between them. In user-based versioning, developers can simply apply different context tags within the same workspace. This allows for easier parallel development without constant context switching or branch juggling.

5. Unified and Streamlined Collaboration

Collaboration in traditional version control systems often involves merging branches, which can lead to conflicts, especially when multiple developers are working on the same feature or fix. In a user-based system, collaboration is simplified by tagging changes for specific purposes. Merging happens based on context tags, and because the changes are more localized, conflicts are minimized.

A Use Case: Small Teams and Real-Time Collaboration

For small teams, user-based versioning with context tags offers a lightweight solution that reduces the overhead of managing multiple branches. Each team member can focus on their work without worrying about creating new branches for every small task. Moreover, in real-time collaboration systems (think of a Google Docs-style development environment), context tags would be perfect for organizing changes without needing to fragment the codebase with branches.

Challenges and Considerations

Of course, like any new workflow, user-based versioning with context tags comes with some challenges:

• Tooling: Adapting existing tools like Git to support user-based version control would require significant changes. Teams would need to invest in or develop new tools that can handle context tags effectively.
• Scalability: While user-based versioning simplifies workflows for small teams, managing context tags across larger teams may require more coordination to avoid overlap and conflicts between tags.

The Shift from Commits to Continuous Save States

In this new system, instead of making explicit commits, the system would automatically track and save your changes in real-time. This would operate much like how Google Docs handles document changes:

• Automatic Checkpoints: Every change made in a user’s workspace would be automatically saved as a “checkpoint.” These checkpoints would be the equivalent of commits, but without the need for the developer to explicitly declare them. They would happen behind the scenes, every time a significant change is detected (e.g., after a function is edited, a file is updated, etc.).
• Version History by Context Tags: Instead of relying on a commit history, changes would be attached to context tags. The system would group changes into these tags, allowing you to trace the evolution of “Feature A” or “Bug Fix 101” through its various checkpoints. Essentially, you could view the “commit history” of a tag, but it would be more fluid and organized automatically by the system.
• Granularity: Since every change is captured as a checkpoint, there would be a fine-grained history of modifications. You wouldn’t need to worry about forgetting to commit; all changes would be saved and tracked continuously.

How the System Works Without Commits

1. Continuous Snapshotting: As a developer works, every file modification is automatically saved as part of a continuous history. These snapshots are the granular units of change. This could be done intelligently, such that meaningful changes (e.g., adding/removing lines, renaming variables, etc.) are captured, while insignificant changes (e.g., navigating around the codebase or adding whitespace) are not.
2. Tagging Changes: Developers would use context tags to categorize their work instead of committing at specific milestones. For instance, if a developer is working on a new feature, they would assign a tag (e.g., #feature-login-ui) to the set of changes. Behind the scenes, the system is continuously saving every change tied to the relevant context tag. This way, each context tag creates a collection of related modifications, much like a branch would in traditional Git, but without the need for commits.
3. Automatic Aggregation: The system aggregates changes under each context tag in real-time. Once the feature or fix is complete, a developer can review all the changes grouped under that context and “publish” them to the main codebase. No commits are necessary since every change has already been tracked. Instead, the system creates a bundle of modifications tied to the tag that can be reviewed or merged in.
4. Version History by Tag: Developers can view the history of a tag to see all the checkpoints or snapshots that were made under that tag. This allows them to trace back through changes (similar to going through a commit log), but in a more fluid, automatic way.

Advantages of Eliminating Commits

1. Reduced Developer Overhead: Developers no longer need to think about when or how to commit. Every change they make is continuously tracked, meaning they can focus on coding rather than managing the version control system.
2. Finer Granularity: Traditional commits are often arbitrary points in the development process, depending on when the developer decides to commit. In a continuous system, every meaningful change is captured, providing finer granularity and more precise tracking of changes.
3. More Fluid Workflow: Context tags allow for seamless switching between tasks without the need to branch or commit. The system tracks everything in the background, automatically organizing changes by context, so developers don’t have to break their flow.
4. Better Collaboration: Without commits, collaboration becomes easier. Developers can see real-time progress on features without waiting for others to commit their work. This is particularly beneficial in fast-moving environments where developers frequently collaborate on the same features.

Handling Rollbacks and Code Review

1. Rollback by Snapshot: In the absence of commits, rollbacks would happen based on snapshots. A developer could choose to revert to any point in time or any specific change made under a context tag. This is more granular than reverting commits because you can choose a specific change within the context of a task.
2. Code Review: Since every change is tagged and tracked continuously, reviewers could review changes by context tag. Instead of reviewing a single commit or PR, they could review all the changes tied to a specific feature or bug fix context. The system could allow for batch reviews of snapshots, similar to how commit diffs are currently reviewed.

Challenges of a Commit-Free System

1. Tooling: Existing version control systems like Git would need significant modifications or alternatives developed to support this new paradigm. Tooling would need to support continuous snapshotting, context tagging, and real-time collaboration.
2. Scalability: Continuous snapshots could potentially create a large volume of data, especially for complex projects with many small changes. However, intelligent storage systems that only capture meaningful deltas (changes) between snapshots could mitigate this.
3. Developer Buy-In: Developers are used to the concept of committing code, and some may find it difficult to transition to a commit-free system. However, the continuous tracking and ease of use could make this change attractive once the benefits are experienced firsthand.

Conclusion

User-based version control with context tags presents a fresh approach to version management that simplifies workflows, reduces branch overhead, and offers a more intuitive way to manage code changes. By keeping all work within a user’s personal workspace and applying lightweight context tags, developers can streamline their development process without sacrificing granularity or flexibility.

For teams looking to reduce complexity and improve collaboration, user-based versioning could be the next evolutionary step in version control. While it may not completely replace traditional branching workflows for every scenario, it offers a compelling alternative for those seeking simplicity and efficiency in their day-to-day coding.