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

Re: Tags and branches are NOT the same

From: Vincent Starre <vstarre_at_comcast.net>
Date: 2006-03-19 15:41:36 CET

Still afraid of this issue due to the hugge thread is spawned last time,
but I _still_ feel it was unresolved last time. Each of my posts asking
for a breakdown of "what is currently difficult in the current system"
and "proposals for how to extend the current system" went ignored. I
would still love to see that, because I really do think there are some
use-cases which could be helped out.

This is just a ++ for further /intelligent/ discussion on the thread.
(and may noone ever mention named numbers within it ;)

Julian Foad wrote:

> John Calcote wrote:
>
>> On 2006-03-18 at 14:34:32 Julian Foad wrote:
>> >
>> > Unfortunately not, because you have fallen into the same trap as
>> so many other
>> > correspondents, and that is to approach the subject with the
>> assumption that it
>> > is conceptually simple, having an obvious Right Answer. The
>> "solution" you
>> > mention here is that a "tag" should be an alias name for a
>> revision number.
>> I don't know Julian, it seems conceptually simple to me, according to
>> the CVS manual [...], tags seem to be
>> just symbolic names for revision numbers. Section 4.4 is entitled,
>> "Tags - Symbolic Revisions", which seems to convey the very simple
>> three-word definition that I used in my original note, which you
>> strongly state is not the case.
>
>
> That's the case for CVS. Subversion is not CVS. One particularly
> pertinent difference is that a CVS revision number is per file,
> whereas in Subversion a revision number is across the whole
> repository. This difference has more than trivial implications.
>
>
> [...]
>
>> > You don't even acknowledge in this mail that there are other possible
>> > definitions, such as a tag marking only a subset of the files and
>> > directories in the repository, which is something that CVS tags
>> can do.
>>
>> I'm sorry if I wasn't clear on this point in my original message. I'm
>> not really interested in possible new interpretations of the concept
>> of tagging. Granted there is probably value in doing a use-case study
>> as you suggest, but my original point was that existing CVS users
>> expect tags to act as symbolic names for specific revisions of file
>> sets.
>
>
> Ah, I see. (That was't clear before, as you didn't mention CVS except
> in the negative. Apology accepted.)
>
> In contrast, the Subversion team is not really interested in just
> implementing something that is as close as possible to the CVS concept
> of tagging without thinking about whether that is the best concept for
> Subversion, nor in providing Subversion with two different ways of
> tagging without very good reason. There may be good reasons for
> supplementing or changing Subversion's tagging abilities, but they
> have not been adequately studied and justified.
>
>
> [...]
>
>> In fact, I didn't provide a complete user experience in my examples.
>> This surely needs to be done, but it's likely not that hard.
>
>
> I love it when people say that. :-) Actually, you're probably right
> in that collecting a fairly comprehensive set of use cases should
> require only a few hours of one person's time plus maybe a fortnight
> or so of collecting examples from other people. Indeed, I'm pretty
> sure a partial collection exists in the mailing list archive as part
> of a previous discussion. Analysing those use cases and arguing about
> whether they should be supported directly or whether the user should
> be taught a new way to achieve the same goal is likely to take longer.
>
>
>> > I know I'm being harsh on you, but this is the way your message comes
>> > across after having seen many others like it. Bear with me a minute.
>> I don't mind you being harsh - I only mind being ignored, because
>> then no intelligent exchange of ideas can happen. :)
>
>
> OK. I'm sorry that all I can offer at the moment is an invitation for
> you or someone else to study the requirements, arguments and proposals
> that have been made so far and present them in a coherent form to
> enable further progress.
>
> - Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 19 15:41:56 2006

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

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