[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: Stephen Butler <sbutler_at_elego.de>
Date: Mon, 06 Oct 2008 13:43:40 +0200

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?

(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.

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.

--Steve

>
>
> - Julian
>
>

-- 
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
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-06 13:43:56 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.