AW: Problem with reverting
From: Markus Schaber <m.schaber_at_3s-software.com>
Date: Thu, 2 Feb 2012 08:24:47 +0000
Von: Stefan Sperling [mailto:stsp_at_elego.de]
> > I'm using the latest SharpSVN build 1.7002.2011, and command line 1.7.2 (r1207936)
> The problem is that the code checking the specified depth is called in the context of processing a single target from the target list.
> Fixing this would require changing how libsvn_wc processes arguments for revert, and changing at least one public function (svn_wc_revert4).
> I suppose we could add a workaround at the client layer that updates the specified depth to inifinity if all specified targets within the specified depth result in the entire subtree being reverted.
I have my own "calculate revert depth" function (and a similar one for commits) which tries to transfer the user selection (which works on objects) into a set of files and directories, and an operation depth argument. In this case, my function came to the conclusion that the depth "files" should be enough. I can try to change it to output "infinity" in that case. But I guess this should only be for added / tree conflicted directories.
The point is that my function intentionally tries to keep the depth level as small as possible, to prevent the inclusion of non-selected objects. The function also detects cases which produce such collisions, and errors out. One example is that we want to commit a deleted directory (which, it seems, only works recursively) and an added directory, but not all added children of the latter one.
In general, it seems that either SVN 1.7 is more picky at the order of parameters and depth for commits and reverts, or our QS and users tend to find use-cases we did not test back with SVN 1.6. I had to adopt both the "calculate revert depth" and "calculate commit depth" functions slightly between 1.6 and 1.7 due to some cases not working any more, and it now seems that I reached a point where this is not enough and I have to split the user operation into several working copy operations. For reverts, this is okay. But for commits, I need to add more cases where we error out, as I do not want to silently split the commit into two distinct commit actions.
Maybe I could workaround this using changesets? I did not investigate further in this direction, yet, however.
> Not sure if that isn't a bit too hackish, though.
But there seems to be a different problem in the second case, with the reordered arguments: At least the --depth=files should convince the client to revert the incoming directory including the incoming "svnobj" file, which it does not.
> In any case, I think this warrants an entry in our issue tracker, if only because the behaviour can be confusing.
I did create issue http://subversion.tigris.org/issues/show_bug.cgi?id=4109 for this case.
My personal wish would be that operations like revert and commit work for all constellations even with "--depth=empty" if we explicitly mention all affected files and directories, and that "--depth=files" recreates the files when reverting a directory. This both together would allow me to completely get rid of my "calculate xxx depth" functions, which seem to grow into write-only code due to their increasing number of corner cases...
 This seems to be the case even when we mention all children of that directory as arguments. I guess that the reason for this is that the directory might potentially have newly added children on the server which are not yet known to the working copy, but on the other hand, this should error out, asking the user for an update.
-- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: email@example.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915Received on 2012-02-02 09:26:00 CET
This is an archived mail posted to the Subversion Users mailing list.