> > For this, a very simple concept of a label would suffice:
> > A text that can be associated with a revision number.
>
> For what exactly? You want to know which tag copies have been made of a
> given file? It seems like a trunk-wide label wouldn't help with that at
> all.
To tell me that "when tag X.Y was created, rev 4711 was used" and
"when tag A.B was created, rev 4819 was used" *without* taking my
eyes away from the history of a file *in the trunk*.
> To do that, you determine the range of revision numbers when the change
> was present on the trunk by doing a log of the file. Then you determine
> the tags that were created from those revisions by looking through the
> log of the entire repository. (Copies are pretty clearly marked in the
> verbose log).
That's the problem. I would have to view the log of the entire repository,
which would not be needed if the simple file log would have told me what
i need.
Moreover, if my development process does not even involve the creation
of tags, then revision labels are a simple means to later easily
determine which revision number was used for which software release.
In such a workflow, the copy information is not even present and my
example above would instead read "rev 4711 is labelled X.Y and rev 4819
is labelled A.B" and i would know that the change was introduced
between the X.Y release and the A.B release.
I can't imagine a non-trivial development process without branches, but
i think that there are a lot of projects that would do quite well without
tags if simple labels would be supported.
> I think revision labels would occasionally be helpful, but I don't see
> how they'd help for this scenario.
Hope you see better now ;-))
>
> Duncan Murdoch
>
> >
> > Robert
> >
> >
> >> -----Original Message-----
> >> From: Jeremy Pereira [mailto:jeremyp@jeremyp.net]
> >> Sent: Montag, 20. November 2006 13:37
> >> To: Tim Hill
> >> Cc: Subversion Users
> >> Subject: Re: Is label support in future release?
> >>
> >>
> >>
> >> On 17 Nov 2006, at 21:32, Tim Hill wrote:
> >>
> >> >>
> >> >> I've seen this argument before. Are graphic artists and technical
> >> >> writers really too stupid to use source code control systems? I
> >> >> think your problem is in the way you are probably trying to
> >> >> explain tagging. I would guess you are giving them the CVS
> >> >> concept of a tag and then telling them how to implement cvs tags
> >> >> in Subversion.
> >> >
> >> > Are you *serious* ??? Have you ever sat down and tried to explain
> >> > tags to these people. It's not terminology, it's a much more
> >> > complex concept. Sorry, they can "get" labels, they don't "get"
> >> > tags. You can _call_ them labels, and they get it then, but once
> >> > you start explaining the *how*, they just glaze over.
> >>
> >> Was there a reason you ignored the subsequent paragraph in my post?
> >> Let me say it again: you don't *need* to teach these people about
> >> tags. Tags in Subversion are just copies really. I'm sure your
> >> graphic designers can understand the concept of a copy, after all
> >> they probably did it all the time with the normal file system in
> >> their pre-source code control days. So you just tell them that when
> >> they do a release they should svn copy the trunk to a sub-directory
> >> of the tags directory. Except I wouldn't call it "tags", I'd call it
> >> "releases". Your graphic designers could use any terminology they
> >> like for the name.
> >>
> >> There are problems with the subversion way, for instance tags are not
> >> immutable (neither are they in cvs incidentally, tags can be moved
> >> from revision to revision without even any history being created);
> >> it's difficult to figure out the revision from which a tag or branch
> >> was made without doing an svn log; it's almost impossible to figure
> >> out which revisions have been copied to make tags and branches. But
> >> to me, the way to fix these problems is to fix the problems not to
> >> introduce another feature which would complicate the product
> >> (unnecessarily IMHO). For instance, per directory access controls
> >> would solve the immutability problem.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 20 16:41:06 2006