[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:49:12 -0400

C. Michael Pilato wrote:
> 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.

Had I read your question with my brain fully engaged in the task, I think I
would have chosen different words of response. I certainly wouldn't have
started off with "Oh, gosh, no". Sorry, Paul.

I think it would be great if there was a way at the end of the merge to say,
"Hey, we notice that you had some tree conflicts, all of the variety caused
by directories missing-due-to-shallowness. Here's a recommended fix, if you
care." Do we have that kind of data and opportunity available?

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

Received on 2010-04-14 21:49:44 CEST

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