| |||||||||||||
Lessons from PostgreSQL's Git transitionLessons from PostgreSQL's Git transitionPosted Oct 12, 2010 23:08 UTC (Tue) by brouhaha (guest, #1698)In reply to: Lessons from PostgreSQL's Git transition by jberkus Parent article: Lessons from PostgreSQL's Git transition Subversion has a much better designed repository ("filesystem") that doesn't tend to accumulate a bunch of bizarre cruft the way CVS does. Exporting a repository from Subversion and importing it into another source control system is *much* easier than doing it from CVS. That said, I don't think that using Subversion as an intermediate step for a few years would have helped that much. It does sound, though, like you're trying to force Git to act like a centralized VCS. If that's really what you want, I don't think Git was the right choice.
(Log in to post comments)
Lessons from PostgreSQL's Git transition Posted Oct 12, 2010 23:16 UTC (Tue) by daglwn (subscriber, #65432) [Link]
Git is a fine choice for a centralized VCS. One can easily use it with the CVS/SVN model. The mistake is throwing away use of git's automated merging tools and doing it by hand. That's no better than CVS.
Lessons from PostgreSQL's Git transition Posted Oct 13, 2010 2:42 UTC (Wed) by yarikoptic (subscriber, #36795) [Link]
just my blunt 0.1 cents: SVN imho rests on an analogy which, at first sight, is user-friendly; but it impairs mind clarity to absorb the main notion of DVCS such as git and hg later on -- it is 'branch is just a directory, you can copy it'. CVS is closer to the notion of GIT/HG branches since there they still live in a "hyperspace" and are appreciated as such.
on the other hand, git-svn is such a handy tool with its bidirectional flow, that it makes "transition" much easier, whenever people could develop entirely in git and commit back to SVN.
Altogether, I think that direct jump CVS -> GIT was the right route; it could be only better if done earlier ;)
Lessons from PostgreSQL's Git transition Posted Oct 13, 2010 11:50 UTC (Wed) by marcH (subscriber, #57642) [Link]
Subversion tagging and branching (or rather: the lack of) is indeed a regression compared to CVS:
<http://en.wikipedia.org/wiki/Apache_Subversion#Subversion...>
With Subversion you basically end up having to manage tags manually in some external document. For fun search the Subversion mailing lists: you will find numerous people explaining how convenient is the lack of tags!
Lessons from PostgreSQL's Git transition Posted Oct 13, 2010 9:34 UTC (Wed) by cmot (subscriber, #53097) [Link]
| That said, I don't think that using Subversion as an intermediate step for a
| few years would have helped that much.
Remember that a big chunk of the conversion was in the support infrastructure. Having to revamp the buildfarm etc. infrastructure twice wouldn't have helped.
(I don't know the situation in the pg universe, but in Debian, quite a few administrators of support infrastructure are not intimately involved in development, so they may not see the ideas behind a change that means quite a lot of work to them...)
Lessons from PostgreSQL's Git transition Posted Oct 21, 2010 14:15 UTC (Thu) by jnareb (subscriber, #46500) [Link]
> Subversion has a much better designed repository ("filesystem") that
> doesn't tend to accumulate a bunch of bizarre cruft the way CVS does. > Exporting a repository from Subversion and importing it into another source > control system is *much* easier than doing it from CVS.
Unfortunately because of "branches are folders" idea, with non-enforced
Those mishandled SVN repositories are PITA to import to Git.
|
|||||||||||||