[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 19:50:06 CET

On 2/28/06, Matthias Wächter <matthias.waechter@tttech.com> wrote:

> I'm not getting the point anyway. If I screw up anything in my own
> repos, it's my fault. We already have a hook script that must be present
> to enable sensitive features like commit metadata (revprops) changes.
> Why not add a hook for this as well so that someone who knows what he
> does, can allow the clients to perform the action, anyone else does not?

Clients are already free to perform the action. In other words, the
API allows you to commit either text or property changes, overwriting
what's already in the repository. You may have no idea what you're
overwriting, but the API allows it.

The policy I'm talking about is simply that the 'official' svn client
doesn't use the API this way. It expects you to make changes to
versioned data in a working copy, so that if you're out of date, you
*have* to begin by merging the thing you'd otherwise be overwriting.

I suppose that if there were a tidal wave of support for some sort of
'svn put localfile URL', or 'svn propset name value URL', we could add
in those features. They just sort of run against the grain of the
'copy-modify-merge' development model that the client was designed
around.

> If I have hook scripts for commits installed, I always will get a
> notification email, whether it was done on a checked-out folder or
> remotely. If I perform a "svn mkdir URL" or "svn cp URL URL" this is
> true as it is for "svn propset URL".

Sure, but 'svn mkdir URL' and 'svn cp URL URL' only create new things.
 They don't silently overwrite existing things. That's the danger of
the feature being proposed.

There are arguments to be made here, which you make: (1) the
overwritten data isn't ever 'lost', because it's still in the
repository's history, and (2) commit emails go out.

But I think the risk here is accidental overwrites of small,
unnoticeable bits. You think that you have the latest version of a
file, because you just grabbed a copy of it 10 seconds ago. So then
you do a 'direct' file write or property set, and unknowingly undo a
1-line change that your collaborator committed during the past 10
seconds. Nobody notices in the commit email either, because it's only
a 1 line change in a sea of diffs.

Anyway, I suppose I'd be more comfortable with the proposed feature(s)
if they had the ability to warn. Something like:

$ svn propset color green URL
WARNING: you're about to overwrite version 29389 of this file, last
modified by 'joe' on Jan 19th. Is this really what you want to do?

---------------------------------------------------------------------
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:08:43 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.