Fredrik Orderud wrote: > Over the past year, there have been several discussions regarding undesirable > side-effects of the currently (too) "permissive" merge mode on this list. As > of today, subversion will silently discard changes (instead of signaling a > conflict) under certain merging scenarios. > > One such problem is out-of-order merging of repeated added & deleted changes, > where changes can easily be lost on the target branch despite svn:mergeinfo > claiming that everything has been merged [1]. > > At my employer, we have a post-commit code review & approval scheme. Under > this scheme, developers are free to commit to trunk. Afterwards, all > changesets are reviewed and approved before being merged to a release branch > containing only "approved" changes. This scheme results in a lot of > out-of-order merging, since the time delay for code review and approval > varies a lot. We have therefore encountered issue #4405 [1] several times the > last year. I find this loss of changes rather worrying, since it happens > silently without any conflict or error message. It is therefore very > difficult for end users to identify this "data loss". > > The previously proposed solution for this problem has been to add a new > "strict conflicts" merge mode. I very much like this idea, and would like it > to get increased attention if possible. > > Could if be possible to add "strict conflicts" to the most wanted list on the > Subversion roadmap webpage?
Hi Fredrik. Yes, I don't see why not. I know others want this enhancement, and I do too (and I intend to do something about it in the not too distant future). We don't have strict rules for what features get added to the "most wanted" list. If nobody objects, I'll add that to the list later today. (I notice that we also need to update the list and push back many of the milestones already on it.) Please note that a work-around exists: you can plug in a third-party merge tool that provides the desired behaviour, if you have one. I just added a comment to the issue, in which I mention that. > [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4405 - Julian
