> -----Original Message-----
> From: Brad Appleton [mailto:brad@bradapp.net]
> Sent: Friday, March 12, 2004 2:58 PM
> To: Rob van Oostrum
> Cc: users@subversion.tigris.org
> Subject: Re: branching several times a day (was Re: Sourcesafe user
> needs primer on branching source control)
[...]
> > On the other hand, I agree with you in that you shouldn't
> > want to dump changes into the main line of development if
> > the baseline of a private branch is significantly out-of-date.
> > So what I like to do in these cases is setup a temporary
> > integration branch off the main line of development and merge
> > the private branch changes back into this.
>
> Actually - do you need a branch for that, can't you just use a
> separate integration sandbox (with or without a new branch),
> in which case I believe it is basically the same as the
> single-release-point (e.g., machine or sandbox) approach.
That depends. In cases where you want to integrate with the current mainline
of development but don't necessarily want to expose one set of changes to
another set of changes (in cases where 2 changesets have files in common),
using a single integration sandbox will not work. In my particular case,
various sets of changes go into various discrete channels of QA ("will
change A work without change B" and "how about we pull change X out of this
release" are daily occurrances). So I am very serious about keeping
everything nice and seperate. Hence the purpose-built integration branch
model. Only relatively trivial changes - the ones that go on and off my
radar quickly and are unlikely to cause problems - are made directly in the
maintenance branch. In terms of volume, the latter represents the majority
of work. In this particular case, the single release point is the
maintenance branch which is the seed point of most private branches. Since
it is also where most of the work is taking place, it's not always desirable
to do integration there.
In short, I want to control a singular sequence of release, while
safeguarding my ability to change everything around if a client should so
desire.
The trick as it turns out is to just tag everything I do. Always tag the
point from which to merge, the point just before the commit of merge changes
and the point immediately after. On average, I do about a half-dozen
releases a day like this, and there are very rarely any merge conflicts of
any significance. For larger changesets that span more time, there are the
merge conflicts. Whether you choose to deal with this pain in small bits or
all at once depends entirely on the circumstances. I don't think that either
option is right or wrong. It all depends.
> But doing that without the update still gives you a more likely
> to be more stale private branch+sandbox with greater merge and
> reconciliation effort that very often more than offsets the
> disadvantages while at the same time minimizing the likelihood
> and impact of the most significant concerns.
The fact that a branch grows more out of date every day by not being
updated/re-seeded is a calculated risk you take. My primary concern is being
flexible. The less cross-branch 'polution' I create as part of the
day-to-day process, the better. And I still have the option of doing updates
into private branches in those cases where it just makes sense to do so. But
since integration is generally a fairly painless affair for me, I'm rarely
even tempted to go that route ...
> The other solution is to break your task up into "micro-tasks"
> and commit much more frequently in much smaller-sets of changes.
> This can work too, but essentially suffers the same traceability
> problems of the continuous update approach.
Fair enough re. traceability, but I still prefer to keep my branches
"purpose-pure" as much as possible.
I really appreciate this meeting of minds Brad. Have your book on my desk so
I must think you're doing something right ;-)
cheers
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 12 22:41:06 2004