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
