Reversion of copied directories with depth != infinity

[Markus Schaber <m....@3s-software.com>]

Hello,

We discussed some issues on #svn-dev[1], and I was encouraged to
subscribe here for further discussion. 

I'm currently working on integration of Subversion support into
CoDeSys[2], using the latest SharpSVN based on subversion 1.6.16.

One current problem is that the revert command refuses to work on a
copied directory with a depth different to infinity. This seems to be
issue 3851[3]. There is written that "in most (all?) cases the user can
use depth=infinity as an alternative". 

Now our issue is that we want to revert the contents and properties of
the directly contained files, but we don't want to revert files in
subdirectories, nor do we want to revert the scheduled addition of the
directory itself.

Our current workaround is to revert the files themselves in case we get
the SVN_ERR_WC_NOT_LOCKED error code, but that may fail in the future
when the semantics of subversion change.

So my question now is: In what direction is the development headed in
this area?

Will there be a different set of operations ("revert the directory
(files, properties) to the original state" vs. "revert the scheduled
addition")?

And will there be an option which allows the deletion of the orphaned
files, if a scheduled-for-addition directory tree is reverted?

Regards,
Markus

[1] http://colabti.org/irclogger/irclogger_log/svn-dev?date=2011-04-27 -
my username was schabi
[2] http://www.3s-software.com/
[3] http://subversion.tigris.org/issues/show_bug.cgi?id=3851

AW: Reversion of copied directories with depth != infinity

[Markus Schaber <m....@3s-software.com>]

Hi, Philip,

> Von: Philip Martin [mailto:philip.martin@wandisco.com] 
> "Markus Schaber" <m....@3s-software.com> writes:

> 1.7 changes the behaviour so that depth more accurately describes the
> nodes to be affected; issue 3851 describes some corner cases in 1.7.

OK, I see. So maybe some of the workaround code I just invented can be
removed once we update to 1.7.

> > So my question now is: In what direction is the development headed
in
> > this area?
> 
> It's not really headed anywhere.  1.7 fixes some of the depth
> inconsistencies in 1.6 and uses the centralised metadata to make more
> cases work.

It's a pity that 1.7 will be to late for our first release.
 
> > Will there be a different set of operations ("revert the directory
> > (files, properties) to the original state" vs. "revert the scheduled
> > addition")?
> 
> Sounds like a reasonable enhancement.
 
> > And will there be an option which allows the deletion of the
orphaned
> > files, if a scheduled-for-addition directory tree is reverted?
> 
> For copied nodes at least.

Maybe "--remove-orphaned-nodes" removes all copied, non-modified files,
and
"--force" in addition removes also non-copied and modified files?

Regards,
Markus

Re: Reversion of copied directories with depth != infinity

[Philip Martin <ph...@wandisco.com>]

"Markus Schaber" <m....@3s-software.com> writes:

> I'm currently working on integration of Subversion support into
> CoDeSys[2], using the latest SharpSVN based on subversion 1.6.16.
>
> One current problem is that the revert command refuses to work on a
> copied directory with a depth different to infinity. This seems to be
> issue 3851[3]. There is written that "in most (all?) cases the user can
> use depth=infinity as an alternative". 

In 1.6 the behaviour of depth with revert on a copied directory is
buggy.  The depth parameter should specify which nodes are to be
reverted but in practice it just determines which directories get
locked.  That means that revert can affect more nodes than would be
expected for a restricted depth.

1.7 changes the behaviour so that depth more accurately describes the
nodes to be affected; issue 3851 describes some corner cases in 1.7.

> Now our issue is that we want to revert the contents and properties of
> the directly contained files, but we don't want to revert files in
> subdirectories, nor do we want to revert the scheduled addition of the
> directory itself.
>
> Our current workaround is to revert the files themselves in case we get
> the SVN_ERR_WC_NOT_LOCKED error code, but that may fail in the future
> when the semantics of subversion change.

That sounds like the correct thing to do.

> So my question now is: In what direction is the development headed in
> this area?

It's not really headed anywhere.  1.7 fixes some of the depth
inconsistencies in 1.6 and uses the centralised metadata to make more
cases work.

> Will there be a different set of operations ("revert the directory
> (files, properties) to the original state" vs. "revert the scheduled
> addition")?

Sounds like a reasonable enhancement.

> And will there be an option which allows the deletion of the orphaned
> files, if a scheduled-for-addition directory tree is reverted?

For copied nodes at least.

-- 
Philip

Re: AW: Reversion of copied directories with depth != infinity

[Philip Martin <ph...@wandisco.com>]

"Markus Schaber" <m....@3s-software.com> writes:

> m.schaber@SCHABERM /cygdrive/d/testcheckout
> $ svn propset svn:ignore testfile bar
> property 'svn:ignore' set on 'bar'
>
> m.schaber@SCHABERM /cygdrive/d/testcheckout
> $ svn status
> A  +    bar
>
> m.schaber@SCHABERM /cygdrive/d/testcheckout
> $ svn revert --depth=empty bar
> svn: Try 'svn revert --depth infinity' instead?
> svn: Unable to lock 'bar/innerdir'
>
> -- snap --
>
> Now, if we have other modifications inside bar, there is no way to
> revert the change of the svn:ignore property without side effects.

As far as I can work out you want to revert the property change without
reverting the copy.  That's not possible using revert as revert applies
to all changes: properties, text, conflicts, tree-changes.  So revert
attempts to undo the copy and that need depth infinity.  There is no API
to revert a subset of the changes such as just the properties.

> Is there a workaround for this situation (working with the API of libsvn
> 1.6.16)? Maybe manually synchronizing the properties to the BASE state?

svn_wc_get_prop_diffs to get the changes followed by svn_wc_prop_set to
make the changes you want.

-- 
Philip

AW: Reversion of copied directories with depth != infinity

[Markus Schaber <m....@3s-software.com>]

Hi,

> Von: Markus Schaber [mailto:m.schaber@3s-software.com]
 
> One current problem is that the revert command refuses to work on a
copied
> directory with a depth different to infinity. This seems to be issue
> 3851[3]. There is written that "in most (all?) cases the user can use
> depth=infinity as an alternative".

I think I now found a case where depth=infinity is not an alternative.

Assume we are in a working copy, and have a non-modified directory tree
foo:

-- snip --

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ svn cp foo bar
A         bar

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ svn status
A  +    bar

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ touch bar/testfile

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ svn status
A  +    bar
?       bar/testfile

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ svn propset svn:ignore testfile bar
property 'svn:ignore' set on 'bar'

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ svn status
A  +    bar

m.schaber@SCHABERM /cygdrive/d/testcheckout
$ svn revert --depth=empty bar
svn: Try 'svn revert --depth infinity' instead?
svn: Unable to lock 'bar/innerdir'

-- snap --

Now, if we have other modifications inside bar, there is no way to
revert the change of the svn:ignore property without side effects.

Is there a workaround for this situation (working with the API of libsvn
1.6.16)? Maybe manually synchronizing the properties to the BASE state?

I'm just starting to look into svn:ignore support, and this problem
might hit me sooner or later.

Regards,
Markus