Re: Feature Freeze date for 8.4 - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Feature Freeze date for 8.4
Date
Msg-id e51f66da0710240055y4be738b7y77c7d342fa3fd3e1@mail.gmail.com
Whole thread Raw
In response to Re: Feature Freeze date for 8.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Feature Freeze date for 8.4
Re: Feature Freeze date for 8.4
Re: Feature Freeze date for 8.4
List pgsql-hackers
On 10/24/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > Mind you, I'm in favor of one.  A new SCM would make some other development
> > tasks easier. However, I'm reluctant to open the can-of-worms which is the
> > "what SCM should we use" discussion again, and complicate something which
> > we seem to have consensus on.
>
> As near as I can tell, the arguments for a new SCM mostly apply to work
> which individual developers are doing outside the main tree.  So, given
> the existence of stuff like git-cvsimport, I don't see a strong reason
> why anyone who wants to work that way can't already sync the core CVS
> with a local SCM-of-their-choice and get on with it.

Yes, external devs can already work fine with DSCM.

And after using the repo.or.cz git tree for some time, mostly
tracking and also for some small patches I really have no interest
touching CVS anymore.

> You're right that this is utterly unrelated to the scheduling question,
> anyway.

As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.  Both leading DSCMs - GIT and Mercurial
do not support it.

Currently converting patch from DSCM to context diff is pain,
especially if it contains new files.  It would make lives of DSCM
users much easier if both formats would be accepted in -hackers.

-- 
marko


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Feature Freeze date for 8.4
Next
From: "Marko Kreen"
Date:
Subject: Re: Feature Freeze date for 8.4