Re: PostgreSQL Developer meeting minutes up

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Markus Wanner <markus(at)bluegap(dot)ch>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL Developer meeting minutes up
Date: 2009-05-28 12:59:44
Message-ID: 20090528125944.GS15213@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas <robertmhaas(at)gmail(dot)com> [090527 22:43]:
> On Wed, May 27, 2009 at 10:09 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> > * Robert Haas <robertmhaas(at)gmail(dot)com> [090527 21:30]:
> >
> >> > And actually looking at the history of the gpo repo, the branches are all
> >> > messed up with "merges" and stuff that I'm not sure where they are coming
> >> > from...  8.2, 8.3, and master(HEAD) are all the same as my gpo repo, but the
> >> > back branchs are very bad...
> >>
> >> This is really quite horrible.  What is the best way forward here?
> >
> > That depends entirely on what the project wants.
>
> I can't speak for anyone else, but what I want is for the git tree on
> git.postgresql.org to match CVS.

Well, sure, but I think the "way forward" part implied recognition that
the current tree at git.postgresql.org *doesn't* match CVS very closely
(for back branches), and that people currently rely on it and use it.

So, again, the answer to the question really does depend on what the
"canonical" VCS of the project is. As of now, it's *still* CVS, and
those using either git repo can still develop and submit patches to CVS
easily.

When the project switches, there will probably need to be a more
canonical conversion, with one of the tools that doesn't support
incremental imports, and then people will have to adjust their current
repo with any of rebase/graft/filter-branch to adjust their work
history onto the "official" tree...

All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary, and possibly not even desirable... PostgreSQL
could just as easily to a "linus" style switch when they switch to git,
and just "import" the latest release in each branch as the starting
point for each branch. The git repository will have no history, and
people can choose which history they want to graft in... CVSROOT can be
made available as a historical download.

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-05-28 13:06:15 Re: Clean shutdown and warm standby
Previous Message Michael Meskes 2009-05-28 12:47:23 Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch