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

Re: STATUS of 1.6

From: Stephen Butler <sbutler_at_elego.de>
Date: Wed, 28 Jan 2009 20:45:27 +0100

Quoting Mark Phippard <mphippard_at_collab.net>:

> Any new updated on this? What can we do to get TODO cleaned up and
> cut this release? For those of you that are "signed up" for these
> items is there anything that can be done to help? Review a branch,
> write a test etc.?
>
> Here is the current list, it is pretty much the same list we've had
> for 3-4 weeks:
>
> Blocker:
>
> * #3334: Tree conflicts "merry-go-round" about update updating the base.
> Julian Foad is working on this. Done for when victim is a file, still
> doing for when victim is a directory. [julianfoad]
> See:
> <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1019712>.

For a long while (since November) we thought that the victim of an
update tree conflict should always be skipped. Sounded clean and
simple.

After feedback from other developers, it's clear that we need to update
the tree conflict victim's metadata and base-files. This should allow
the user to resolve and commit immediately (equivalent to --accept=mine)
or revert (equivalent to --accept=theirs). We avoid the merry-go-round
by not requiring a second update before the commit.

Any working-copy gurus out there could review the issue-3334-dirs
branch, and review our email discussions about the design for this
backdoor tweaking of victim metadata and base-files (which gets a
bit hairy when the victim is a directory tree).

   http://svn.haxx.se/dev/archive-2009-01/0678.shtml
   http://svn.haxx.se/dev/archive-2009-01/0681.shtml

It would be great if someone extended resolved_tests.py to generate
the 3 main update use cases (see update_tests.py 46-51) and then
resolve and commit them.

>
> * #3209: Tests XFAIL due to changed tree-conflicts behaviour
> http://svn.haxx.se/dev/archive-2009-01/0538.shtml summarizes the tests
> that are failing because of real differences in pre-TC vs. post-TC
> functionality.

For these cases ("local add without history" and "prior checkout"),
trunk currently raises a tree conflict. That's messy, because the
victim must be skipped, which puts the user on the merry-go-round
of issue 3334.

1.5 fails in either case. I think we should restore this behavior
on trunk.

Ideally, we'd fold the added/existing items silently into the
working copy, as Paul Burba suggests. We'd fail only if faced
with a true obstruction (e.g. the local add is the wrong type,
or the prior checkout has a different URL). But that can
probably wait until after 1.6.0.

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
Received on 2009-01-28 20:45:47 CET

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.