Re: Tree conflict detection in 'svn merge'

On Fri, Feb 29, 2008 at 12:20:47AM +0000, Julian Foad wrote:
> It sounds like we're trying to define what merging means (with respect to
> what target corresponds to what source), and I don't know whether we're
> defining it correctly.
>
> In fact, this algorithm is a fundamental part of merging.
>
> I'm afraid my knowledge of merging is not yet up to the task of analysing this.
>
> I'll see what I can do, but to begin with that mainly means getting help
> from someone who knows about merging.

Julian,

I'm currently reading through the archives, trying to get an idea about
the current state of merging and tree-conflicts. I have some comments
and questions for you and everyone else interested:

Have you found someone informed about the details of merging
who is willing to help us analyze the issue yet?
Would anyone on the list reading this volunteer to do so?

It seems that part of Stephen Butler's rather elaborate plan about
use cases 4 and 5 in notes/tree-conflicts/detection.txt has been
made obsolete by comments made by Nico, stating that at least use
case 4 could be detected in much a simpler way. Can you confirm this?

If so, I think we should update detection.txt to reflect the current
status. I could try to modify the document accordingly and post a diff
for review, also because this would help me getting back into the loop
again after having been busy with other things than tree-conflicts
for a while. Should I do that?

Have you yourself made any advances in analysing the issue?
If so, would you mind sharing your thoughts on the list?

Having read some of the comments made by you and Nico, especially
about relating source items to target items during merging, and the
new use cases proposed by Nico, I keep thinking "Oh man, if only we had
true renames, all this would not be such a big issue...".
Do you feel the same? Do you think it's feasible trying to carry on with
implementing tree-conflicts detection without true renames?
I don't want to sound pessimistic here, far from it. I'd just like to
know whether others had or have similar thoughts on this.
Obviously, a true-rename implementation would open a whole different can
of worms and is way outside the scope of the tree-conflicts branch.
I'd still like to get at least a faint idea about to what degree true
renames would help in reducing the complexity of the problems the
tree-conflicts branch has to deal with. I've already written about what
true renames would mean for our update and switch use cases in detection.txt.

I'll be able to work again full-time on tree-conflicts for the next
four weeks at least. I hope we can get past the design phase during
this time and hopefully get some code written. I'm motivated to do so,
anyway. Oh, and don't worry, I'm not saying that I'd push for writing
code before the design is solid. I'd just very much like us to get there :)

Thanks,

-- 
Stefan Sperling <stsp_at_elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner