Re: Tree conflicts - problem handling when local directory is deleted

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

> I suppose we could record a new tree conflict, possibly overwriting
> an existing tree conflict. It could get confusing if the user
> updates and raises a tree conflict in dir A, then later updates dir
> A/B and raises a new conflict in A/B. Now there are two tree
> conflicts in the same tree. This could happen in everyday situations
> such as an interrupted update.
>
> Does anyone see a problem with overwritten or redundant tree
> conflicts?

If this means we need to potentially overwrite one tree conflict with
a newer one, than I guess that is what we would need to do. We cannot
leave things as they are.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1043297