--- Stefan Sperling <stsp_at_elego.de> wrote:
> 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?
I've just spent a couple of days with Paul and Mike and although we weren't
specifically discussing tree conflicts I've gained a much better general
understanding of how merging works in Subversion. I think I can now see how
far we have to take this conflict detection, and it's not too far.
> 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?
Just a brief note on the rest of your questions: I'm not right back into this
in detail, but yes I think Nico was right on simplifying that case. On the
subject of renames, yes I think we can and should proceed with detecting
conflicts to the same degree (or lack) of sophistication that "svn merge"
already does (or doesn't) cope. I think this is feasible and useful.
- Julian
>
> 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 :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-19 03:27:00 CET