[Nut-upsdev] Time for a distributed VCS?

[Arnaud Quette]

Hey Eric,

long time no see...

2011/11/26 Eric S. Raymond <esr at thyrsus.com>:
> Recently, I've been working on tools for doing high-quality conversions
> of project histories from centralized version-control systems like
> Subversion to modern decentralized systems like git and hg.
>
> To see what I mean by "high quality", take a look at my DVCS migration
> guide: <http://www.catb.org/esr/dvcs-migration-guide.html>.  A really
> good conversion should, for example, rescue references like "r2317"
> in commit comments so that they still point at the right changesets
> inb the new system.
>
> In order to improve my tools, I've been actively seeking opportunities
> to help projects up-convert their repositories.  Recently I've done
> conversions for Hercules (an IBM mainframe emulator) and Roundup (an
> issue tracker).  I would be happy to perform the same service for the
> NUT-UPS project.
>
> I don't know whether there's been any discussion of moving the project
> off Subversion.  But maybe you (all of you) should consider it. Subversion
> was a good thing in its day, and certainly a huge improvement on CVS,
> but any modern DVCS really beats the snot out of it on just about any
> level - with support for code analysis, off-net operation, much faster
> speed of common actions such as commits, and in many other ways too.
>
> The way I can help is by making the conversion perfectly
> metadata-preserving, rapid and painless.  All three of these are
> difficult with an ad-hoc, by hand conversion, but easy with my
> repository-surgery tools and experience at the job. (And every time I
> do one of these my tools get a bit better in the process - that's *my*
> motivation.)
>
> By "rapid" I mean that I can do the conversion and cutover within two
> to three hours after an announced time. By "painless" I mean that
> users should have zero difficulties other than the relatively trivial
> one of learning how to say (for example) "git commit -a" rather than
> "svn commit".  I've already covered most of "metadata-preserving"
> earlier.
>
> As to which DVCS you choose: the easiest choice would be git, as my
> tools operate on git-import stream files.  If you want hg or bzr, that
> can be arranged with a very little more effort.  However, I must
> recommend against bzr; it suffers from some deep confusions about
> whether its working unit is an entire repo or a detached branch of
> one, and I find this makes it unnecessarily difficult to actually use.
>
> If you're ready to move, I'm ready to help.

thanks for your offer.
we've started work on this side already, using git.

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

On bzr, I have the exact same grievance:
2 days ago, I had to contribute a 20 Kb script. Branching for
committing starting to clone the full repo (500 Mb), which wasn't
satisfactory at all. so, I ended up breaking the checkout, doing a
diff and posting a patch as a bug report :-/

our problem, in NUT, is not much with the DVCS, but rather with the
hosting facility:
Forges, in general, are not that agile nor adapted to have a suitable
workflow for specifying, managing roadmaps and trackers, coding /
versioning, testing and delivering. Most satisfy one thing or another.
I like trac for the roadmap, github in general (AFAICT),
{g,fusion}forge because it's free, launchpad for blueprints+wiki spec,
(...),  but none of these bring the whole solution

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

cheers,
Arnaud