I am going to be implementing a similar scheme here. I come from a
ClearCase background where it happens essentially automatically with a
trivial configspec.
The one issue I am trying to sort out is uplevelling after the branch
has been done. That is, if the branch is made from revision 100 (for
example) and the fix takes a while, the developer will want to uplevel
from revision 100 to 110 (again, for example) which basically means
merging from 110 into the branch. If the entire tree is branched then
the merge from 110 will merge *all* the intermediate changes into the
developer's branch which is not the right thing to do. The answer to
this is svn switch where you switch only the subset of files you are
working. An svn update should update all non-switched files to the
latest trunk revision without merging, with the developer then having to
merge the trunk into the branch to resolve files changed both on the
developer branch and between revs 100 and 110. Does this seem right so
far?
One concern I have is that the it is easy to forget to svn switch a file
before editing it so that you inadvertently edit a trunk file instead of
branching first. ClearCase handles this by forcing a switch before the
file can be edited (hard to explain if you dont know clearcase). I am
sure I can write a script to make it easier but I am not sure how I can
remove the risk of inadvertent trunk editing.
How do people handle this?
On Thu, 2004-03-04 at 14:18, Jim Nutt wrote:
> On Thu, 4 Mar 2004 18:56:41 -0300
> "Luiz Daniel Lapolla" <luiz.lapolla@sfw.com.br> wrote:
>
> > We are considering the adoption of a branch-by-task model:
> > - A new branch (across all files) is created for each Change
> > Request,
> > based on the last stable milestone.
> > - All the development for one CR goes on it's own branch.
> > - After N cicles of testing and bugfixing the branch is scheduled
> > to be
> > merged with it's baseline.
>
> This is the development model we're currently using. Performance seems
> to be good, but we've not really been using SVN long enough to get solid
> numbers.
>
> One caveat is that merging the whole branch back is a bit different than
> in CVS (you have to specify the starting revision of the branch). It's
> not that it's any more difficult, it's just that it's different enough
> that it's easy to make mistakes until you get the hang of it (the first
> few times I did it nearly drove me to distraction). Once you get used
> to it it though, it's not any harder than under CVS and has some
> advantages.
>
>
> --
> jim nutt
>
> home: jim@nuttz.org jabber: jimnutt@jabber.com
> work: jimnutt@vestek.com ms msg: jim@nuttz.org
> pgp id: 1ECBCC78
--
Chris Wein
Software Engineer
Mobilygen Corp.
E-Mail : cwein@mobilygen.com
Phone : 408-869-4035
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 5 19:52:24 2004