Hi Max,
Sorry to come to this very late, but I didn't see any follow-ups to
this,
and I think there is an important conceptual difference between copies
and
tags.
> David Weintraub wrote:
> > We agree that tags have several short comings:
> >
> > Tags are not first class objects in Subversion -- just another
> > directory. It is up to the administrator to know that a particular
> > directory is a tag and not a branch. This type of knowledge
> is stored
> > in the implementation of the site and not in Subversion itself.
>
> Being in a directory "/tags/" conveys the meaning pretty well - could
> explain why this should be considered a shortcoming?
That allows you to find the objects in a tag. It is not so easy to find
the tags that apply to a given object - which is often what you want out
of a tag (consider "compare with tag" from an IDE when trying to find
out which version a particular feature/bug/... was implented). And it
is not possible for generic applications (e.g. Subclipse) to do
automatically because it is just a convention (and there are two
recommended
conventions) rather than something implicit in Subversion.
Having tags as just another directory is a neat implementation,
but it doesn't capture the intrinsic difference in intent. A tag is
a bookmark to a particular snapshot, rather than another tree among
equals. Hook scripts *can* make it immutable and read-only,
but out-of-the-box, Subversion doesn't do this. It's not so bad if
all you use is the command line, where you've got to specify it
yourself,
but a GUI should be able to allow selection from a list.
Also, the copy doesn't have instantly obvious link to the tree to which
it is related. Yes, the information is there, if you do log -v, but
just
browsing the repository, you don't necessarily know how tagA relates to
trunk, branchB, tagC. Developers have to be disciplined in naming.
Branches and tags should be clearly related to their common sources (and
to each other when they are related).
> I think the overriding summary thought has to be "Is there
> really anything
> labels could do, which (suitably enhanced) tags could not?".
I think the overriding summary thought has to be "what interface will
give people the behaviour they expect"? Then start thinking about
whether the current implementation can be extended to support it. The
behaviour I expect is that an object set possesses tags and branches;
the current behaviour is that a tag or branch possesses objects. I
think that is the crucial distinction which causes the confusion.
Cheers,
Ian Brockbank
Applications Software Team Leader
e: ian.brockbank@wolfsonmicro.com / apps@wolfsonmicro.com
scd: ian@scottishdance.net
t: +44 131 272 7145
f: +44 131 272 7001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 28 13:08:28 2005