trouble merging 6.11.1 into 6.11.2

Moderator: pouillon

User avatar
Posts: 504
Joined: Mon Aug 17, 2009 9:25 am

trouble merging 6.11.1 into 6.11.2

Post by jzwanzig » Mon Nov 21, 2011 6:17 pm

I've just branched my 6.11.2 branches using bzr-get-branches, and am attempting to merge my 6.11.1-private branch in (which is committed and passes tests on my local machine, but is not yet complete enough to make public). However, this procedure makes significant changes in various files like haydock.F90, which, when I try to fix, leads to more and more problems. This really puzzles me because I've never worked on the GW parts of the code, and I don't really know what to do next. Any suggestions would be very welcome.

Josef W. Zwanziger
Professor, Department of Chemistry
Canada Research Chair in NMR Studies of Materials
Dalhousie University
Halifax, NS B3H 4J3 Canada

User avatar
Posts: 651
Joined: Wed Aug 19, 2009 10:08 am
Location: Spain

Re: trouble merging 6.11.1 into 6.11.2

Post by pouillon » Tue Nov 22, 2011 1:45 pm

I would have been tempted to say that it happened because you didn't merge trunk for a while, but this is obviously not the case.

If you've installed kdiff3, you can use my bzr-resolve script (found in extras/bzr_helpers/). Just remove plugins.conf, it should not exist anymore. Solve the conflict in fallbacks.conf as you wish, you'll revert it later. In all cases, select file "B" whenever possible or in doubt.

You'll then have to "bzr revert" many files that should not have been deleted, as well as all files in config/, .bzrignore, and fallbacks/config/specs/fallbacks.conf, plus all files in tests/ you didn't modify yourself. Then check that everything is OK with "bzr qdiff" or a similar tool.

I frankly don't know why you got this. There has been a serious mistake somewhere, and I can't figure it out. Might be a peculiar criss-cross, but this is not sure at all.

I tried different merge algorithms without success, which means that you'll really have to do most things manually. An alternative to the merge would be to import manually your changes from 6.11.1 into 6.11.2.

Please remember that as long as this is a development version, only Abinit developers will be affected by your changes. Once your branch goes green on the test farm, the earlier it's merged into trunk, the better, regardless of completeness, beauty and/or perfection. This is also a very good way to know ASAP whether your developments interfere with those of other developers. Then, the x.2y.0 versions give you time to polish your developments or disable them if really they're not usable.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain