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.
Received on 2012-02-02 11:58:55 CET