Well...I just checked through the e-mails regarding
this thread, and would like to say that I do agree
with those seeking to change the TAG, and I do
understand those not wanting it changed. However...
In the original e-mail, David Gómez
<david@pleyades.net> said:
"Tags should be more simple than that, just like
revision keywords PREV, HEAD, BASE and COMITTED, a
mapping from a literal to a revision number."
I agree with this 100%. It is one thing that I rather
like about CVS. Since SVN uses the 'svn copy/branch'
mechanism to perform the tag, I thus have to eat a
whole revision number plus the size of the trunk head
in disk/db space for each tag. If the above were true,
then a tag would not use a new revision number, nor
would it cause use of more disk/db space.
BTW - the operation for the above should be
implementable at the same cost level as the 'svn
copy/branch' in its worst case.
While my project is not large, for large projects this
could mean eating space at an incredible amount,
especially if they had to create as many tags as some
of you are saying, and I, for one, would find that
unacceptible for such a project. (FYI - I do love
SVN.)
As to the 'flat file' comment, would the 'property'
suggestion fix that? And to searching them, why force
the user to create a TAG directory? One solution could
be to have a directory called "TAG" that would list
them, or perhaps create a separate list function to
list just the tags assocated with a specific branch.
Yes, there are the issues mentioned about name
conflicts, which would have to be resolved. Perhaps by
tying in some extra data (username, groups, etc.), and
giving the admin the ability to override the name (so
they could create a simple REL_1-0 instead of
admin_REL_1-0) would solve that too.
Any how...just some thoughts, and show of support for
making an easier and less overhead for a tag. It is
certainly something that should be thought about
before implemented, but I, for one, think it should be
implemented in some manner better than it currently
is. (Its current implementation is probably good
enough given the relative newness of SVN, but in the
long run, it probably needs to be changed over.)
And thanks for the great product - SVN.
Ben
--- Tim Hill <tim@realmsys.com> wrote:
> Yes, you can do some pre-commit "magic", but I think
> it's still somewhat
> out-of-band. Don't get me wrong: the branch
> mechanism in SVN is
> admirable, but overloading its use for labels is
> somewhat odd.
>
> Would labels have to be a flat list? Why shouldn't I
> be able to label a
> directory? At this point, a label looks an awful lot
> like a directory
> property to me ("svn:label" ???). In fact, the only
> real change needed
> in SVN itself would be to allow revision numbers to
> be specified using
> labels, so, for example:
>
> svn co URL -r !MYLABEL!
>
> ...would checkout the revision implied by the label
> (I made up the silly
> syntax, substitiute as desired).
>
> I can see several uses:
> 1. Eliminate need for "trivial" tags. Tags are good
> for major
> milestones, where the visibility is a plus. But for
> every build?
> 2. Eliminate out-of-band data. If I equate SVN
> revisions to builds, then
> tracking build numbers to revision numbers is of
> course trivial. But
> many shops have build processes that are not so
> simple, and as a result
> must track revision number to build number
> histories, creating YASLDF
> (Yet Another Silly Little Data File). Far better to
> use labels and keep
> everything within a single reference point -- SVN
> itself.
>
> ...and after all, we already have extensions to the
> "pure" revision
> number model for dates, so why not labels?
>
> --Tim
>
> Johan Appelgren wrote:
>
> >
> ><snip>
> >
> >Are aware that you can use a pre-commit hook to
> make the tags
> >readonly? That would at least remove part of your
> problem with how you
> >tag in subversion. And being able to put branches,
> tags and pretty
> >much anything else in a clear hierarchy is in my
> eye less of a
> >nightmare than having a huge flat list of labels.
> But then again, I'm
> >probably missing something about how you envision
> labels to work :)
> >
> >/Johan
> >
>
>---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail:
> users-help@subversion.tigris.org
> >
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 3 19:54:21 2005