On Thu, 2009-01-22 at 16:38 +0000, Julian Foad wrote:
> On Thu, 2009-01-22 at 11:30 -0500, Mark Phippard wrote:
> > On Thu, Jan 22, 2009 at 11:28 AM, Julian Foad
> > <julianfoad_at_btopenworld.com> wrote:
> > > On Thu, 2009-01-22 at 17:07 +0100, Stephen Butler wrote:
> > >> Quoting Mark Phippard <mphippard_at_collab.net>:
> > >>
> > >> > On Thu, Jan 22, 2009 at 9:56 AM, Julian Foad
> > >> > <julianfoad_at_btopenworld.com> wrote:
> > >> >> FYI I'm just about to look at this.
> > >> >
> > >> > I added an svn info to the script to look at the tree conflict. The
> > >> > problem is that after running update the local revision in the WC for
> > >> > the folder is 1 when it should have been updated to 2 by the update
> > >> > command. So this is why it is out of date when you try to commit.
> > >> > When the tree conflict was created it should have still allowed the WC
> > >> > revision to be updated.
> > >>
> > >> Turning off the skipping of tree conflict victims is pretty
> > >> straightforward, at least for this use case (#1 in
> > >> notes/tree-conflicts/detection.txt).
> > >
> > > Is it? "Turning off skipping" means "designing and implementing some
> > > behaviour other than skipping". The local node is scheduled for
> > > deletion. The incoming change is to modify it. I assume the existing
> > > "update" code would not handle this case already.
> >
> > That is exactly what 1.5.5 does. The base is updated, you can revert
> > etc. That said, I did not test this exhaustively, but that is what it
> > seemed to do to me.
>
> Oh, OK. That would make it really easy to implement the way we want it.
> Great. I'll have a go if Stephen doesn't beat me to it.
Making this simple change...
[[[
Index: subversion/libsvn_wc/update_editor.c
===================================================================
--- subversion/libsvn_wc/update_editor.c (revision 35411)
+++ subversion/libsvn_wc/update_editor.c (working copy)
@@ -2294,7 +2294,14 @@ open_directory(const char *path,
SVN_ERR(svn_wc_conflicted_p2(NULL, &prop_conflicted, NULL, full_path,
adm_access, pool));
- if (victim_path != NULL || tree_conflict != NULL || prop_conflicted)
+ /* If this is raising a tree conflict because the dir is scheduled for
+ * deletion, then fall through to the normal "update" code path which
+ * will update the base while leaving it scheduled for deletion.
+ * For other conflicts, return without updating the node. */
+ if (victim_path != NULL
+ || (tree_conflict != NULL
+ && tree_conflict->reason == svn_wc_conflict_reason_deleted)
+ || prop_conflicted)
{
db->bump_info->skipped = TRUE;
remember_skipped_tree(eb, full_path);
]]]
results in the desired result on the outer directory, but the tree
conflicts are raised on the children:
[[[
$ bash ../markphip-tc-script.sh
### Making a Greek Tree for import...
### Done.
### Importing it...
### Done.
### In wc1, edit and commit A/B/E/alpha ...
Sending wc1/A/B/E/alpha
Transmitting file data .
Committed revision 2.
### Done.
### In wc2, rename A/B/E to A/B/E1 ...
A wc2/A/B/E1
D wc2/A/B/E/alpha
D wc2/A/B/E/beta
D wc2/A/B/E
### update wc2, creating tree conflict ...
C wc2/A/B/E/alpha
At revision 2.
Summary of conflicts:
Tree conflicts: 1
D C wc2/A/B/E
> local delete, incoming edit upon update
D C wc2/A/B/E/alpha
> local delete, incoming edit upon update
D wc2/A/B/E/beta
A + wc2/A/B/E1
### In wc2, merge change from r2 to renamed file ...
--- Merging r2 into 'wc2/A/B/E1':
U wc2/A/B/E1/alpha
### In wc2, mark conflict resolved ...
Resolved conflicted state of 'wc2/A/B/E'
D wc2/A/B/E
D C wc2/A/B/E/alpha
> local delete, incoming edit upon update
D wc2/A/B/E/beta
A + wc2/A/B/E1
M + wc2/A/B/E1/alpha
### In wc2, commit rename
/home/julianfoad/src/subversion-tc2/subversion/libsvn_client/commit.c:867: (apr_err=155015)
svn: Commit failed (details follow):
/home/julianfoad/src/subversion-tc2/subversion/libsvn_client/commit_util.c:287: (apr_err=155015)
svn: Aborting commit: '/home/julianfoad/tmp/markphip-tc-script/wc2/A/B/E/alpha' remains in conflict
]]]
I haven't thought further about this yet.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1044802
Received on 2009-01-23 13:47:14 CET