On Wed, Mar 2, 2011 at 4:14 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Arwin Arni [mailto:ar...@collab.net] >> Sent: woensdag 2 maart 2011 10:49 >> To: dev@subversion.apache.org >> Subject: [PATCH] Add --dry-run flag to "svn update" client command >> >> Hi All, >> >> In my effort to understand the delta editor API, I took it upon myself >> to try and implement the --dry-run flag for "svn update". >> With Kamesh's guidance, I think I've managed to pull it off. >> >> Here is the relevant Issue. >> http://subversion.tigris.org/issues/show_bug.cgi?id=2491 >> >> I have attached a log message and a patch that implements --dry-run for >> update. >> >> Currently, externals are handled inside >> subversion/libsvn_client/externals.c by running checkout/switch. For a >> dry-run update to mimic a real update, the notifications have to be the >> same. Since some of these notifications are generated by the above >> mentioned checkout/switch runs, I have to implement dry-run for them >> also. I'll take this up as a follow-up exercise. Now, the dry-run will >> simply ignore any externals in the working copy. >> >> Please review this and share your thoughts. > > I don't think this is the way we should implement this. > > This patch adds an if before every operation in the update editor that > changes the working copy. This makes the update editor harder to maintain, > while you really only need a simple editor implementation that notifies its > output to get a dry run output. > > That would allow the dry run code to be maintained independently without > obfuscating the existing update editor. > > > Besides: I don't know why the update editor really needs --dry run support. > We always told our users to use svn status -U, which shows the same > information in a generally more useful output. > > A dry run update is a nice feature for 'svn' with console notification, but > implemented this way it doesn't help any other Subversion client, while > status -U does. Should we improve status -U instead?
Agreed. I'm not a fan of duplicating this functionality (and maintaining them in parallel when they inevitably drift) as part of 'svn up'. Let's improve what we already have, rather than inventing 'svn st -U' -Hyrum
