On Wed, Mar 2, 2011 at 4:14 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Arwin Arni [mailto:arwin_at_collab.net]
>> Sent: woensdag 2 maart 2011 10:49
>> To: dev_at_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
Received on 2011-03-02 14:42:52 CET