Hi, Stefan,
Thanks for your feedback! Please see my response inline.
On Fri, Jul 21, 2017 at 2:16 AM, Stefan Sperling <stsp_at_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,
Received on 2017-07-21 20:45:12 CEST