Philip Martin <philip@codematters.co.uk> writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
> > Or should we just say, "hey, svn cp URL URL won't overwrite anything,
> > period." I mean, I guess that *would* be consistent with our
> > out-of-date commit philosophy.
>
> Not permitting copy to overwrite gets my vote
Me too, really. Read below as to why.
> If we allow overwriting there is no procedure that can be used to
> avoid doing it by accident. I can check that the destination
> doesn't exist before the copy, but that doesn't guarantee that the
> destination doesn't get created between the check and the copy
> operation.
Actually, that's not true. 'svn cp URL URL' is driving a regular old
commit editor, just like any commit. That means that if the
destination *does* get created between the existence check and the
commit, then svn_fs_merge() will bounce the txn due to out-of-dateness.
> On the other hand disallowing overwriting means that a copy operation
> can not be guaranteed to succeed. Once again I can check for the
> destination first, and delete if required, but as before I cannot
> guarantee that the destination does not get created between the check
> and the copy.
Well, this is true of *any* type of commit. There's always a race
condition with other committers.
> If I overwrite a destination by accident, it is not obvious that it
> has happened. If the copy fails because the destination exists I get
> a visible error. To my mind the latter behaviour is preferrable, and
> the consistency with commit reinforces my view.
Exactly. Silent overwrites *never* happen with ordinary commits. And
given that 'svn cp URL URL' is just a commit as well, I tend to think
it should behave the same.
> Having a '--force' flag to allow overwriting would be acceptable
> (maybe even ideal), but I don't see it as necessary.
If we decide to do this, then it's a feature that will become part of
'svn commit' itself... i.e. "commit, but don't do out-of-dateness
checks". Is that really desirable? Do people really want to be able
to commit and silently overwrite things? This has the potential to
clobber other people's changes that you've never seen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 26 15:55:25 2002