[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: Re: merging branches confusion

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-08-16 21:22:44 CEST

> -----Original Message-----
> From: John Calcote [mailto:jcalcote@novell.com]
>
> In all the arguing I've seen on this and the dev list regarding why
> tags should NOT be used as simple aliases for revision
> numbers in SVN, I
> still have yet to see a truly valid reason for this point of view.

        In CVS or ClearCase tags/labels were applied to individual
files. Thus you could move the label/tag on a file by file basis. Yes,
tags/labels should be unchangable, but every so often there's a really
good reason to tweak the label/tag to fix something.
        Being able to _add_ files to a label is useful: label the code,
pull by label, build, and then check-in the build output and apply the
label.

        However, Subversion tags are applied to revisions and revisions
represent a set of files. If a svn tag was an traditional alias/label,
then there would be no way to modify or add files to a tag. Updating a
tag would require changing a revision after the initial commit.
However, since a svn tag is a branch, you can modify the tag branch to
fix or add files to the tag.

It boils down to:
        A lot of concepts that work well for version control systems
that operate on a file-by-file paradigm, are no longer valid (or work
differently) with Subversion's change-set (revisions) approach.
        So far I've seen this file-by-file versus change-set paradigm
change trip up folks in regards to merging, having one global version
number, version trees, and now, tagging.

 
> On the other hand, I hear time and time again about the
> frustration the
> people experience with not being able to use tags as aliases in SVN.
>
> then the least we can do is provide a brand
> new feature called "names" or something.

        How about "labels"?

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. AL622

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 16 21:28:11 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.