Couple things about this that I find quite scary ...
First of all, I take issue with the "let's make tool Y work like tool X"
mode of thinking that I've been seeing in various threads. I would
personally lean towards getting the most out of SVN rather than trying to
make it a ClearCase you don't have to pay for. Or: use SVN in the way it's
been designed and don't try to hack it into something it's not designed to
do (well).
To address your scenario, I spent some time as a ClearCase admin, and I
remember the concept of re-seeding a branch. IIRC, this basically re-built
the branch so that it ended up as having been seeded at the new branch point
all along, meaning the merge is done BEFORE any of the changes you made on
that branch. This is a nifty feature, but neither CVS nor SVN support this.
As a result, when you re-seed the branch to bring it's codebase uptodate
with the trunk, and you add changes to make the merge work, you end up with
2 batches of changes on your branch: all changes made from the top of the
branch to right before you committed the merge, and all changes between
right after the commit of the merge until the latest on the branch. IMO this
pollutes the branch since the merge changes have nothing to do with the
changes that the branch was created for in the first place, and you'll have
to somehow document the fact that you can't just grab the top and bottom of
the branch, do a diff, and know what changes are associated with that
branch.
What we do is this: the trunk is not used for any direct change work. All
maintenance is done on one branch, except when a set of changes is thought
to take too long for it to be in the way of other changes. In that case, a
branch is created off the maintenance branch. When the work is done on that
branch, the changes made on that branch are merged back into the maintenance
branch. If the integration work is thought to be significant, an integration
branch is spawned from the latest on the maintenance branch, the changes on
the work branch are merged back into the maintenance branch, and after
integration is complete all changes from the integration branch is merged
back into the maintenance branch. That way all work stays isolated in its
own little space, and you get around the issue of not being able to re-seed
a branch like you would in ClearCase ...
just my .02
Rob
> -----Original Message-----
> From: Chris Wein [mailto:cwein@mobilygen.com]
> Sent: Friday, March 05, 2004 1:52 PM
> To: users@subversion.tigris.org
> Subject: Re: Branching models
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 5 20:17:17 2004