[Nut-upsdev] Time for a distributed VCS?

[Eric S. Raymond]

Arnaud Quette <aquette.dev at gmail.com>:
> Charles has already applied the painless, rapid and metada-preserving
> approach: https://github.com/clepple/nut
> but he will probably elaborate more on this, and the last point (preservation).

Cloning...right, I see what he has done.  This is a normal mirror site
using git-svn.  It's a good start, but there are a couple of issues with
this kind of purely mechanical conversion.

One is that the Subversion r[0-9]* references aren't converted.  Instead, 
there are generated lines at the end of each commit comment like this:

git-svn-id: svn://svn.debian.org/nut/trunk@3320 72a954d1-e00c-0410-aa02-d9c7bb700a61

Another is that comments aren't massaged into git form - summary line plus
optional blank like and details.  Doing this requires hand-editing in a
way that isn't really practical without a support command similar to
reposurgeon's "edit multiline".

Another is that .cvsignore files aren't mapped over to .gitignore files.
Yet another is that git-svn does not detect rename and copy operations.

When I do a conversion, I translate all the artifacts from previous
VCSes so the resulting history looks much more as though the project
had been using git from day one.  Subversion reference cookies turn
into committer/date pairs; junk commits like 

f6d28c0cabca44449799fc53f81dec18ea72b351 "This commit was manufactured
by cvs2svn to create branch 'INITIAL_IMPORT_AQ'.

get removed entirely.  Rename and copy operations are reconstructed.
My tools also do better tag lifting; where git svn renders all Subversion tags 
as git branches, I turn them into actual tag objects.

> more than the DVCS battle, that is IMO already won, you may prefer to
> concentrate your force on the next gen Forge ;-)

Besides all those irritations you rightly mention, the one that bothers me
worst is lack of scriptability.  I *hate* the fact that conventional
forges force me (for example) to do clicky-dances on a web interface
to declare a releese - I think I ough to be able to write a release
script that generates an XML-RPC or JSON request...

I'm working the problem.  I've found a good base platform for a next
generation forge; it's an issue-tracker called "Roundup" with ten
years of field testing - the Python project uses it.  Underneath, it's
a manager for message queues that allowes them to be viewed and edited
though a web interface, mail gateways or via XML-RPC.

There are a couple more primitive features it needs before I can write
a forge in it.  I have a plan and a roadmap.  And, actually, it's
useful for me to know that nut-ups is looking for a better home; if
and when I spin up "Federation", I'll want real projects to move there
as test and demonstration.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>