On Wed, Apr 14, 2010 at 3:49 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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."
Ok, I got you now. I agree that would be nice to have. In the same
vein, it would probably be beneficial to flag tree conflicts
due-to-missing-subtrees-due-to-auth restrictions. This is probably
quite rare, but wow, talk about confusing:
I have an unmodified, single-rev WC:
>svn up
At revision 5.
>svn st
I merge all available revs:
>svn merge ^^/A A_COPY
C A_COPY\D\H
--- Recording mergeinfo for merge of r2 through r5 into 'A_COPY':
U A_COPY
--- Recording mergeinfo for merge of r2 through r5 into 'A_COPY\D':
U A_COPY\D
Summary of conflicts:
Tree conflicts: 1
Local delete?
>svn st
M A_COPY
M A_COPY\D
! C A_COPY\D\H
> local delete, incoming edit upon merge
Summary of conflicts:
Tree conflicts: 1
Nothing has been deleted on this branch since it was copied!
>svn log -v -r1:HEAD A_COPY
------------------------------------------------------------------------
r1 | jrandom | 2010-04-14 16:23:08 -0400 (Wed, 14 Apr 2010) | 1 line
Changed paths:
A /A
A /A/B
A /A/B/E
A /A/B/E/alpha
A /A/B/E/beta
A /A/B/F
A /A/B/lambda
A /A/C
A /A/D
A /A/D/G
A /A/D/G/pi
A /A/D/G/rho
A /A/D/G/tau
A /A/D/H
A /A/D/H/chi
A /A/D/H/omega
A /A/D/H/psi
A /A/D/gamma
A /A/mu
A /iota
Log message for revision 1.
------------------------------------------------------------------------
r2 | jrandom | 2010-04-14 16:23:14 -0400 (Wed, 14 Apr 2010) | 1 line
Changed paths:
A /A_COPY (from /A:1)
log msg
------------------------------------------------------------------------
r3 | jrandom | 2010-04-14 16:23:16 -0400 (Wed, 14 Apr 2010) | 1 line
Changed paths:
M /A_COPY/mu
Good luck guessing that the problem is that you are not authorized to
a subtree in your target:
>type ..\..\repositories\merge_tests-83\conf\authz
[/]
* = rw
[/A_COPY/D/H]
* =
Of course in that case our recommended course of action would be "svn:
Wow, your authz configuration and/or repository configuration is
insane! Go throttle the person responsible for it until they change
it".
> Do we have that kind of data and opportunity available?
From Stefan's reply elsewhere in this thread I gather the answer is
currently no re the data. Re the opportunity, not sure I totally
understand you there, but at the very end of
libsvn_client/merge.c:do_directory_merge() would be the place to do
it.
Paul
Received on 2010-04-14 22:49:31 CEST