You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Markus Schaber <m....@3s-software.com> on 2012/02/01 16:27:13 UTC
Problem with reverting
Hi,
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" "Dev ice\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 :-(
Best regards
Markus Schaber
--
___________________________
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
Re: AW: Problem with reverting
Posted by Philip Martin <ph...@wandisco.com>.
Markus Schaber <m....@3s-software.com> writes:
>> Can you describe in detail how the tree conflict came about?
>
> I tried to create a self-contained example, but it seems that, in
> those examples, the conflict comes out differently, I cannot get the
> tree conflict to appear.
I added an example to the issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=4109
Is that the problem you are seeing?
--
Philip
AW: Problem with reverting
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Stefan,
Von: Stefan Sperling [mailto:stsp@elego.de]
> As given your example is a bit hard to follow because there are multi-layer operations involved. I am not sure how to interpret the replacement. What did the directory look like before it was replaced?
> Is this during merge or update?
> Can you describe in detail how the tree conflict came about?
I tried to create a self-contained example, but it seems that, in those examples, the conflict comes out differently, I cannot get the tree conflict to appear.
I'll send more detail if I know how to reconstruct that sample with plain SVN.
Best regards
Markus Schaber
--
___________________________
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
Re: Problem with reverting
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 02, 2012 at 10:27:23AM +0000, Markus Schaber wrote:
> > That can be done. It requires reworking how the 'revert' operation in libsvn_wc processes its arguments. We'd need to pass it a list, rather than a single path and adapt the code to handle this properly.
> > This implies an API change so it can only be done for 1.8.
>
> Maybe it's a task I could try to "attack" on the Hackathon.
Agreed :)
> I'm not sure what you mean with "independently of their parent directory".
>
> In case of the re-ordered arguments, the revert operation first reverted the added file foo/bar, and then reverted the added and tree-conflicted directory foo. But despite the fact that "--depth=files" was given, the revert did leave the incoming foo/bar marked as deleted, instead of reverting it when reverting foo/.
>
> Here's the example, executing the two revert operations independently, using a copy of the same working copy:
> D:\TreeConflict\ef3sok5h.vc4.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
>
> D:\TreeConflict\ef3sok5h.vc4.svnwc>svn revert "Device\Plc Logic\Application\Library Manager\svnobj"
> Reverted 'Device\Plc Logic\Application\Library Manager\svnobj'
>
> D:\TreeConflict\ef3sok5h.vc4.svnwc>svn status
> R C Device\Plc Logic\Application\Library Manager
> > local add, incoming add upon update
> D Device\Plc Logic\Application\Library Manager\svnobj
> Summary of conflicts:
> Tree conflicts: 1
>
> D:\TreeConflict\ef3sok5h.vc4.svnwc>svn revert --depth=files "Device\Plc Logic\Application\Library Manager"
> Reverted 'Device\Plc Logic\Application\Library Manager'
>
> D:\TreeConflict\ef3sok5h.vc4.svnwc>svn status
> D Device\Plc Logic\Application\Library Manager\svnobj
>
> Here, I'd expect the second revert operation to recreate the svnobj file.
It is possible that what you are seeing is correct behaviour.
As given your example is a bit hard to follow because there are
multi-layer operations involved. I am not sure how to interpret the
replacement. What did the directory look like before it was replaced?
Is this during merge or update?
Can you describe in detail how the tree conflict came about?
> But maybe this problem is a different problem than the other problem.
Possibly.
AW: Problem with reverting
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Stefan,
Von: Stefan Sperling [mailto:stsp@elego.de]
> On Thu, Feb 02, 2012 at 08:24:47AM +0000, Markus Schaber wrote:
> > I did create issue http://subversion.tigris.org/issues/show_bug.cgi?id=4109 for this case.
> Thanks!
> > 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,
> That can be done. It requires reworking how the 'revert' operation in libsvn_wc processes its arguments. We'd need to pass it a list, rather than a single path and adapt the code to handle this properly.
> This implies an API change so it can only be done for 1.8.
Maybe it's a task I could try to "attack" on the Hackathon.
> > and that "--depth=files" recreates the files when reverting a
> > directory
> You mean reverting individual files independently of their parent directory? Not sure if this does or would work. In theory is could work.
I'm not sure what you mean with "independently of their parent directory".
In case of the re-ordered arguments, the revert operation first reverted the added file foo/bar, and then reverted the added and tree-conflicted directory foo. But despite the fact that "--depth=files" was given, the revert did leave the incoming foo/bar marked as deleted, instead of reverting it when reverting foo/.
Here's the example, executing the two revert operations independently, using a copy of the same working copy:
D:\TreeConflict\ef3sok5h.vc4.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
D:\TreeConflict\ef3sok5h.vc4.svnwc>svn revert "Device\Plc Logic\Application\Library Manager\svnobj"
Reverted 'Device\Plc Logic\Application\Library Manager\svnobj'
D:\TreeConflict\ef3sok5h.vc4.svnwc>svn status
R C Device\Plc Logic\Application\Library Manager
> local add, incoming add upon update
D Device\Plc Logic\Application\Library Manager\svnobj
Summary of conflicts:
Tree conflicts: 1
D:\TreeConflict\ef3sok5h.vc4.svnwc>svn revert --depth=files "Device\Plc Logic\Application\Library Manager"
Reverted 'Device\Plc Logic\Application\Library Manager'
D:\TreeConflict\ef3sok5h.vc4.svnwc>svn status
D Device\Plc Logic\Application\Library Manager\svnobj
Here, I'd expect the second revert operation to recreate the svnobj file.
But maybe this problem is a different problem than the other problem.
Best regards
Markus Schaber
--
___________________________
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
Re: Problem with reverting
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 02, 2012 at 08:24:47AM +0000, Markus Schaber wrote:
> I did create issue http://subversion.tigris.org/issues/show_bug.cgi?id=4109 for this case.
Thanks!
> 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,
That can be done. It requires reworking how the 'revert' operation
in libsvn_wc processes its arguments. We'd need to pass it a list,
rather than a single path and adapt the code to handle this properly.
This implies an API change so it can only be done for 1.8.
> and that "--depth=files" recreates the files when reverting a directory
You mean reverting individual files independently of their parent
directory? Not sure if this does or would work. In theory is could work.
The files would need to come from a different revision than the directory
on-disk, i.e. this would need to create a mixed-revision working copy.
I don't recall off-hand how mixed-revisionness is supposed to work in
newly added directories, though.
AW: Problem with reverting
Posted by Markus Schaber <m....@3s-software.com>.
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
Re: Problem with reverting
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 01, 2012 at 03:27:13PM +0000, Markus Schaber wrote:
> Hi,
>
> 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" "Dev ice\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 :-(
>
> Best regards
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.
Not sure if that isn't a bit too hackish, though.
In any case, I think this warrants an entry in our issue tracker,
if only because the behaviour can be confusing.