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