>>> As a thought experiment, how difficult would it be to release 1.6
>>> without tree
>>> conflicts?
>> TODO: Take out TC code and tests, restore old error messages
>> (that we replaced with TCs), and tweak old tests that create
>> TCs inadvertently.
>>
>> A few hours, I guess. I think we could safely plan to branch
>> Wednesday evening.
I humbly disagree, I think it would take a little longer than that. The
tests mending alone would be quite stupendous and time-consuming. I'd say
three days at least?
> Whoa, pard'ner! My comments were a bit drastic, too be sure, so I hope you're
> not now frantically working to pull every shred of tree conflicts from 1.6. I'm
> just curious as to what the effort would be.
>
> And note that when I say "pull tree conflicts" I really mean "remove the bits
> which aren't finished and which couldn't ship Real Soon Now."
Julian suggested that it would be feasible to disable tree-conflicts
detection upon update and leave it in for merge (I'd think it's possible
within very short notice, a couple hours for this one). TC on update are
inherently more complex than merge, because they need to take care about
updating the base or not. Update holds the bulk of bugs/problems. Merge is
simpler as it only results in local mods.
I like what Mark said:
- Tree-conflicts do look good in many cases, and
- Tree-conflicts are *very* complex and may need to grow gradually beyond
1.7 anyway.
I feel that we've been hunting corner cases in tree-conflicts for a long
time now. The core works. The problem being the vast number of possible
corner cases. And in some cases "what happens after" is still unanswered.
It remains inherently difficult to form a firm opinion on it. I keep swaying
both ways... I think it'd be best to have preferably unknowing people to
take on tree-conflicts scenarios, as stsp tried, and see what they say (see
the thread following
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=145317
), in order to get very specific reasons for either decision.
For example, it would be very helpful if any developers out there could take
the current trunk and carry out two complete, typical conflicting Java code
refactorings, and try to merge them either via "merge" or via "update",
including all resolve/resolved/revert steps necessary.
We are happy to assist. It would be good if someone out there did this,
deliberately trying to get as confused as possible, because us TC folks know
too much about tree-conflicts to be impartial.
Thanks!
~Neels
Received on 2008-11-18 04:46:55 CET