svn commit: r275122 - in projects/clang350-import: contrib/ipfilter contrib/llvm/lib/Target/Sparc/AsmParser contrib/llvm/lib/Target/Sparc/Disassembler contrib/llvm/lib/Target/Sparc/InstPrinter cont...

[John Baldwin]

On Monday, December 01, 2014 08:03:34 AM Steve Kargl wrote:
> On Mon, Dec 01, 2014 at 09:05:32AM -0500, John Baldwin wrote:
> > On Wednesday, November 26, 2014 02:36:05 PM Dimitry Andric wrote:
> > > Author: dim
> > > Date: Wed Nov 26 14:36:04 2014
> > > New Revision: 275122
> > > URL: https://svnweb.freebsd.org/changeset/base/275122
> > > 
> > > Log:
> > >   After some horrible wrestling with Subversion's worthless merge
> > >   implementation, merge ^/head r275078 through r275117.
> > >   
> > >   Note that all the extraneous mergeinfo is there because Subversion
> > >   created it.  I'll hopefully be able to remove it again when merging
> > >   back
> > >   to head.
> > 
> > To be honest, for merging back to HEAD, I'd probably just do it by hand.
> > We've been burned in the past by svn thinking it should copy modified
> > files from the projects branch into HEAD instead of doing a merge thus
> > losing history in HEAD.  Probably what I would recommend is trying to do
> > a merge, but reading the diff very carefully to ensure no modified files
> > are added wholesale and then explicitly remove any mergeinfo before
> > comitting (assuming you will only do a single merge at the end in which
> > case the mergeinfo would be useless anyway)
> 
> Isn't this backwards?  The initial commit (and testing) should be
> done in HEAD, and once it is proven to work, the commit is then
> merged into the branches.

This is for a projects branch (such as the one here where dim@ is testing
the clang3.5 import), not for stable branches.  For stable branches, yes
changes must go through HEAD first.

-- 
John Baldwin