Multiple Concurrent Changes Using SVN, GIT, and CVS

Question

At work, we are using SVN, CVS, and GIT because there any many projects that were started at various times. Anyway, a common sequence that occurs is as follows:

1. Working on task A, making changes to project
2. Has new task B, some bug or functionality needs to be done on project, independent of task A but may affect same set of files
3. Check in task B
4. Check in task A

Unfortunately, what I do at this time is two maintain 2 working copies of each project. So I can always work on task B from a clean copy. As you can imagine, this is wasteful and also, does not scale well (task C, D, E, etc.)

For each of these versioning systems, are there commands that can help me do the following:

1. "Save" task A, reverting working copy to current repository
2. Work on task B, check in changes
3. "Restore" task A changes back to working copy

Answer 1

svn and cvs don't have any easy built-in ways to do this without creating and managing patch files yourself.

git uses quilt to achieve this (similar to mercurials mq extensions), and it's quite useful

Answer 2

Based on SVN.

You would create a branch off of the trunk for Task A.

Then when you get Task B, you create a branch off of the trunk for this as well.

You switch between the two branches to work on one thing or the other. (This is fairly quick as it only updates the differences)

When one task is finished, you update it with changes from the trunk and merge it back into the trunk.

When the second task is finished, you update it with changes from the trunk (which now contains the other task) and you merge it back in.

Answer 3

Git only

Git encourages you to use branches for this kind of workflows.

Branches are very cheap in git, so you should use them extensively. What you are asking are called "topic branches", and these are nothing more than a normal branch, but dedicated to a given topic (rather than a development state).

With git you should do something like:

$ git clone ...
$ git branch
* master
$ git checkout -b taskA # Start working on task A
$ git branch
master
* taskA
$ <changes on task A>
$ git commit # This "saves" the work done on task A
$ git checkout master # Revert to the last stable state
$ git checkout -b taskB # Start working on task B
$ git branch
master
taskA
* taskB
$ <changes on task B>
$ git commit # "Save" the changes on task B
$ git checkout master # To revert to the last stable state
$ git checkout taskA # To continue working on task A

This will create a history that represents your different "workspaces" with branches:

a -> b -> c # master
            \
              -> d -> e # Topic A
              \
                -> f -> g # Topic B <- HEAD

$ git branch
master
taskA
* taskB

Once you have this history, you can merge your changes back to master (the stable branch) and then push your master branch to the central repository.

This scheme is very useful, because you can work on any topic branch without needing multiple workspaces and you can work at any given time on any given topic, always keeping your history of changes.

You can make changes to the same files in different branches, when merging a branch into another, git will try and merge the changes made to the files. If there's a conflict because you changed the exact same line on two different places, then git will notify you to solve that particular conflict.

Also, you may check git stash to see how to save temporal changes that can't be committed at the moment.

Read Branching Workflows chapter from Pro Git for more information.