The project I am working on is version controlled by SVN, and the unspoken rule at work is to commit only when a new stable feature is added (in order to have a “clean” revision history with no revert) so I work sometimes for a few days without commiting.
However I am kind of a commiting maniac (several commits per day on my previous git projects) and this workflow doesn’t suit me. Ideally I would like to fork the project, commit unstable version under the “submarine repo” and merge into the stable one whenever the feature is stable enough ( my unstable commits must not appear in the stable repo). How can I do this ?
With SVN : I’ve look for Vendor Branches and Externals but I didn’t really find what I want.
With Git : is it possible to use Git on the undercover unstable repo and SVN for the stabilized repo without conflicts between the two CVS during merges ?
4
With Subversion you can operate in a branch which for all intents and purposes will keep incomplete code out of the trunk.
With Git you can operate locally prior to pushing all of your changes to master, or as with subversion you can operate in multiple branches.
The main advantage to using Git over subversion, other than the fact it is a DVCS is that merging is far more trivial than it is with Subversion.
How can I do this ?
Do your development work in a branch for your VCS/DVCS of choice. Only merge back to the trunk when your feature is stable and you’re happy with it.
With Git : is it possible to use Git on the undercover unstable repo and SVN for the stabilized repo without conflicts between the two CVS during merges ?
This question/answer on Stack Overflow shows you how to sync and push Git to Subversion. Hopefully it provides the level of technical detail you need.
4
I would use the patch management tool Quilt. It is very light weight and efficient for making numerous small changes to a large tree, and simple to use.
When it comes time to commit to the big repo you can either apply all the patches and make one big commit, or commit them one by one.
With Quilt you can be a perfectionist, because it is easy to rewrite history. You can navigate up and down the stack of patches and fix your older work, essentially perfecting each patch. If you migrate your patches individually to a version control system, the whole thing then looks like a perfect unit of work. All logically independent changes belonging to that piece of work are in numerous separate patches, and yet there is no evidence that there had been any debugging, since there are no repeated changes to the same piece of code to get it working.