5

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 ?

Improve this question
4
  • 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).
    – Roman
    Mar 21, 2013 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.
    – user40980
    Mar 21, 2013 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
    – lucasg
    Mar 21, 2013 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).
    – Roman
    Mar 21, 2013 at 12:46

2 Answers 2

Reset to default
7

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.

Improve this answer
4
  • Although those are valid points, they don't really answer the question.
    – Roman
    Mar 21, 2013 at 0:12
  • @R0MANARMY Ok I shall update.
    – Sam
    Mar 21, 2013 at 0:13
  • 1
    Note that you can also have a local svn repository.
    – Amy Blankenship
    Mar 21, 2013 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, 2013 at 7:37
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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