Re: Fwd: PostgreSQL 8.4 development plan

I wonder if the efforts to provide mirrors for many different systems can hurt later down the road. It is pretty obvious that amost every current system has options to convert from or to mirror a CVS repository. But what if we someday really want to use something else as the master repository? Are we ready to accept losing unsupported mirrors at that time, or will that actually influence the choice (I think that it should not ... but I can hear the outcry already).

Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

-----Original Message-----

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
Subj: Re: [HACKERS] PostgreSQL 8.4 development plan
Date: Fri Feb 8, 2008 7:15
Size: 773 bytes
To: "Brendan Jurd" <direvus(at)gmail(dot)com>
cc: "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com>; pgsql-hackers(at)postgresql(dot)org

Am Freitag, 8. Februar 2008 schrieb Brendan Jurd:
> In particular, if the git repos were officially supported, and best
> practises for use with Postgres documented, I think a lot more hackers
> would be comfortable using git to do their work, which is good for
> collaboration (as mentioned by Greg Stark and Heikki upthread).

Well, I didn't want to announce anything before anything existed, but this is
precisely what is being worked on. Watch for an announcement in this forum.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Feb 10, 2008 8:58 AM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> I wonder if the efforts to provide mirrors for many different systems can hurt later down the road. It is pretty obvious that amost every current system has options to convert from or to mirror a CVS repository. But what if we someday really want to use something else as the master repository? Are we ready to accept losing unsupported mirrors at that time, or will that actually influence the choice (I think that it should not ... but I can hear the outcry already).

If an SCM comes along so compelling in its feature set that it
convinces the Postgres committers to abandon CVS, I don't think anyone
will complain about having to use it =)

Seriously though, I think the main impetus for having these mirrors is
that developers don't want to work with CVS. If the master repos was
upgraded to a modern SCM, the importance of having mirrors would
dwindle.

Cheers,
BJ

On Sat, 9 Feb 2008, Jan Wieck wrote:

> It is pretty obvious that amost every current system has options to
> convert from or to mirror a CVS repository. But what if we someday
> really want to use something else as the master repository?

In order to export from CVS into one of the newer systems, there's a lot
of work involved. A typical problem is matching up all the commits that
happened at one particular timestamp and grouping them into a changeset.

Once you've crossed that hurdle, moving between newer tools is a lot
easier. Check out Tailor as an example for something that converts
changesets in between all the major tools:

http://wiki.darcs.net/DarcsWiki/Tailor

It should be much easier to run multiple types of repositories all in
parallel once CVS isn't one of them. And there will be more options for
easily moving to yet another system if the first choice proves wanting
after a while.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

On Feb 9, 2008 4:58 PM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> I wonder if the efforts to provide mirrors for many different systems can hurt later down the road. It is pretty obvious that amost every current system has options to convert from or to mirror a CVS repository. But what if we someday really want to use something else as the master repository? Are we ready to accept losing unsupported mirrors at that time, or will that actually influence the choice (I think that it should not ... but I can hear the outcry already).

The primary reason for a "hue and cry" to happen would require several
prerequisites:

0. An SCM would be chosen to replace CVS. Let us identify it as SCM1

1. The ones hueing and crying would have chosen an SCM, SCM2, that
was different from SCM1, and, furthermore, one where there isn't any
"tailor"[1] available to permit translation of patches between them.
(I'm not sure that any of the options that people are thinking about
*aren't* on tailor's supported list...)

2. There is a further requirement for this lead to a "hue and cry"
that needs to be listened to, namely that some complex and
non-migratable processes have been set up that depend on SCM2.

I think we can avoid this by declaring up front that its a Really Dumb
Idea to set up complex processes that depend on a particular
alternative SCM without the nice big fat caveat that "The PGDG has not
committed to migrating to any particular SCM at this time. Depend on
such at your peril!"

[1] Tailor <http://progetti.arstecnica.it/tailor> is a tool to
migrate changesets between ArX, Bazaar, Bazaar-NG, CVS, Codeville,
Darcs, Git, Mercurial, Monotone, Perforce, Subversion and Tla
repositories. It's "two-way" for a number of them...
--
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results." -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling

On Saturday 09 February 2008 22:51, Christopher Browne wrote:
> On Feb 9, 2008 4:58 PM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
> > I wonder if the efforts to provide mirrors for many different systems can
> > hurt later down the road. It is pretty obvious that amost every current
> > system has options to convert from or to mirror a CVS repository. But
> > what if we someday really want to use something else as the master
> > repository? Are we ready to accept losing unsupported mirrors at that
> > time, or will that actually influence the choice (I think that it should
> > not ... but I can hear the outcry already).
>
> The primary reason for a "hue and cry" to happen would require several
> prerequisites:
>
> 0. An SCM would be chosen to replace CVS. Let us identify it as SCM1
>
> 1. The ones hueing and crying would have chosen an SCM, SCM2, that
> was different from SCM1, and, furthermore, one where there isn't any
> "tailor"[1] available to permit translation of patches between them.
> (I'm not sure that any of the options that people are thinking about
> *aren't* on tailor's supported list...)
>
> 2. There is a further requirement for this lead to a "hue and cry"
> that needs to be listened to, namely that some complex and
> non-migratable processes have been set up that depend on SCM2.
>
> I think we can avoid this by declaring up front that its a Really Dumb
> Idea to set up complex processes that depend on a particular
> alternative SCM without the nice big fat caveat that "The PGDG has not
> committed to migrating to any particular SCM at this time. Depend on
> such at your peril!"
>

Would a pre-requisite for any new SCM to be anointed as *the* new SCM that the
buildfarm can be reconfigured to run with it? Unless there is an SCM2CVS
option available I suppose... how many SCM's support such a thing?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:
> On Saturday 09 February 2008 22:51, Christopher Browne wrote:
>> On Feb 9, 2008 4:58 PM, Jan Wieck <JanWieck(at)yahoo(dot)com> wrote:
>>> I wonder if the efforts to provide mirrors for many different systems can
>>> hurt later down the road. It is pretty obvious that amost every current
>>> system has options to convert from or to mirror a CVS repository. But
>>> what if we someday really want to use something else as the master
>>> repository? Are we ready to accept losing unsupported mirrors at that
>>> time, or will that actually influence the choice (I think that it should
>>> not ... but I can hear the outcry already).
>> The primary reason for a "hue and cry" to happen would require several
>> prerequisites:
>>
>> 0. An SCM would be chosen to replace CVS. Let us identify it as SCM1
>>
>> 1. The ones hueing and crying would have chosen an SCM, SCM2, that
>> was different from SCM1, and, furthermore, one where there isn't any
>> "tailor"[1] available to permit translation of patches between them.
>> (I'm not sure that any of the options that people are thinking about
>> *aren't* on tailor's supported list...)
>>
>> 2. There is a further requirement for this lead to a "hue and cry"
>> that needs to be listened to, namely that some complex and
>> non-migratable processes have been set up that depend on SCM2.
>>
>> I think we can avoid this by declaring up front that its a Really Dumb
>> Idea to set up complex processes that depend on a particular
>> alternative SCM without the nice big fat caveat that "The PGDG has not
>> committed to migrating to any particular SCM at this time. Depend on
>> such at your peril!"
>>
>
> Would a pre-requisite for any new SCM to be anointed as *the* new SCM that the
> buildfarm can be reconfigured to run with it? Unless there is an SCM2CVS
> option available I suppose... how many SCM's support such a thing?
>

I dont think the buildfarm needs to require CVS. The code can be
changed in the buildfarm to just run 'svn up' or 'git up and go' (sorry,
never used git so I had to guess at the command :-) ) right?

-Andy

Andy Colson escribió:
> Robert Treat wrote:

>> Would a pre-requisite for any new SCM to be anointed as *the* new SCM
>> that the buildfarm can be reconfigured to run with it? Unless there is
>> an SCM2CVS option available I suppose... how many SCM's support such a
>> thing?
>
> I dont think the buildfarm needs to require CVS. The code can be
> changed in the buildfarm to just run 'svn up' or 'git up and go' (sorry,
> never used git so I had to guess at the command :-) ) right?

In fact I don't see why the buildfarm couldn't be configurable to use
whatever tool/repo the user sees fit. It's easy enough to detect
whether a checked out copy is SVN or git or whatever, and act
accordingly.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Andy Colson wrote:
> Robert Treat wrote:
>> Would a pre-requisite for any new SCM to be anointed as *the* new SCM
>> that the buildfarm can be reconfigured to run with it? Unless there
>> is an SCM2CVS option available I suppose... how many SCM's support
>> such a thing?
>
> I dont think the buildfarm needs to require CVS. The code can be
> changed in the buildfarm to just run 'svn up' or 'git up and go'
> (sorry, never used git so I had to guess at the command :-) ) right?

As long as the build farm never writes results - certainly. Any system
that pulls data from a central repository would work.

Cheers,
mark

P.S. Depending on configuration, it might be 'git pull'.

--
Mark Mielke <mark(at)mielke(dot)cc>

On Feb 11, 2008 9:14 PM, Andy Colson <andy(at)squeakycode(dot)net> wrote:
> I dont think the buildfarm needs to require CVS. The code can be
> changed in the buildfarm to just run 'svn up' or 'git up and go' (sorry,
> never used git so I had to guess at the command :-) ) right?

The relevant commands, for several of the tools, are:
"svn update"
"git pull"
"darcs pull --all"
"hg pull"
"mtn pull"

Distributed SCMs seem to favor "pull" over "update"

The only thing about this that would be a bit tricky is that buildfarm
presently treats a certain format of output as indicating that no
changes were found. The "expected output" for other SCMs will differ
somewhat. And this isn't so vastly tricky a matter as to be
considered an obstacle.

Indeed, I think that it would be an entirely reasonable thing to
expect to modify buildfarm a little bit so that it could cope with
multiple SCMs, and for us to have a few "animals" set up specifically
to track some SCMs.

This clearly ISN'T a barrier of the sort that Jan suggested.
--
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results." -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling

Andy Colson wrote:
>>
>> Would a pre-requisite for any new SCM to be anointed as *the* new SCM
>> that the buildfarm can be reconfigured to run with it? Unless there
>> is an SCM2CVS option available I suppose... how many SCM's support
>> such a thing?
>
> I dont think the buildfarm needs to require CVS. The code can be
> changed in the buildfarm to just run 'svn up' or 'git up and go'
> (sorry, never used git so I had to guess at the command :-) ) right?
>
>

Wrong. The buildfarm has quite a lot of CVS-specific intelligence in it
that will need to be adapted to whatever we use to replace CVS. It is
very far from "plug and play". And I sure don't want to keep a CVS repo
just on account of the buildfarm. If and when the "one true postgres
SCM" changes, buildfarm should change along with it. Working out how is
just a part of the problems we'll face.

I have deliberately stayed out of this debate, since I have nothing much
new to say (and I observe that nothing much new has been said ;-) ). But
let me repeat a couple of things I have said previously:

I want to make a change in SCM once only in the foreseeable future. And
I'm in no great hurry. If I have a preference it is ever so slightly for
Mercurial, but that's just based on impression rather than solid
experience. I have used Subversion for quite some time - it has sorted
out some of the more obvious wrinkles that CVS presents, but I'm not
sure it's that much of a quantum leap that it's worht the trouble. I'll
be interested to see what Mark Miekle says after looking at all the systems.

cheers

andrew

On Monday 11 February 2008 18:18, Andrew Dunstan wrote:
> Andy Colson wrote:
> >> Would a pre-requisite for any new SCM to be anointed as *the* new SCM
> >> that the buildfarm can be reconfigured to run with it? Unless there
> >> is an SCM2CVS option available I suppose... how many SCM's support
> >> such a thing?
> >
> > I dont think the buildfarm needs to require CVS. The code can be
> > changed in the buildfarm to just run 'svn up' or 'git up and go'
> > (sorry, never used git so I had to guess at the command :-) ) right?
>
> Wrong. The buildfarm has quite a lot of CVS-specific intelligence in it
> that will need to be adapted to whatever we use to replace CVS. It is
> very far from "plug and play". And I sure don't want to keep a CVS repo
> just on account of the buildfarm. If and when the "one true postgres
> SCM" changes, buildfarm should change along with it. Working out how is
> just a part of the problems we'll face.
>
> I have deliberately stayed out of this debate, since I have nothing much
> new to say (and I observe that nothing much new has been said ;-) ). But
> let me repeat a couple of things I have said previously:
>
> I want to make a change in SCM once only in the foreseeable future. And
> I'm in no great hurry. If I have a preference it is ever so slightly for
> Mercurial, but that's just based on impression rather than solid
> experience. I have used Subversion for quite some time - it has sorted
> out some of the more obvious wrinkles that CVS presents, but I'm not
> sure it's that much of a quantum leap that it's worht the trouble. I'll
> be interested to see what Mark Miekle says after looking at all the
> systems.
>

Switching from CVS to SVN is like switching from myisam to innodb; yeah, it's
an improvement, but you're still working with something fundementally broken.

Oooh...burn....hiss :-P

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL