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

[Greg A. Woods]

At Sat, 10 Mar 2012 19:04:15 -0500, Charles Lepple <clepple at gmail.com> wrote:
Subject: Re: [Nut-upsdev] some fixes, improvements, and new features (EPO and DYING) for 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.

I don't understand.  That's not a problem for a one-time conversion.

The simple procedure I outline in my Git notes covers the conver
entirely if it only needs to be done one time.

Same goes for tags.

There might be some old tags that can be removed, and of course the
files which should not be tracked can be removed too, but that kind of
cleanup can be done either before the conversion or after -- just so
long as it gets done.  I.e. it doesn't have to be done during the
conversion, and doing it during the conversion so might even be a bad
thing in that it might get hidden.

> 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.

OK, that could be something useful, but personally I would not want to
try to do that in any project I converted, even if I used a tool that
made it possible.  History is just that, history.  :-) Besides, I
personally think it would be an awful lot of extra effort for relatively
tiny insignificant gain.  There are nearly 3500 changes in SVN now.


> 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.

Is it important to try to mark old merges that have happened long ago?


-- 
						Greg A. Woods
						Planix, Inc.

<woods at planix.com>       +1 250 762-7675        http://www.planix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120311/76d9834d/attachment.pgp>