On Thu, 2009-01-08 at 15:06 -0500, Mark Phippard wrote:
> This might be the same as what Julian is already working on.
Yes, this is issue #3334 for directories.
> Scenario:
>
> Folder is moved/renamed and committed.
>
> In another WC, I make an edit to a file in this folder. I then do an
> update, which brings in the rename to the folder and creates a tree
> conflict:
>
> $ svn up
> C MyProject/src/com/test/myproject/builder
> U MyProject/src/com/test/myproject/editors/XMLColorManager.java
> A MyProject/src/com/test/myproject/internal
> A MyProject/src/com/test/myproject/internal/builder
> A MyProject/src/com/test/myproject/internal/builder/SampleNature.java
> A MyProject/src/com/test/myproject/internal/builder/SampleBuilder.java
> A MyProject/src/com/test/myproject/internal/builder/ToggleNatureAction.java
> U MyProject/plugin.xml
> Updated to revision 6.
> Summary of conflicts:
> Tree conflicts: 1
>
> $ svn st
> C MyProject/src/com/test/myproject/builder
> > local edit, incoming delete upon update
> M MyProject/src/com/test/myproject/builder/SampleBuilder.java
>
> OK, at this point it all seems right. It created a conflict on the
> folder and left it in place, along with the modified file. (Actually,
> it left all of the files in the folder).
Yes, this so far is exactly what we want. (It doesn't delete the rest of
the stuff in the folder, because we want to leave the user with a single
self-consistent version of the folder - in this case, the "mine" copy -
so as not to make the state of this sub-tree more complex than it need
be.)
> So what I did was copy my changes to file to a patch and apply them to
> the new version of the file. I then just wanted to get rid of the
> tree conflicted version (delete it). This is what I did:
>
> $ svn revert -R .
> Reverted 'MyProject/src/com/test/myproject/builder'
> Reverted 'MyProject/src/com/test/myproject/builder/SampleBuilder.java'
> $ svn st
> $ svn up
> At revision 6.
This was a correct expectation on your part, but the WC metadata was
left in an inconsistent state when the conflict was raised: the base
revision was updated to "6" but the entry was not marked as "deleted"
and still had all its text bases and other stuff. Then "revert" reverted
to the text-bases, and "update" thought there was nothing to do because
it based its decision on the rev-number.
> $ svn info MyProject/src/com/test/myproject
> Path: MyProject/src/com/test/myproject
> URL: file:///Users/mphippard/repositories/svn-1.6/trunk/MyProject/src/com/test/myproject
> Repository Root: file:///Users/mphippard/repositories/svn-1.6
> Repository UUID: 96b0211e-88b0-4685-b02d-4a050a80c20f
> Revision: 6
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mphippard
> Last Changed Rev: 6
> Last Changed Date: 2009-01-08 14:52:28 -0500 (Thu, 08 Jan 2009)
>
> $ svn info MyProject/src/com/test/myproject/builder/
> Path: MyProject/src/com/test/myproject/builder
> URL: file:///Users/mphippard/repositories/svn-1.6/trunk/MyProject/src/com/test/myproject/builder
> Repository Root: file:///Users/mphippard/repositories/svn-1.6
> Repository UUID: 96b0211e-88b0-4685-b02d-4a050a80c20f
> Revision: 6
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mphippard
> Last Changed Rev: 3
> Last Changed Date: 2009-01-08 14:43:07 -0500 (Thu, 08 Jan 2009)
>
> So basically, revert removed the conflict etc. but the way the WC is
> written the folder and its contents still exist. I expected revert to
> either make it unversioned, or for update to remove it. Like I said,
> I think this is what Julian is already working on -- basically turning
> the folder into a scheduled Add + History like it does for a file in
> the same scenario. If that were the case, then revert would have put
> the folder back to unversioned. I figured I would make sure.
Yup. Thanks for sharing the scenario.
I'm struggling to understand exactly how to manipulate the WC metadata
but getting somewhere.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1013727
Received on 2009-01-09 14:03:41 CET