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?
>
> 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.
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
-- The ability to create a tag (copy) at commit time in a single
command:
svn commit blah blah --tag PATH
-- The ability to use a tag as an argument to the --revision switch:
svn co foo.c --revision "some-tag-path-syntax-or-other"
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.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 20 17:38:10 2006