On Tue, Sep 08, 2009 at 11:01:48AM -0400, David Weintraub wrote:
> The problem is that there is no way to tell if a copy operation is a tag, a
> branch, or someone is merely copying files. They all use the same "svn cp"
> command.
>
> Basically, if something is copied to the "tags" directory, it is a tag. If
> it's copied to the branches directory, it is a branch, and if it is copied
> somewhere else, it is a regular copy.
>
> The best I can suggest is user training. Repeat over and over again to your
> users that "Tags go here...".
While a wrong/deleted/modified tag is always a problem caused by human
error, I'm beginning to doubt that we can keep telling people to simply
be really, raelly careful, forever.
People make errors, that's part of why we use tools to support us
when we're dealing with complicated tasks. I'm increasingly considering
that Subversion should make it possible to mark parts of the repository
tree as 'write once, then readonly'. It would avoid many problems caused
by human error.
I don't think the existing solutions with pre-commit hooks are reliable
enough. svnperms.py isn't the answer for complex real-world repositories.
Having to write regexes to match paths in huge multi-project repositories
with directory structures which happen to have evolved over time isn't
that much fun.
> Remember that this is a revision control
> system, so you can always undo what the developers did, and you always know
> who was not doing what they're suppose to be doing.
Yes, you can always undo everything, which is good. No data can get lost.
But there can still be subtle problems and people can waste *time*
trying to figure them out.
When you check out a tag to reproduce a problem, you don't readily know
if that tag is still in the same state as it was when it was created.
Which in itself is already a contradiction to what a tag is all about.
You have to run svn log to find out. Have you *ever* verified that
a tag you got from a Subversion repository was still sound? I haven't.
Maybe someone has modified e.g. a single file by accident when they
were working on a bugfix for that version, from a working copy checked
out of this tag, and no one noticed the accidental commit?
The fact that an accidental commit should not have happened and should
have been noticed and both these failures are based on human error does
not help much when you're actually hitting problems like this in practice.
People use IDEs which look rather like pilot cabinets of an airplane.
I'm not surprised that with all those buttons and dials in the way
people make errors. "Oops I must have right-clicked the wrong folder
when committing that months ago..."
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392538
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-08 17:45:32 CEST