No, I didn't ignore it. Frankly, you are saying "it's easy, they will
get it". Have you tried? I have, lots of times. They _don't_ get it.
And if they do get it on Monday, by Wednesday its gone again. Jeremy,
as developers we are all used to the kind of mental models and
abstractions that make this stuff second nature. But these people
have different areas of expertise, and stuff that we take for granted
are blind spots for them.
> 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.
And that's one of the things I have proposed; to make tags more
"first class" (without breaking existing stuff) and also make them
more approachable to mere mortals. You can reference my earlier post
on this thread where I think I made my position pretty clear.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 21 17:42:32 2006