[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Support for: Setting property on non-local target

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-02-28 20:24:38 CET

On 2/28/06, Julian Foad <julianfoad@btopenworld.com> wrote:

> That's interesting, Ben. I've heard that idea mentioned in conversation, but
> are you sure?
>
> (a) I've never really heard that given as the reason. Have we written it down
> anywhere?

Karl and I have been saying to each other in the chicago office for 5
years, though maybe we've never written it down or mailed to the list.
 (I know I've said it on this list before, though, or maybe it was on
users@ ...? )

>
> (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.

'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.

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!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 20:28:10 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.