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

Re: [PATCH] Add --dry-run flag to "svn update" client command

From: Arwin Arni <arwin_at_collab.net>
Date: Wed, 02 Mar 2011 16:11:37 +0530

Hi Bert,
> 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.
>
I actually just followed the model used in merge dry run. If I were to
implement my own editor, I felt that I would be duplicating a lot of
code which already exists in the update editor. (w.r.t conflict
detection, property handling and lots more)
>
> 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.
>
IIRC, status -U doesn't tell the user if there are going to be any
text/prop conflicts upon performing the update (which I think is the
primary use-case of this dry-run flag), it merely tells you if a file
has been modified and if there is a newer version on the server.
Moreover, status doesn't accept an -r option.
> 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?
>
I have actually percolated the dry_run parameter all the way to the API.
svn_client_update4 accepts this boolean and the notify_func provided by
the client does the notification. I don't understand why this wouldn't
help any other Subversion client.

Thanks and Regards,
Arwin Arni
Received on 2011-03-02 11:42:00 CET

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.