Ben Collins-Sussman schrieb:
>> (b) It's not consistently true. For example, "svn delete" can delete by URL an
>> item that's changed since you last saw it.
>
> Sure, but again, I don't think the the core issue here is about
> consistency in our command set. It's about data-loss risk and
> encouraging safe practices.
I think it's the documentation's task to encourage safe practices, maybe
supported by server-side hooks.
> 'svn rm URL' and 'svn put file URL' is about the difference between
> overt destruction and accidental destruction. When someone deletes an
> entire file (or tree) at once, *everybody* notices. There's no
> 'subtle, unnoticed' loss of data. It's a thunderous event, destroying
> everything... both stuff you've seen and stuff you haven't. If your
> coworker just changed the file 10 seconds before your delete, you
> *know* that you'll be getting a phone call from him when he sees your
> commit.
You are biased on a subset of possible use cases. If you have any
$(wildcard) call in a makefile you will not automatically notice a
removed file, for example.
> But committing a tweak to a file that you don't even realize is
> out-of-date? That's where the insidious, silent data-stomping can
> happen. That's the thing we should be afraid of. It's the very
> problem that both 'copy-modify-merge' and 'lock-modify-unlock' version
> control systems were designed to prevent!
Ok. How about that:
$ REP=`pwd`/repos
$ svnadmin create ${REP}
$ svn mkdir -m "create dir" file://${REP}/dir
Committed revision 1.
$ svn cp -m "copy dir to dir1" file://${REP}/dir file://${REP}/dir1
Committed revision 2.
$ svn cp -m "copy dir to dir1" file://${REP}/dir file://${REP}/dir1
Committed revision 3.
$ svn ls -R file://${REP}
dir/
dir1/
dir1/dir/
So if someone (r2) creates the directory with the name I want to use for
my copy right before my commit (r3), my copy is put at an unexpected
place. Don't you consider this a "Very Bad Thing" either?
I suggest that a "known good repository revision" for remote activities
should _always_ be required, for "svn cp URL URL" as well as for "svn rm
URL" or "svn propset URL". The current behavior is misleading in the way
things are considered "safe". In this example, I would be required to use
$ svn cp -m "copy dir to dir1" --consider-revision=1 file://${REP}/dir
file://${REP}/dir1
to assure that neither /dir/ nor /dir1/ (in its non-existence) have
changed since revision 1 which my change for r3 is based on.
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 22:02:31 2006