Charles Lepple <[email protected]>: > A complete defect report would be great, but bear in mind that the > reposurgeon code has changed drastically in terms of what it is > trying to do automatically, and as such, I am hesitant to finish > traversing the other several hundred commits until I have an idea of > what you are planning to do next.
Fair enough. I suppose from the outside it's difficult to tell that the objectives are not changing as fast as the implementation. I have reproduced the apparmor branch problem and am pursuing it. > I think that given the NUT project's acceptance of SVN's > shortcomings, we tended to merge infrequently. This is probably why > the git-svn conversion is our "90% solution" - git-svn does not > attempt to reproduce SVN merges, and since it is not trying to alter > the topology of the repository, there seems to be a lower risk of > lost data. This sort of concern is why one of reposurgeon's design rules is "never throw away data unless the user tells you to". In particular it is why when I junk a copy or tip-delete commit it turns into a tag instead of vanishing - you have to *tell* reposurgeon to dispose of it with a "delete obliterate" > In terms of where I would want to spend the most time for a > high-quality repository conversion (for NUT in particular), it would > be to enable easy manual merges, with the option to tell > reposurgeon, "I know what I'm doing - ignore the sanity check". merge = attempt this merge and report if it's clean, merge perform = do this merge, merge perform force = do this merge ignoring sanity checks It's already designed exactly the way you want it. > Automatic merge detection is an unexpected bonus, provided that it > preserves the integrity of the repository. To be honest, I'd rather > have reposurgeon present a list of automatically-detected merge > points that I could choose from (especially during an incremental > refinement process like this). There is no danger to the repo integrity from *detection*; only when we actually edit merge points. That's why "merge perform" is separate from "merge", so that you can know the former won't perform any write operations. >Maybe it can do this already - I haven't looked at the code that >closely, because the little time I have had to spend on this has been >focused on inspecting the output. Automatically detecting *all* potential merge points is expensive - worst case is O(n**2) in the number of commits. The workflow is designed around the assumnption that a human will identify potential merge points, test them with "merge", and if they're clean di a "merge perform". > Does reposurgeon take commit IDs as parameters to the merge command, > or is it better to just describe the definitive merge points in > terms of the commit messages? The command can take either. Here's how it works. If I say, hypothetically, merge :1234,:5678 the expression on the right evaluates to a two-element selection set. The merge goes from the earlier to the later commit. Similarly if I write merge <2010-10-18T11:46:[email protected]>,<2011-08-18T11:42:03Z> though this form is preferable because, while marks can become displaced by a renumber operation, references by date should always be good unless a date is explicitly edited after the reference is written down. (It is not necessary to append the submitter unless there are multiple commits with the same time/date.) OTOH, if I write merge /I am a merge source commit/|/I am a merge target commit/ what's actually happening is a bit subtler. Each // is a text search that yields a selection set. With the '|', I form the union of the two selection sets. If both text searches refer to unique different commits, the result is a two-element set; otherwise merge throws an error. The date/time and text-search forms are most stable under repo surgery. The text-search form is IMO easiest to understand. I normally use it, falling back to date/time if I can't identify unique comment text to key on. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
