On 11/20/2006 8:49 AM, Robert Graf-Waczenski wrote:
> 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.
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.
> 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.
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).
I think revision labels would occasionally be helpful, but I don't see
how they'd help for this scenario.
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 15:45:19 2006