Ben Collins-Sussman schrieb:
> 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.
[...]
> 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.
... what could be solved by requiring a "-rREV" to be given for such
operations (and "svn delete URL" as well, as Julian points out). This
way you'd make a "virtual checkout" by remembering a revision that you
analyzed your change are acceptable against, and if the repository
object has changed since the time you analyzed it, say, since "-rREV"
the command would fail at the server. This dependency would have to be
resolved like any local merge driven by "svn update". But -- without
knowing the API altogether -- this sounds like an API change.
> 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?
Uuh, Ooh, without blocking the repository between the output of "29389"
and the user reply that opens another window of uncertainty ... ;)
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 2 22:38:23 2006