Thanks for the suggestions Ryan.
> Well, the tags directory does have a special meaning to you and me:
> it is a place where you copy things to but then never change again.
Yes, I agree. The tag directory does have a special meaning to users,
but that's by convention, not hard-coded into SVN.
And that's as it should be. (So, I think we agree on this.)
> Install a pre-commit hook to allow adds but not modifications
> in the tags directory and you solve the problem.
That's a good idea. However, it is possible that you might wish to
create the tag and then adjust, for example, the version information in
the tag itself. I'm not saying that's good practice, but a hook script
does prevent the tags area from being used a little flexibly like this.
(I don't know of a way to implement a '--force' to allow a hook script
to be bypassed.)
> > The problem stems from the fact that the copy command means
> something
> > slightly different depending upon whether the target already exists.
> > An alternative possible cause of this problem is if two engineers
> > create the same tag at almost the same time.
>
> Two engineers trying to create tag at the same time is a
> communication problem; not Subversion's domain to solve that.
I agree. I think for official releases this is certainly the case.
SVN commands certainly should not be used instead of communication.
But, suppose that tags are also used to trigger 'informal' test builds;
this might occur often enough that it's not worth having a formalised
process in place. Then I think it is reasonable to ask for SVN to
provide a little additional support.
It is not SVN's job to enforce good practice, only to encourage it.
SVN should be a flexible tool, allowing a team to implement whatever
mechanisms and processes suit the needs of that team.
(To illustrate what I mean, consider that SVN provides a locking
mechanism. This helps prevent two authors both editing a bitmap at the
same time. The same could be achieved by team communication and
process. The fact that SVN has a locking mechanism, though, helps, and
this mechanism can be used as *part* of a process or team communication
system.)
Thus whilst I agree with all the points you have made, I don't think
you have given reason why my suggestions should *not* be implemented.
My suggestions a usefulness beyond the particular circumstances I have
used here to motivate them.
Thus I still think it would be useful to have the
--target-directory DIR
--no-target-directory
as with the Bash shell copy command.
Likewise, I think it would also still be useful to have some mechanism
whereby a branch or tag area, or indeed any directory, can be given
protection from having loads of files 'accidentally' copied into it.
Usually, if you copy many files into an area already containing lots of
files, that is a mistake. It would be nice if the *default* copy
behaviour prevented this, somehow.
What I don't have is a good suggestion for how to do this.
My inclination would be for copy to not perform such copies without
an explicit, e.g.,
--combine-trees
switch. That suggestion would not be backwards compatible, but would,
I think, be useful, and in all other respects an advantage.
I'd certainly welcome other suggestions.
Thanks,
Rob.
Rob Hubbard
_______________________________________________
This email has been scanned for Softel by Star.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-29 11:01:07 CEST