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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The right to buy weapons is the right to be free.
-- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December
1942
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
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 at 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>