Hi, Stefan, Thanks for your feedback! Please see my response inline.
On Fri, Jul 21, 2017 at 2:16 AM, Stefan Sperling <s...@apache.org> wrote: > On Thu, Jul 20, 2017 at 08:01:55PM -0700, Xin LI wrote: > The FreeBSD repository is one of the best real world data sets available > to Subversion developers. I have referred to it several times while > working on the new conflict resolver planned for Subversion 1.10 and > have spent days running test merges against this repository. > The repository shows many difficult and interesting problems we would > normally only see in repositories that are locked up inside companies. > > While some of the problems I have seen are due to limitations of SVN, > I believe most problems FreeBSD developers have with SVN are self-made. > FreeBSD developers in general do not really understand the tool and > don't know how to work arounds its weaknesses. The FreeBSD handbook has > a section on Subversion which is full of bad advice and half-truths. I guess you mean this article? https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer.html Could you please be more specific with the bad advices? (It would be very helpful if we could have fixed these documents and/or practices, if possible; I'll take a look at the premier to get the issues raised in EuroBSDCon 2014 tutorial addressed). > I wish there was more communication between the FreeBSD and Subversion > projects about such issues, but such communication is virtually never > existed. (I may be wrong, but I think you are the only FreeBSD developer > posting on this list -- thank you!) I think there are other FreeBSD developers on this mailing list. > At EuroBSDcon 2014 I offered a special SVN tutorial for FreeBSD developers. > There were many participants but *nobody* of them were FreeBSD developers :( > There was a clear lack of interest for this kind of communication. > So the tutorial didn't go as planned and no interesting conversation happened. > You can still find the tutorial here (one of your own bad merges was discussed > in there, too, I believe): https://stsp.name/eurobsdcon2014-freebsd/ I didn't knew this tutorial before, and thanks for taking time to do the analysis and sharing. So if I understood correctly, when doing a vendor import with file renames, in addition of doing 'svn mv's in the vendor tree [quick question: is there some semi-automated way to do this?], the developer should also handle the merge conflicts differently in the development trunk, by replaying each merges with: svn revert <old file> # Restore the file to before merge state svn rm <new file> # Remove new file in preparation of actual merge svn mv <old file> <new file> # Move old file to new location svn merge --accept postpone ^/vendor/.../<old file>@<vendor commit -1> ^/vendor/.../<new file>@<vendor commit> <new file> Then do a 'svn propdel svn:mergeinfo' on these new files? [Do we need to do similar changes when merging to stable/?] And am I understanding correctly that the benefit of doing this is that the new files now get the same change history line from development trunk, instead of as a continue of the vendor history, and also avoided missing changes that happen in development trunk but not in vendor area (or development trunk)? Thanks in advance! Cheers,
