[Nut-upsdev] reposurgeon progress

[Charles Lepple]

On Jan 9, 2012, at 12:58 AM, Eric S. Raymond wrote:

> This is a consolidated reply to your four most recent emails.
> 
>> I am trying to leverage reposurgeon to automate the process of finding merge
>> points, and I seem to be spinning my wheels. Can you provide an example of how
>> you are searching for merges?
> 
> Not a working one, yet.  That code is buggy.  It's my next thing to work on.
> 
>> reposurgeon% merge (apcsmart-dev)
>> reposurgeon: :11392 cannot merge clean at target :11808
>> reposurgeon: target :11808 is out of date on these files: docs/man/apcsmart.txt drivers/apcsmart.h drivers/apcsmart.c
>> 
>> # This doesn't seem to be the right merge point, but maybe that's because '(apcsmart-dev)' represents the whole branch.
> 
> That's correct. <apcsmart-dev> is the syntax to reference the tip commit.

Ah, I got it backwards - I assumed that <apcsmart-dev> was the root of the branch, not the tip.

>> I am not sure why this merge is so far down the trunk - it was definitely 
>> merged before v2.6.2.
> 
> As I said, the merge code is buggy.  It's one of the two algorithmic issues
> I still need to work on.  After I fix the things that are plain bugs.

Can the selected merge points be used as-is with "force", or will that only help cases where the algorithm says a merge isn't possible?

>> I'd add this to the list: "5. with multiple fossil references in a line, only
>> the first gets lifted."
> 
> I've already dealt with the problem this would solve by inserting line feeds
> where the action stamps need horizontal room.

This is separate from the cosmetic issue of line length. In vi or sed terms, this is like using "s///" where "s///g" is needed (but the reference lifting code seems to be looping over the commit message in a way that I don't quite follow). In the converted repository, we shouldn't see any output from 'git log | fgrep '[[SVN:'. It might be just the first in the commit, rather than the first on the line, which is getting lifted.

>> I think it might be time to revisit the alternate style I proposed a
>> while back (which can probably be handled through editing *.box) where
>> we use a footnote-like syntax. If this were automated (and I wouldn't
>> mind taking a shot at it) we could also add short Git hashes to help
>> with quickly navigating through the tree in gitk (since they turn into
>> clickable links).
> 
> This is a cosmetic issue.  Hold that thought, and let's revisit once I
> have the implementation bugs fixed and the algorithmic stuff solved.

Will do.

>> Long-term it might be nice to patch gitk to understand your commit ID format.
> 
> I'd do that if I undertood the gitk code well enough.  But it's pretty hairy,
> and my Tcl-fu is weak. How's yours?

I was thinking more in terms of figuring out a sneaky way to get a gitk developer to do the work :-) But that might be hard if they don't have to deal with legacy SCM systems much.

>> I'll look to see how we merged branches/Testing and trunk.
> 
> Please do.  Giving me a good grasp on how the topology of the git
> commit graph is wrong in those cases will be essential to getting it
> right.
> 
>> I just discovered that the svn:ignore properties are not converting to
>> .gitignore files properly. It looks like the regression happened between
>> 2.0-pre4 and -pre5, although it could well be that the configuration files
>> bundled with those versions are deleting the necessary metadata.
>> 
>> In the git output of 2.0-pre5 and later, all of the .gitignore files
>> contain the following:
>> 
>> Makefile
>> config.log
>> config.status
>> 
>> even the ones in subdirectories where config.log would not be expected.
> 
> Hmmm.  I instrumented reposurgeon to show all instances of .gitignore
> generation, and I'm not spotting any that are obviously wrong to me.


Working backwards, then: are you seeing the symptom on your end? (That is, all of the .gitignore files have the same content - where the one under drivers/, for instance, should have a list of the driver executables that won't be present in other directories). The smallest interval I narrowed the regression down to in the history of reposurgeon is 2.0-pre4 to 2.0-pre5, but I did not start looking at the differences in the configuration yet.

I won't have much time today to look at this, but I will definitely download the new tarball and check everything later.

-- 
Charles Lepple
clepple at gmail