Re: Tree conflict bug?

Quoting Mark Phippard <markphip_at_gmail.com>:

> On Thu, Oct 30, 2008 at 2:04 AM, Neels J Hofmeyr <neels_at_elego.de> wrote:
>>
>>
>> Mark Phippard wrote:

>>> For a user to want or expect that behavior would seem that they would
>>> have to just ignore what an update command does. If I run update does
>>> it update or not? If it does, then the file ought to reflect the
>>> state of the repository -- unversioned. Of course perhaps we need to
>>> invent a new "state" for this scenario, but if we have to choose from
>>> our existing states I think unversioned is the one that reflects the
>>> reality of the situation. It also puts the working copy in the best
>>> place to resolve the conflict as the user can run svn add or "rm" to
>>> put the WC into the desired state. In this scenario, it probably
>>> makes sense for the parent folder to be in the tree conflict state?

Hi Mark,

Out of curiousity, I had a look at our initial problem statement
in /notes/tree-conflicts/use-cases.txt. Use case #2 is similar
to your transcript. We display something equivalent to

    C foo.c
A bar.c

during svn update that tries to delete a foo.c that has local
mods. So far, so good. But then, in our diagram, foo.c
magically disappears somewhere near svn resolved, right where
you run into trouble with svn add and svn rm.

For what it's worth, our tests (currently) check the results
of the individual commands, but not any use cases from start to
finish. :-(

> $ svn st wc2
> M wc2/foo
> $ svn up wc2
> C wc2/foo
> A wc2/bar
> Updated to revision 2.
> Summary of conflicts:
> Tree conflicts: 1
> $ svn st wc2
> M C wc2/foo
> $ svn resolved wc2
> Resolved conflicted state of 'wc2'
> $ svn st wc2
> M wc2/foo

> svn: File not found: transaction '2-2', path '/foo'
> $ svn add wc2/foo
> svn: warning: 'wc2/foo' is already under version control
> $ svn st wc2
> M wc2/foo
> $ svn add --force wc2/foo
> $ svn st wc2
> M wc2/foo
> $ svn ci -m "Cannot checkin" wc2Sending wc2/foo
> subversion/libsvn_client/commit.c:864: (apr_err=160013)
> svn: Commit failed (details follow):
> subversion/libsvn_fs_fs/tree.c:661: (apr_err=160013)
> svn: File not found: transaction '2-3', path '/foo'

Here's a funny message that means "out of date". But running
svn update again will just re-raise the tree conflict!
Carrying out the deletion in the first place would solve
the dilemma.

I think skipping parts of an update is OK where the update
wants to add or edit something. For a directory, an "edit"
can include deletion of descendants. We can still skip
those deletions.

We've already added a sort of "limbo" state for tree conflict
victims that are unversioned or simply do not exist. In svn
status they appear as

? C foo-unversioned.c
! C foo-really-gone.c

So maybe there's a way forward for the update case. I'll
ponder merge over breakfast.

Thanks for the feedback!
Steve

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