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

Re: Updating local-moves (was: svn commit: r1301390 ...)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sat, 17 Mar 2012 01:14:38 +0100

On Fri, Mar 16, 2012 at 10:40 PM, Branko ─îibej <brane_at_apache.org> wrote:
> On 16.03.2012 15:50, Stephen Butler wrote:
>> Some users do want more control over update (i.e., they trust
>> Subversion less). Interactive resolution during or after update is an
>> interesting scenario.
> s/Some/Many/ :)

I seriously doubt that. But maybe you're joking :-).

In my experience, only the most technical users would like to have
more control like this. And the most technical users amount to ...
what? ... maybe 1 % of the Subversion user population? Most other
users just want Subversion to do the right thing, without bothering

In my company, of the ~100 colleagues that use subversion, I think
there might be exactly 1 that would prefer to have more control. I'm
pretty sure the other 99 would prefer Subversion to do the right thing
automatically, and leave them alone except if absolutely necessary

Don't git and mercurial and others just apply the changes to wherever
the code moved to, regardless of the container? Do those users often
complain about that behavior? (I don't know, it's just a question)

> Somewhat off-topic, but "svn update" has the serious problem that it's
> impossible to revert to the state before the update if one had local
> changes. Most of these "pick sane defaults" kinds of discussions would
> become moot if one could have some kind of client-side snapshot that let
> revert be something more than just an all-or-nothing proposition.

That's a great suggestion, I agree that would be a very good
improvement. It would allow to have more control, but only if you need
it (in case you noticed after the fact that something went wrong, and
you can back up step by step).

Received on 2012-03-17 01:15:34 CET

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