>
> Yes, but as Julian describes, this is not a patch for whatever the
> problem is. It is a patch about how we treat errors in general. And
> it is certainly not a finished patch but it is a working demonstration
> of the concept.
>
> Paul, BTW, if this patch "works" does it reveal anything more about
> what the actual problem is so that work can happen towards fixing it?
Yes, we have been running it dry run mode (for us that means --accept
theirs-full) so we can speed to conclusion or witness the early-exit.
We get a ream of debugging output, that we'll use to complete the
merge (go through things, fix 'em, mark as resolved) before the commit.
The debugging output is extensive, and we could easily obfuscate
client client details, before uploading the patch to the issue or
posting it back to this mail list.
We think that you'll see from it enough to be able to model the
complete reproduction. Though we are left with some 30 files that
would otherwise have cause tree-conflict exists with svn client 1.6.5,
they are unrelated and most likely caused by multiple similar
operations that were on different change lists over the period of a
week or so. The difference between our team and regular subversion
users is that we are a "constantly refactoring Agile team" working on
more that one branch, and relying on broad daily merges to make sure
we don't lose work between releases. In this particular case, and
because of a delayed merge by a Clearcase team working on a library
that our trunk and branch team both depend on, we has waited a week
before starting the merge.
Personally, I only recommend true trunk based development for
centralized SCMs :-)
Regards,
- Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398947
Received on 2009-09-23 18:25:13 CEST