On Mon, 2006-11-20 at 15:18 -0500, John Rouillard wrote:
> >
> > But I suspect there are things you just can't do with a tag - I just
> > want to know what they are.
>
> How about cherry pick multiple files at different revisions without
> going crazy? See any of my prior emails/use cases on the issue.
If you create the tag from a workspace instead of a revision
you can tag exactly what you want.
> The problem with SVN's tags as I see it is that it defies common
> understandings of space/time. Space is branches - different lines of
> development, different files in a tree etc. It is the "name" or
> location of the object you are working on. All can be handled by a
> url.
>
> Versions/revisions always occur along the time axis not the space
> axis. SVN even recognizes this by allowing date or revision numbers as
> the parameter to the -r flag. SVN just doesn't follow through on it
> preferring to use space (a tag) to define a point in time (release of
> a portion of a tree) rather then supplying a true time only based
> mechanism for identifying revisions of a given file or compatible
> revisions of a set of files.
But, there is no reason to think that the set of files you want
to tag ever existed (without concurrent changes you don't want)
at any repository revision. That is, there will be a point where
you commit your last change and have exactly the state you want
to tag. Meanwhile other changes you don't want to include until
the next tag may have been committed before yours. In CVS you
expect this and you expect tags to identify the state of a workspace
at the time the tag is created because there is not even a concept
of repository revisions. Subversion seems to offer an appearance
of time-sequence order in the repository but no way to really get
what you want when concurrent changes are possible except in
a workspace or by making a branch no one else will ever use. And
creating a branch just to hold what you want in a tag seems like
overkill when they are fully equivalent.
> That is IMHO the crux of the issue and will continue to be until some
> more natural/orthoginal mechanism for identifying revisions of files
> that should be treated as a single entity is devised.
Copying a workspace to a tag is as natural as it gets if you are
trying to identify exactly that set of files and particularly if
you are making the last change and committing it because it may
be impossible to identify that exact set any other way. Assuming
that you don't forget to commit before the copy, what subsequent
problems are likely?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 20 22:19:35 2006