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

Re: [RFC] Issue #3603 Fix - Should we do more?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 14 Apr 2010 15:36:31 -0400

Paul Burba wrote:
> On Wed, Apr 14, 2010 at 2:34 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Paul Burba wrote:
>>> In a perfect world maybe we'd give a error along the lines of 'hey,
>>> you are trying to reintegrate into a shallow WC and some of the paths
>>> affected by the merge aren't present, you are going to get tree
>>> conflicts, is this really what you want? :-)'
>>>
>>> But going this route adds more merge special casing and obviously has
>>> a performance penalty, two things we definitely don't need more of.
>> Can we give this feedback at the time of the conflict rather than up front?
>> That is, can we avoid the performance penalty of an upfront merge forecast
>> but still tell folks, when they get those tree conflicts, "Hey, you could
>> avoid this kind of conflict by simply not having directory FOO missing by
>> sparse configuration; go flesh that sucker out and retry this reintegration."
>
> Mike,
>
> Do you mean to let the merge complete and give the warning at the
> *end* rather than stopping the merge on the first tree conflict due to
> a missing subtree-caused-by-a-shallow-WC? After all, the user might
> not care about some tree conflicts and want the merge to complete as
> best it can.

Oh, gosh, no. I think my comment is less about your proposed change and
more of a general tree conflict thing. I would feel more warm and fuzzy if
I knew that the tree conflict information that we leave around is clear
about the reason for the conflict. That a missing-due-to-sparse-checkouts
directory is the reason for the conflict, not just some generic "something
is missing" note. That way folks can immediately know, if not by explicit
recommendation stored in the conflict information then at least by
inference, that they could probably avoid the conflict by reverting the
merge, de-shallowing the directories that the merge wished were present, and
then repeating the merge.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-04-14 21:37:03 CEST

This is an archived mail posted to the Subversion Dev mailing list.