Hi, Stefan,
Von: Stefan Sperling [mailto:s...@elego.de] On Wed, Feb 01, 2012 at 03:27:13PM +0000, Markus Schaber wrote: > > I have a directory foo with tree conflict: local add of foo and a file > > foo/bar, and then an update trying to add the same foo and foo/bar. Now, I > > try to revert using SharpSVN, which internally calls svn_client_revert_2(). > > I give the path of the directory and the file, and a depth of "files". Then > > I get the Exception Can't revert 'C:\Users\{...}\foo' without reverting > > children", SVN_ERR_WC_INVALID_OPERATION_DEPTH. > > > > I can reproduce that on the command line, getting the additional hint that > > I should use --depth="infinity" instead. That seems to indicate that > > reverts of added directories always need --depth="infinity", despite the > > fact that all existing children are also mentioned in the argument list. > > > > C:\{...}\svnwc>svn status > > R C Device\Plc Logic\Application\Library Manager > > > local add, incoming add upon update > > A Device\Plc Logic\Application\Library Manager\svnobj > > Summary of conflicts: > > Tree conflicts: 1 > > > > C:\{...}\svnwc>svn revert --depth=files "Device\Plc > > Logic\Application\Library Manager" "Device\Plc Logic\Application\Library > > Manager\svnobj" > > svn: E155038: Try 'svn revert --depth infinity' instead? > > svn: E155038: Can't revert 'C:\{...}\svnwc\Device\Plc > > Logic\Application\Library Manager' without r everting children > > > > > > The strange thing is that if I change the order of arguments, it works > > without errors, but misses to restore the "svnobj" file from the > > repository, marking it as "deleted" - despite the fact that both > > --depth=files and the file's path are given on the command line. > > > > C:\{...}\svnwc>svn revert --depth=files "Device\Plc > > Logic\Application\Library Manager\svnobj" "Device\Plc > > Logic\Application\Library Manager" > > Reverted 'Device\Plc Logic\Application\Library Manager\svnobj' > > Reverted 'Device\Plc Logic\Application\Library Manager' > > I'm using the latest SharpSVN build 1.7002.2011, and command line 1.7.2 > > (r1207936) > > > > C:\{...}\svnwc>svn status > > D Device\Plc Logic\Application\Library Manager\svnobj > > > > I guess that this was the reason why I initially sorted the arguments to > > revert by "parents first"... > > > > I always thought of operations like "revert" or "commit" to work on a > > set of input files, where the order of arguments is not important, but > > this seems to be wrong :-( > The problem is that the code checking the specified depth is called in the > context of processing a single target from the target list. > It cannot know that you're also going to revert the single child. > 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[1]) 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... Best regards Markus Schaber [1] 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: m.scha...@3s-software.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 167014915
