使用SVN定义基于功能的开发的工作流程

Question

I think this problem is general when we work with disconnected version controls like SVN on GIT. I'm coming from Clearcase background where there's an active server and the files are just virtual copies in our system.

If I talk in the clearcase perspective, if more than one people are working for a particular feature, this will be branched out seperately and checked in the particular branch by the developer branch. Once the entire feature is done, it will be merged back to the main branch. Essentially we're not screwing up the main branch by the halfcooked features. Because the others could hurt with the daily build.

The above method is good to go as I've a branch out there in the clearcase server. With disonnected version controls like SVN and GIT, how to solve this problem? Is it required to setup a separate server and share with the developers to accomplish this?

Answer 1

For Git, you don't have to set a separate feature.
You can create as many feature branch as required, and merge them in a non-fast-forward way in order to achieve the same goal.

See " Why does git use fast-forward merging by default? " for more.

SVN can offer the same kind of workflow, except the merge back to the main branch might need a " merge --reintegrate " slightly different than a classic merge (and with a few pending bugs like this one with SVN 1.7).

The difference between the two is regarding the publication of the branches:

• SVN will declare the branch in its central repo, visible for all
• Git users declare their branches in their local repo, can merge back on a main common branch, but choose what they push back to a central repo: only the update common branch with new commits, and/or also their feature branch.

See " this question " for more on the orthogonal aspect introduced by a DVCS (like Git) compared to a centralized VCS like SVN.

Answer 2

You'll want to use the branch concept in Subversion or Git — no need for any separate server. The two systems work radically different:

• Subversion: , you make a foo branch by making a copy from /trunk to /branches/foo . Subversion doesn't really have a notion of a "branch", but since you can merge between folders you can emulate branches that way. This is covered in the SVN book .

• Git: you create a real branch with git branch foo . Branches are first-class citizens in Git and an integral part of how you use the system. Any good Git tutorial will cover branches, please see my link to the Git book.

Answer 3

Followup to Von and Martin

• SVN isn't really fully "disconnected" VCS (as Git or any other DVCS are ), because, at commit-update stage developer's Working Copy (snapshot of some tree from central repo at some moment) communicate with central server and local changes can not be stored in gepo before getting in merging "other changes" (if they appeared before commit attempt)
• "Branch per feature" with more-than-one developers per branch still possible (in SVN-world), even in two slightly different forms:
  1. A direct analogy (and bad workflow ) with CC - each developer can have own personal branch, but during development process they periodically merge other-branches to own (and trunk to branch), all finished branches merged to trunk
  2. Single branch for any amount of developers (common widely used way), svn up is a must before any code-changes in order to get new committed changes from others into local Working Copy (without it changes can not be commited to repository, update+merge on top of own changes can broke code)

In both workflows branches are placed on one central repository, bi-directional data exchange between Subversion repositories is big headache for SVN-admins