On Mon, Jan 23, 2017 at 11:29:03AM -0500, Kris Deugau wrote: > I've been maintaining a set of spam filter rule files in Subversion for some > time. On the client side this has been almost entirely with 1.6.x on CentOS > 5. > > I've just recently done a major refresh on my PC, switching to the current > Debian stable release, with Subversion 1.8.10. > > The directory structure I've suddenly found I've been merging incorrectly > looks like: > > dev/ > file1.cf > file2.cf > file3.cf > ... > prod/ > file1.cf > file3.cf > ... > > (Note a small number of files were added in dev/, but have not been copied > to prod/. IIRC the few files added to SVN in dev/ but not prod/ got added > by the merge, then revert'ed, then OS-rm'ed.) > > dev/ and prod/ were created at the same time, in r1. Files were created in > dev/, then svn cp'ed to prod/. > > With the old 1.6 client, I was able to "svn merge ^/dev" in prod/, and it > did what I expected; merge all changes to the relevant files (and add the > occasional new file) from dev/ to prod/. merginfo is only maintained on the > prod/ directory, not individual files. > > With 1.8, it's now complaining that dev/ and prod/ have no common ancestor. > > What can I do to get unstuck? > > -kgd
You could use the --ignore-ancestry option but because this disables merge tracking you'll also either need to specify one or more revisions to merge, or use the 2-URL merge syntax. See 'svn help merge' for more details. For the long term, I would recommend to reconcile the branches, then delete one of the branches and recreate it as a copy of the other.