AW: Re: Is label support in future release?

Tim Hill <mailto:drtimhill@comcast.net> schrieb am Montag, 20. November 2006 17:37:

> On Nov 20, 2006, at 4:37 AM, Jeremy Pereira wrote:
>
>>
>> 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.
>
> "A rose by any other name...". You can call them anything you
> like ... it won't help. The tag _concept_ is more complex to
> present,
> and it's _implementation_ is more complex to explain. Do you
> have any
> experience of doing something like this? With trained, but non-
> techie, professionals?
>

I have. And apart from the problems that trained people, non-tech people have with version control in general I haven't had a single problem so far. But this is coincidential evidence and I don't doubt in any way that explaining these concepts may be difficult.

Most non-tech people don't need to know about "when was this tag created from which path and at which revision". They need to be able to check out a tag, they need to compare a tag with another one and they need to be able to create a tag. All of this is simple the way things currently are once you wrapped your mind around the "a tag is a copy" paradigm.

The best thing is not to call that thing a "tag" but just teach them "release copies are found in the folder 'tags'".

>>
>> 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.
>>
> You have those now (per-dir access controls), so in fact it *might*
> be possible, but the implementation isn't correct, since ad
> admin has
> to "bless" a folder as a tags folder, which means just creating a
> "tags" folder is not enough; so the user has no cues from the tool
> about which "tags" folders are _really_ immutable and which should be.

To the contrary: The fact that subversion allows me to name tags any way I like gives me the freedom to call them "releases" for all non technical users out there. It allows me to build a directory structure and split tags into "dev, qa, release" if the project requires it. And I can bless them all to be immutable if I wish so.

However, using the name "tag" is a good convention and some tools (TortoiseSVN e.g.) will warn you if you try commiting to a subfolder of the tags folder.

>
> If tags were really to work for me, I would need three additional
> features:
>
> -- The ability to actually mark the tag as truly immutable, enforced
> by the tools, at create time. Something like:
>
> svn copy blah blah --immutable

You can do that. Put the proper hook in place and you don't even need the --immutable switch. You can even grant some people the permission to modifiy tags (although not recommended, but still occasionally useful). The argument that a hook is not part of subversion does not count IMO: hooks are an integral part of subversion and any subversion administrator should be capable of putting a suitable one in place. There are sufficient examples out there.

>
> -- The ability to create a tag (copy) at commit time in a single
> command:
>
> svn commit blah blah --tag PATH

You can do that, however the syntax is slightly different: 'svn copy -m"tagging this wc" . repo/tags/tagname'. This creates a tag with you desired name at commit time. There are other implications to this: you get a tag that does represent a state not in the trunk or any other branch, but this is more a problem with mixed revision working copies. I wouldn't do it but it is certainly possible.

If you imply that you command should commit to whatever path the working copy was checked out and then tag that revision: I'd not do that either as you might be tagging an untested state.

If you want the syntax to be 'svn tag' instead of 'svn copy' feel free to write a wrapper. TortoiseSVN does this btw: you get a "tag/branch" command that maps directly to a copy operation.

>
> -- The ability to use a tag as an argument to the --revision switch:
>
> svn co foo.c --revision "some-tag-path-syntax-or-other"
>

You can't, but I rarely use this (at least not with checkout). I can imagine it could be useful if you were to do lots of merging from/to branches (merge all changes from the trunk from the revision on that this branch was created). Things such as "Show all log messages in the trunk from tag_a to tag_b". However, I can live without that and it can be scripted: Write a wrapper to svn that checks wether a revision argument is a valid svn url and substitute it by the revision number the url was copied from (obtainable by svn log --stop-on-copy).

>
> Whatever -- it's not going to happen anyway since the subversion
> priests here don't need it, so ipso facto no-one else does either.

No. It's not happening because noone could write a formal spec that takes care of quite a lot of nasty corner cases and still makes life simpler. Noone volunteered to write the nessesary code either, the people developing this great great software have limited time (just like you and me probably) and decided that they regard other features as more important or more entertaining and thus will implement those first. I can not and will not hold that decision against them - their fun project is a valuable tool for me, saving me hours and hours of stupid work. Most, if not all problems I've seen in this thread are solveable in some way or another, some may seem or be a little awkward to use but you can abuse the full power of your favourite shell to make your life easier.

People here are trying to explain the reasons behind the current way things work and to help you find ways how you can solve you problems with the current featureset until perhaps sometimes label support might get implemented.

>
> --Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

regards

felix

-- 
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org