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

Issue #2491: Add --dry-run flag to "svn update" client command

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 23 Jun 2014 09:18:23 +0100

Markus Schaber wrote (in thread "controversial issues in the tracker"):
> * 2491 Add --dry-run flag to "svn update" client command
> http://subversion.tigris.org/issues/show_bug.cgi?id=2491
> There already was a patch submitted by Arwin Arni 2011 and discussed on the
> list, but it was not applied due to objections.
> The first controversial issue was of conceptual nature: This functionality
> somehow duplicates the semantics of "svn status -u" - on the other
> hand, "svn status -u" is known to not exactly give the desired
> semantics in some cases - especially, it can only tell about the existence of
> incoming changes, but not whether they're actually produce a conflict.
> The second issue was more of an implementation issue - the patch spreads a lot
> of if()-branches in the code. Some developers would have preferred cleaner code
> by creating a separate editor driver. However, this will result in a bunch of
> duplicate code, which needs to be kept in sync (or the "--dry-run"
> mode will not match what the real update will perform. There is already a
> precedence for merge --dry-run.
> See also the lengthy discussion at
> http://svn.haxx.se/dev/archive-2011-03/index.shtml#63
> My personal opinion is that it is an useful feature, so we should try to agree
> on a way of implementing it. On the other hand, given that the provided patch
> does not cover some corner cases, it may actually not be "bite-sized".
> :-)

I think we *should* have a dry-run mode but it's not simple to do, so I would leave the issue open.

(Even better than a dry-run mode would be the ability to undo after running an update -- but that requires something like "stash" support which is not available yet.)

- Julian
Received on 2014-06-23 10:18:58 CEST

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.