User: Password:
|
|
Subscribe / Log in / New account

Lessons from PostgreSQL's Git transition

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 11:54 UTC (Wed) by lmb (subscriber, #39048)
Parent article: Lessons from PostgreSQL's Git transition

So, Postgres switched, but it took them longer than the slightly larger Linux kernel project. I'm not sure that is something to be proud of.

Beyond CVS conversion oddities (sure, those suck), their install seems to do without the most powerful features of git - no merges, no author/submitter history, etc. In fact, it appears they are using it as a centralized and linearized CVS replacement, for which they might as well have used SVN (except for storing full local history).

In particular the "no merges" bit is really weird. For review, reviewing the history of a feature/bugfix in an offered pull tree would appear to be much better. I could understand an "I'll not merge if there are conflicts to resolve" policy, but that?

Yes, of course, it takes a while for people to adjust, but I think this is self-inflicted to a degree; a number of the problems (short of the conversion madness, but that's a one-time effort) seem to stem from the desire to not fully adopt git. (Which explains why specialized documentation for the project is needed, etc.)


(Log in to post comments)

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 12:03 UTC (Wed) by marcH (subscriber, #57642) [Link]

> So, Postgres switched, but it took them longer than the slightly larger Linux kernel project. I'm not sure that is something to be proud of.

I do not recall Linux ever using CVS.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 12:32 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

You are correct. Linus went so far as to state - on the basis of his experience using CVS at Transmeta - that passing around tarballs+patches was actually superior to CVS.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 13:53 UTC (Wed) by marcH (subscriber, #57642) [Link]

Exaggeration to get a point across? No, not that type of guy...

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 14:07 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Well, he stood by what he said and never used CVS.

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 12:45 UTC (Wed) by njd27 (subscriber, #5770) [Link]

When Linux was imported into git all history was thrown away so it's not a comparable process.

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]

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.

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.

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.

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 (guest, #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!

Lessons from PostgreSQL's Git transition

Posted Oct 13, 2010 19:19 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

So, Postgres switched, but it took them longer than the slightly larger Linux kernel project. I'm not sure that is something to be proud of.
That seems unreasonable. Git was custom built to complement the way the kernel developers wanted to work, not the way the Postgres project wants to work. That has a huge impact on how easy the transition is.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds