[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Recommendations for branch/tag structure for multi-develop

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-03-14 02:24:27 CET

"Jake C" <buddhabuddy@hotmail.com> wrote on 03/13/2006 07:14:04 PM:

> >Personally, I prefer the model that Subversion (and to a much lesser
> >Subclipse) follow. Generally people work on trunk. Development
> >are reserved for special cases such as large or length changes. Release
> >branches are created from trunk and then stabilized by selectively
> >backporting fixes from trunk to the release branch.
> >
> >There are literally a hundred different ways to approach this and they
> >have pluses and minuses.
> >
> >Mark
> Thanks for the kind reply to my mis-placed post... :-)
> So, when you are ready to do a release, THAT is when you branch. Fixes
> ongoing development are both done in trunk, and only fixes related to
> found during testing are integrated back into the release branch.
> The problem we keep running into is that a developer can never work on a

> single task at a time. Something gets started, then another task gets a
> priority bump, and you end up working on THAT for a while. If the
> task involves some of the same files, then all the work on the previous
> needs to be backed up somewhere, the changes reverted, and then start up
> the new task. When it is finished and checked in, all the backed up
> must be copied back to the working copy and then updated to get the
> that was just checked in.
> It just seems so backwards! I thought VC was supposed to REMOVE the need
> do this kind of thing...

It is backwards, and I am not suggesting you do not use Subversion for
this. What I am saying, is that I would make the simple case the rule and
then train the developers on how to manage the exceptions. I would also
give them leeway and assistance in this area. In the example you cited,
the developer should feel free to create a branch on the fly, commit his
work to that branch, and then move back to trunk for the next task. This
is a rough technique that works well:

svn up -rXXX (get WC at one revision. doesn't have to be HEAD, but
certainly can be.) Deal with conflicts if there are any.

svn cp -rXXX url://trunk url://branch -m "Create branch to save work"

svn sw url://branch (Switch WC to new branch)

svn ci -m "Saving work to branch"

svn sw url://trunk (Switch back to trunk)

I do it this way so that the branch creation and commit of work are in
separate commits. This can make merging later easier. You can also make
the branch from your working copy, but then it is all done in one commit.
And you have to revert the changes when you are done, before getting back
on trunk.


Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Tue Mar 14 02:24:40 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.