[Nut-upsdev] some fixes, improvements, and new features (EPO and DYING) for NUT

[Charles Lepple]

On Mar 9, 2012, at 2:43 PM, Greg A. Woods wrote:

> At Thu, 8 Mar 2012 23:01:39 -0500, Charles Lepple <clepple at gmail.com> wrote:
> Subject: Re: [Nut-upsdev] some fixes, improvements, and new features (EPO and DYING) for NUT
>> 
>> On Mar 8, 2012, at 6:21 PM, Greg A. Woods wrote:
>> 
>>> Here are a series of my recent changes to NUT.
>>> 
>>> The first few in the set are primarily little fixes and improvements.
>>> 
>>> In among those are a few for .gitignore files which of course you can
>>> ignore for SVN, and there's one for a commit to a generated file which
>>> of course should not be tracked in any VCS.
>> 
>> We are actually in the process of trying to move the NUT source code
>> over to Git, but both conversions by git-svn and Eric S. Raymond's
>> reposurgeon are not quite there yet. (We are leaning towards
>> reposurgeon, which involves a little more tweaking of commits, but
>> produces better results for a one-way SVN-to-Git conversion, including
>> .gitignore files generated from svn:ignore properties.)
> 
> You might want to look at "git svn" in the latest release again.

Anything in particular? I have been incrementally running 'git svn fetch' and 'git svn rebase' to generate the tree at https://github.com/clepple/nut

One problem is that git-svn's method of generating the .gitignore (or .git/info/exclude) files is static. I can run it in my local tree, but as you have seen, there have been some atrocities related to mechanically generated files in NUT, and many of those files were originally static files. Eventually, it would be nice to check out a Git commit with the .gitignore files applicable to *that* revision. reposurgeon can bake those files into the generated repository.

Another thing I like about the reposurgeon concept is the ability to reformat the commit messages. ESR published some diffs when he made a first pass through the repository, and I think it's a good idea to keep everyone honest. Many of the SVN commit messages were not word-wrapped, and the first line often said very little about the content of the commit.

There are a bunch of other features, including a tag relocation feature similar to the one you suggest, and the ability to mark merges that don't show up in older SVN metadata.

About the only hiccup that prevented us from using reposurgeon directly was that we had some really weird CVS-to-SVN conversion artifacts in the NUT repository that tickled some reposurgeon bugs. I think they're all worked out now, but I still want to do a few more sanity checks (checking out released versions, and comparing releases to the Git checkout), fix a few merge points, and reformat some of the "fossils" (references to SVN revisions) for readability.

If you are interested, all of the NUT+reposurgeon discussion took place on nut-upsdev.

http://news.gmane.org/find-root.php?message_id=%3c20120119122532.3300A42A46%40snark.thyrsus.com%3e

etc. (search for "esr" on gmane under nut-upsdev)

> Also, ignore all the half-assed half-brained ideas floating around out
> there on the internets abou how to use it.  Most of the people writing
> about it are only taking into consideration the most basic uses.
> 
> I've written up some more-or-less un-published notes on doing more
> complete conversions that were based on my work to make use of Git to
> maintain local changes to FreeBSD, yet another project that uses SVN.
> I've further refined them and the result I have now in my git-svn cloned
> copy of the NUT repository seems complete and fully functional, at least
> compared to what I can see of the SVN repository independently.
> 
> Here's a link to my notes:
> 
>       http://www.planix.com/~woods/git.html

Regarding sec. 6.1.2: 'git svn show-ignore' can be appended to .git/info/exclude, but you're right, it isn't cloned (hence my "local" qualifier above).

There are some good tips in that document, but some of those concepts might be better explained with diagrams or gitk screenshots.

-- 
Charles Lepple
clepple at gmail