On Tue, 23 Oct 2007, David Fetter wrote:
If Mercurial has a similar migration/legacy support path, then by all
means, let's try that out, too.
There's an import tool at http://hg.beekhof.net/hg/cvs-import but the
experience of the Mozilla project suggests it's on the buggy and slow side
for large repositories with lots of history:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
http://code.google.com/p/msysgit/ but it's not quite there yet; there's
also a partial MinGW port.
The way I suspect any plan for incorporating a new [D]VCS on a larger
scale in this project will need to progress is like this:
1) Make a converted copy of the existing CVS repository
2) Keep the mirrored repo up to date with new commits
3) Provide working guidelines so that developers can use the new VCS to
build local patches and improve their productivity
4) Get enough developers using the new system that it becomes a popular
way to increase visibility on work in progress patches
5) Reach a critical mass of developers showing improved productivity on
the new system to sway the core toward that particular VCS
6) Convert the main repository to the new VCS
Git has reached (2) already. I started documenting a process for using
Subversion, it would only take a little more work on
http://developer.postgresql.org/index.php/Working_with_CVS and that would
hit (3). I personally don't think there's enough potential for gain
converting to SVN to make it worth the trouble, which is why I haven't
bothered doing more there.
Mercurial/Monotone/Bazaar are all interesting possibilities as well, but
it will take an advocate willing to start down this trail for a particular
tool to kick off a serious investigation of any of them.
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend