On 10/24/07, Greg Smith <[EMAIL PROTECTED]> wrote: > 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.
How up to date is the Git repos? Does it pull individual commits from CVS, or does it resync the whole history periodically? If so, what's the lag? An important part of (2) is that the mirrored repos be sufficiently up to date that using it for your dev work and producing patches doesn't put you significantly behind HEAD. I think the Subversion repos resyncs every six hours, but I'm not sure (strangely there's not a whole lot of information about it on the wiki). To me, six hours seems a little slow. If you hit (3) on Git I for one will gladly start using the Git repository for my dev work. I work on minor upgrades, not the major stuff, so I think the benefits of a distributed system might be slim for me (because I'm not going to be switching across large branches). But I'd be happy to give it a shot. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
