"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
extent
> >Subclipse) follow. Generally people work on trunk. Development
branches
> >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
all
> >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
and
> ongoing development are both done in trunk, and only fixes related to
bugs
> 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
earlier
> task involves some of the same files, then all the work on the previous
task
> needs to be backed up somewhere, the changes reverted, and then start up
on
> the new task. When it is finished and checked in, all the backed up
files
> must be copied back to the working copy and then updated to get the
stuff
> that was just checked in.
>
> It just seems so backwards! I thought VC was supposed to REMOVE the need
to
> 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.
Mark
_____________________________________________________________________________
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