[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts - see what happens in the current state

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 07 Oct 2008 22:49:47 +0100

On Mon, 2008-10-06 at 13:43 +0200, Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
> > Tree conflict fans,
> >
> > To become aware of what happens in the current state of tree conflict
> > detection, please try the following exercises. You'll see several things
> > that work better than in v1.5, and several things that remain to be
> > done.
>
> Hi Julian,
>
> Thanks for the exercises. They were instructive! I would like to get the
> "deep" tree conflict detection tests working. E.g.,
> tree_conflicts_on_update_* in update_tests.py.
>
> By "working", I mean "not XFAIL". I'll tweak the expected output to use
> your new treeconflict='C' for victims instead of the old status='C ' for
> parent-dirs.
>
> On the svn side, we'll need the update/merge/etc. commands to skip tree
> conflict victims. I'm afraid that will break a lot of other tests that
> we've discussed already, the ones that create tree conflicts. But I'm no
> stranger to patching tests.
>
> Does this sound like a reasonable interim goal?

Yes, that's perhaps the main coding task we need to do now.

> (And one more comment below)
>
> Regards,
> Steve
>
> >
> > [[[
> >
> > # Apply the attached patch (which adds a pseudo-test to
> > update_tests.py).
> > patch -p0 < ...
> >
> > # Run the pseudo-test. [*1]
> > cd subversion/tests/cmdline/
> > ./update_tests.py 51
> >
> > # Change directory to the WC.
> > cd svn-test-work/working-copies/update_tests-51/
> > cd uc1
> >
> > # Try one of these:
> > svn up # or ...
> > svn switch ^/uc2 # or ...
> > svn merge -c3 ^/uc1
> >
> > # Try some of these:
> > svn status # status currently shows on both parent and victim
> > svn info . # info is shown on the parent
> > svn commit -m 'try to commit with unresolved conflicts'
> > svn resolved . # resolving is currently done to the parent
> > svn commit -m ''
> >
> > # For UC2, don't be in the directory "uc2" when running "svn up": [*2]
> > cd ..
> > svn up uc2 # or ...
> > svn switch ^/uc2 uc2 # or ...
> > svn merge -c3 ^/uc1 uc2
> >
> > ...
> > ]]]
> >
> >
> > The changes set up by the pseudo-test are:
> >
> > Branch Incoming change (-c3) Local scheduled change
> > ------ -------------------- --------------------
> > uc1/ edit Foo.c move Foo.c Bar.c
> > uc2/ move Foo.c Bar.c edit Foo.c
> > uc3/ move Foo.c Bar.c move Foo.c Bix.c
> >
> > These correspond to Use Cases 1/2/3 in
> > notes/tree-conflicts/use-cases.txt if you exercise them with "update",
> > or cases 4/5/6 if you exercise them with "merge".
> >
> >
> > [*1] I think that's how you would run an individual test if you build in
> > the source tree. I build Subversion in an object tree that is separate
> > from the source tree, and running an individual test is a bit more
> > complex. I need a "bin" directory somewhere (mine is in the source tree)
> > containing either installed executables or symlinks to the versions of
> > "svn" and "svnadmin" in the object tree. I run the test like this:
> > [[[
> > (cd $OBJECT/subversion/tests/cmdline/ &&
> > $SOURCE/subversion/tests/cmdline/update_tests.py 51 --bin=$SOURCE/bin)
> > ]]]
> >
> > [*2] I just found a bug triggered by UC2 where, if you try to do the
> > update from within the directory "uc2" itself, it throws an error
> > because it doesn't like raising a tree conflict in a directory whose
> > path is passed as the empty string "".
>
> This is because add_file_with_history() (update_editor.c:3314) calls
> check_tree_conflict() with the parent path instead of the victim path.

Ah, thanks for finding that.

> I think we don't need to check for tree conflicts in that function,
> because it's called from the add_file() callback. It calls its caller,
> so we end up checking for tree conflicts twice. Maybe I can unroll
> the recursion.

It would be great if you can. I'll take a look too.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-07 23:50:10 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.