Lessons from PostgreSQL's Git transition [LWN.net]

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 14:36 UTC (Wed) by lmb (subscriber, #39048) [Link]

Point taken, though that too is a (possibly) viable process.

But from what I read here, the main point of contention was not the cvs2git conversion (which always is trouble, since CVS just doesn't have all the data one would like - if it did, it wouldn't suck so much), but the processes etc surrounding it afterward.

Switching to a distributed VCS, and then rejecting one or two of the main aspects - distributed development and merge capabilities - to restrict it to CVS-like work flows seems somewhat weird, and I'm not surprised that such an attitude carries with it a lot of self-fulfilling prophecies.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 15:00 UTC (Wed) by alvherre (subscriber, #18730) [Link]

The processes were difficult, but the actual CVS-to-git conversion was pretty problematic too, and required quite a bit of tweaking of the CVS repository (see this mailing list message for the details) and help from the cvs2svn developers.

We've already switched. We're not going back. As people said above repeatedly, changes in workflow will come in time.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 18:41 UTC (Wed) by iabervon (subscriber, #722) [Link]

If you look more closely at what they're doing, they've actually been doing distributed development for a while; they just do it without VCS support, and admit changes to the project state in a centralized fashion. Leaving aside how the published project state gets updated, they've been emailing context diffs to the mailing list and revising them. It's a small step here to use git to keep track of what you're doing with a patch set (especially with the base state published in git), and to use git to communicate changes to reviewers. And then you find that you've got your unaccepted changes in a form that your build farm is (technically) capable of testing, and maybe you could switch to regression testing commits before updating the public repository instead of after. And then maybe you start having the reviewers see what version the author has based the patch on, and think about whether any of the features accepted since matter to that, instead of thinking that either "patch" or people will find conflicts in functionality.

In any case, they're very much not coming from a centralized development background, where people don't communicate code to each other except through the central repository.

Lessons from PostgreSQL's Git transition

Posted Oct 20, 2010 7:24 UTC (Wed) by augustz (subscriber, #37348) [Link]

There are a significant number of weaknesses in cvs, especially for software like Postgresql that would benefit from reasonable version control, beginning with atomic commits and I won't bore you with other CVS oddities.

So git, WITHOUT changing from a CVS style workflow, is going to be much nicer for the project to use as their authoritative vc. So switching to git while keeping CVS workflow is not weird at all. It will improve results for the project.

Not adopting all gitisms at once is also not weird. Any larger organization moves slowly, rightly I think personally. They have an approach that works well. Let's wait a year for things to shake out before worrying about going with all the gitisms.

Credit also goes to the project for respecting the consensus that developed which was to switch to git without abandoning work styles. If you read the discussions, this was important to a number of committers and I think a good thing to respect. The value of the commiter I think outweighs adopting a specific ism of a specific tool.

Thanks for a good write-up Josh!