Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
2  
Do you commit frequently because you want a remote backup in case something horrible happens to your machine, or just as a safety net in case you want to undo stuff? If safety net, you may as well just install git locally and use that to commit until everything is "ready." You may also be interested in this question Using git within an svn checkout? (without git-svn). –  R0MANARMY Mar 21 '13 at 0:11
2  
You might be looking for this git-svn tutorial - andy.delcambre.com/2008/03/04/git-svn-workflow.html or maymay.net/blog/2009/02/24/… -- the idea being you use git locally (branch and commit all you want), and then push from your local git repo back to svn when ready. –  MichaelT Mar 21 '13 at 2:55
    
@R0MANARMY : it is mainly a safety net. I want to be able to revert some intermediate step if something goes wrong. Anyway, I think I will try the git-svn-worflow mentionned by MichaelT –  georgesl Mar 21 '13 at 8:29
    
@georgesl git-svn is a valid approach, just keep in mind there may be certain SVN operations that don't map very well into git-svn workflow. Also, the article Michael points to is 5 years old, that's a long time for tools to change (and hopefully improve). –  R0MANARMY Mar 21 '13 at 12:46

2 Answers 2

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.

share|improve this answer
    
Although those are valid points, they don't really answer the question. –  R0MANARMY Mar 21 '13 at 0:12
    
@R0MANARMY Ok I shall update. –  Sam Mar 21 '13 at 0:13
1  
Note that you can also have a local svn repository. –  Amy Blankenship Mar 21 '13 at 0:37
    
Additional note: Working on an SVN branch will be noticed, if only because there will be gaps between revision numbers for the check-ins on trunk. Keep this in mind and decide how invisible your intermediate check-ins should be. –  Bart van Ingen Schenau Mar 21 '13 at 7:37

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.