How do you achieve the following with SVN tags:
I am analyzing a defect and look at the history of a
given file in the *trunk*. This history gives me the
revision numbers during which the given file was changed.
It does not allow me (easily) to cross-reference a change
in the history with what has been tagged in the past, i
have to do this manually by checking what tag was created
with what revision.
For this, a very simple concept of a label would suffice:
A text that can be associated with a revision number.
This text must be *independent* of the commit message that was
supplied by the committer of the change that created the
given revision number. It is as simple as sticking a post-it
to the correct sheet in a huge pile of paper. (Thanks to the
other poster who used this analogy!) And, to stay with this
analogy, removing the post-it and sticking it on a different
paper or writing a different text on it should also be possible.
I don't want to have to look through all the /tags
subfolders, then lookup the file, then open this file's
history to determine if the offending change is there or not.
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
Received on Mon Nov 20 14:49:57 2006