Stefan,
>> As suggested earlier, svn-1.6.x-latest is better at communicating
>> which file is the actual tree conflict. Like so
>>
>> G foo/Bar
>> svn: Attempt to add tree conflict that already exists at apple/
>> banana.xml
>> svn: Error reading spooled REPORT request response
>>
>> When trying to 'resolved' that one, and optimistically resume the
>> merge, we're discovering that svn had made multiple items marked as
>> "! C", not just the first one.
>
> Can you please provide more of the actual output you are seeing?
> svn merge -accept theirs-full https://svn/repo/trunk/web .
[ many successful ]
G foo/Bar
svn: Attempt to add tree conflict that already exists at apple/
banana.xml
svn: Error reading spooled REPORT request response
> svt st
! C apple/banana.xml
! C apple/grape.xml
! C apple/orange.xml
! C apple/kiwi.xml
That's more or less what we're seeing.
What I'd rather see, is :
> svn merge -accept theirs-full https://svn/repo/trunk/web .
[ many successful ]
G foo/Bar
svn: Attempt to add tree conflict that already exists at apple/
banana.xml, apple/grape.xml, apple/orange.xml, apple/kiwi.xml
svn: Error reading spooled REPORT request response
>
>> Could svn be changed to report all of the items that are tree
>> conflicts, not just the first one (or not just a single one) ?
>
> It should report all of them, during update, merge, and status.
>
> Have you run 'svn status' on the working copy?
Yes, results as about. I can triple confirm that there were zero
outstanding commits before beginning the merge; the working copy was
pristine.
> It should list all tree conflicts.
It does list all the tree conflicts, by the message issues by the
aborting svn-merge does not.
> If you want help with analysing
> the conflicts which are happening, please post the entire output
> of merges you are running, with the output of 'svn status -v' before
> and after any merges.
Actually, all of this is symptomatic of my root issue : subversion
1.6.6(dev) has issues with three conflicts that I would hope it could
sail past.
>
>> I appreciate that resuming a merge is somewhat non-standard too, but
>> we have no choice here if we're trying to get past this issue.
>
> Note that any existing tree-conflict victim will be skipped by a
> subsequent merge. svn assumes it's not safe to do anything to them.
> You should probably resolve all tree conflicts before running
> another merge.
We witnessed that the only way to get a merge to carry on with such
tree conflicts (marked with "! C" in a svn st) was to mark them as
resolved.
>
>> What we'd really love is the ability to respond via std-in with a "P"
>> for pend, in respect of tree conflicts, and deal with them after the
>> merge invocation.
>
> http://subversion.tigris.org/tasks.html#tree-conflicts-ui
Thanks.
- Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395642
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-16 18:51:11 CEST