> -----Original Message-----
> From: Brad Appleton [mailto:brad@bradapp.net]
> Sent: Friday, March 12, 2004 7:24 PM
> To: users@subversion.tigris.org
> Subject: Re: branching several times a day (was Re: Sourcesafe user
> needs primer on branching source control)
[...]
> > 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.
>
> I guess I had the impression that this was happening for
> me automatically with SVN by virtue of its change-sets and
> repository-wide versioning (tho with a numeric rather than
> symbolic identifier). What am I missing about how change-sets
> work in SVN and how they can be referred to (even when the
> branch they might have been created in may be obsoleted/removed)?
You're absolutely right and you're not missing a thing. Actually we're still
on CVS at the moment ;-) Large projects for large clients tend to not like
radical change too much ... SVN right now is being piloted small-scale and
we'll phase it in eventually I'm sure.
SVN does give me that numerical repository-wide versioning which eliminates
the necessity of tagging, provided you document which revision number has
what meaning. With SVN's cheap copy scheme, I see no compelling reason not
to create meaningful tags just as you would in CVS as a way of
documentation. Assuming the changeset is always encapsulated in a single
repository revision, with SVN, there is no need for pre-change tagging.
However, developers - *gasp* ;-) - don't always get things right on the
first try, so to allow for that contingency, I think I would still prefer to
keep the pre-change tag in all cases just to be consistent. I might take
advantage of the PREV revision argument in cases where the change is limited
to a single revision. Just have to figure out what the overhead is for my
script to check for for a tag and use PREV if it doesn't exist.
cheers
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 15 16:40:35 2004