 |
|
 |
|
|
Author |
Message |
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
 Posted: Sun Jul 02, 2006 6:48 pm Post subject: Subversion tags and branches |
|
|
The policy that I have tried to use up until now has been something along the lines:
* Create a tag for every non-development build distributed.
* Create a branch for every now version (branch from the main branch).
* The main branch should always contain the latest stable version.
This has worked fine for me, but I'm not sure how well suited it is when more people start collaborating. Therefor it would be nice to agree upon a policy that should be applied.
I see a couple of weaknesses in the above one. First of all it does not support legacy versions, if someone wanted to for instance continue developing the 1.3.* line then there would be no common branch to use. So maybe branches for every major version (1.3, 1.4,...) that contain the latest stable minor version should be created? Branches should probably also be created for every major change that multiple people might want to collaborate on. It's probably also good if the contents of every version branch is runnable, i.e. no committing half-finished things that break the program to version branches.
I don't have a lot of experience with these kind of policies, so I would appreciate if someone is willing to share. |
|
Back to top |
|
 |
impishfae
Joined: 19 Jun 2006
Posts: 125
Location: Australia
|
| Posted: Sun Jul 02, 2006 11:19 pm Post subject: |
|
|
I've used revision control systems for years, and while you can really use whatever system you want to (everything can be made to work, it's just a matter of degrees of effort!), I'm not sure quite what qualifies as 'best practice'. I certainly wouldn't hold up many of my development environments as ideal. Normal, perhaps, but not ideal.  Google failed to tell me what was best practice too.
What I did find was a number of documents describing branching patterns, which outline the kinds of variant situations under which team development needs to branch. Yes, there's many! For people with time and interest, links are included at the bottom of the page.
Mainly they agreed with your. Branch on a major release, when you will still have development potentially occurring on both forks (new development on trunk, maintenance dev on the branch, periodic merges needing to occur between them). Label/tag for a minor release where no merging is required, but you need to be able to get back to that point if you have to.
The main issue is when you actually go about branching off the maintenance release. There's the more clearcut approach of doing so the moment the new one is out there (ie: the moment 1.4.0 was born, 1.3.10f went to live in a branch), or deferred branching, which has 1.4.0 work occurring in a 'new feature' branch which becomes the trunk when it's stable. The feature branch gets abandoned at that point, and a new branch is created for 1.3.10g to live in, in case of any emergency bugfixes. (This can be a virtual branch: you can get away with tagging it on the trunk and branching only when the emergency bugfix is actually required)
Article: http://www.seapine.com/pub/papers/SCMBranchingModels.pdf
Responses to article: http://csdl2.computer.org/comp/mags/co/2003/01/r1011.pdf
Configuration Management site. Scroll down, to the section headed: Branching Patterns and their Participants http://www.cmcrossroads.com/bradapp/acme/branching/
Perforce 'best practices': http://www.perforce.com/perforce/bestpractices.html |
|
Back to top |
|
|
impishfae
Joined: 19 Jun 2006
Posts: 125
Location: Australia
|
| Posted: Tue Jul 04, 2006 11:24 am Post subject: |
|
|
A dev mgr friend of mine also reminded me of the old-skool bible, the CVS Book and it's chapter on branching principles:
cvs book linky - go down to the section on "Going Out On a Limb (How To Work With Branches And Survive)" |
|
Back to top |
|
|
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Mon Aug 28, 2006 7:30 pm Post subject: |
|
|
This is how things currently look: From the trunk a "1.4" branch exists in "branches/clients". "1.4.0" branches from the "1.4" branch. Every release is tagged.
The trunk holds the latest released version. The "1.4" branch holds the latest 1.4 version. The "1.4.0" branch holds the latest release of 1.4.0. Any work on 1.4.0 (such as 1.4.0a) is done in that branch. When it is released the changes are merged to 1.4 and also to the trunk if 1.4 is the latest major version. The branches were created in a bit of a hurry, so they will probably have to be reworked, please point out flaws. |
|
Back to top |
|
|
|
|
