On Jan 23, 2012, at 9:37 PM, Eric S. Raymond wrote: > Charles Lepple <[email protected]>: >> Hmm, I still see the wrong content in the final >> scripts/augeas/*.aug.in, although the merge from Augeas into the >> trunk is not indicated. (That merge point on the last pass was >> correct, IMHO - but the final merged *.aug.in files should have >> @CONFPATH@ instead of /etc/nut after the trunk merge - see my >> previous email.) Tested with commit c023d35 to reposurgeon.
Per your other email, I was using c023d35 in reposurgeon, plus d5cfc7ec in nut-reposurgeon. When I was testing with 147ce9ee in reposurgeon (one before c023d35), I saw SVN commit 2781 expressed as an Augeas-to-trunk merge. With c023d35, it is no longer indicated as a merge in the nut-git output, but there is still a problem with the file contents as described below. > Then we've probably got a two-point failure, with some bug or metadata > problem unrelated to the merge. I stupidly assumed that since you > were reporting content from the wrong side of the merge, filtering > out the invalid merge would do the trick. Now I suspect there's > something funky happening on the trunk side. It's slightly more nuanced than "wrong side of the merge" - more like something from the middle of the Augeas branch. Here's a breakdown of the events (with SVN revision numbers): trunk@2367: Before Augeas branch was created, there was no scripts/augeas/ directory. Augeas@2368: Looks like a server-side copy created the branch (no fileops) Augeas@2373: Added initial versions of scripts/augeas/*.aug (with hardcoded paths to /etc/nut) Augeas@2769: The scripts/augeas/*.aug files are renamed to scripts/augeas/*.aug.in, with autoconf-style substitutions. Augeas@2780: Merge from trunk@2779. At this point, the *.aug.in files still look good, and the reposurgeon trunk-to-branch merge looks okay. trunk@2781: Merge from Augeas@2780. This commit seems to get the contents of the *.aug files (but stored in the *.aug.in files) from before Augeas@2769 (badness ensues) > And it really was an invalid merge - copy of a subdirectory rather than the > entire branch. Well...semantically it was a valid merge, but one that > can't be expressed in gitspace. We may run into more of those. This is one aspect of the git fast-import stream that I still can't seem to wrap my head around. Git represents each revision as a set of files in time, with the only file "history" being the topology of the commits themselves. A merge commit, as I understand it, should simply be a snapshot of the files after they were merged. It is up to front-end tools like gitk to reconstruct the three-way diff or perform rename detection when requested. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
