Another issue with tags is that in some cases with CVS I ended up
moving a tag to a different version of a file. For example, we'd tag a
release, put it in test, discover a stupid configuration issue, fix it,
move the tag to the new version of that one file, and then put a new build
in test based on the revised tag.
I guess with Subversion this would be a merge operation, where you
merge the change on the one file in the trunk into the copy living in
tags/, which means AFAICT that "tag" is actually now a "branch" living in
the "tags/" directory. It's a little unpleasant, compared to just moving
the tag "marker" on the file itself like you would in CVS.
At any rate, perhaps we should just dispense with "tags/" and put
all copies under "branches/" (or "copies"!). But I digress.
Aaron
On Fri, 24 Sep 2004, David F. Newman wrote:
> On Fri, 2004-09-24 at 10:55, Brad Appleton wrote:
> >
> > A similar idea would be allowing a symbolically-named "alias"
> > for a global revision number. It would just be a mapping
> > (without creating a copy for each one -- however cheap it may be)
> > that would "macro-expand" into the corresponding revnum.
> >
>
> If a copy of a file in subversion is equivalent to a hard link in unix,
> then ultimately the only thing being added to the repository is the text
> representing the new URL. In my mind that is equivalent to a tag in
> CVS, just some extra text attached to a file. Albeit, much longer text,
> but that is why I store my URLs in short environment variables, such as
> ${M}
>
> -Dave
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 24 17:37:08 2004