Re: Reversion of copied directories with depth != infinity

"Markus Schaber" <m.schaber_at_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