On Fri, Jan 23, 2009 at 2:56 PM, Stephen Butler <sbutler_at_elego.de> wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
>> On Thu, 2009-01-22 at 11:20 -0500, Mark Phippard wrote:
>>>
>>> On Thu, Jan 22, 2009 at 11:07 AM, Stephen Butler <sbutler_at_elego.de>
>>> 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).
>>> >
>>> > What should we do if the user runs update again without resolving the
>>> > existing tree conflict first? Skipping is not an option.
>>>
>>> I've never really grokked why we'd skip updating something, but I am
>>> sure there are some reasons.
>>
>> In text conflicts, it's hard to imagine how we could do better than
>> skip, so we just skip. In tree conflicts, likewise, except now I think
>> about it it might not be too hard to design how to "compose" two tree
>> conflicts together... at least in some cases, such as when one of the
>> conflicts involves deleting the node.
>>
>>> Clearly the current situation is worse
>>> though. You cannot commit, because you are out of date, and if you do
>>> update again after resolving the tree conflict all it does is create
>>> it again.
>>
>> Note that the work-around is (should be) to mark as resolved, revert the
>> schedule-delete, update, then re-schedule the delete:
>>
>> svn resolved wc2/A/B/E
>> svn revert -R wc2/A/B/E
>> svn up wc2
>> svn delete wc2/A/B/E
>
> I believe the update would get rid of A/B/E completely (perhaps leaving
> some unversioned local mods), so the final delete is not needed. See
> UC3 below.
In my scenario (which I guess is UC1), the delete is local, so update
is not removing anything. It did seem like when testing with 1.5,
update took care of the updating the .svn even though it was locally
deleted. So if I did revert the delete, I was all set (up to date).
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1045314
Received on 2009-01-23 21:01:04 CET