subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Schaber <m.scha...@3s-software.com>
Subject AW: Problem with reverting
Date Thu, 02 Feb 2012 08:24:47 GMT
Hi, Stefan,


Von: Stefan Sperling [mailto:stsp@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.schaber@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

Mime
View raw message