Re: Feature Freeze date for 8.4
От | Marko Kreen |
---|---|
Тема | Re: Feature Freeze date for 8.4 |
Дата | |
Msg-id | e51f66da0710240055y4be738b7y77c7d342fa3fd3e1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Feature Freeze date for 8.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Feature Freeze date for 8.4
Re: Feature Freeze date for 8.4 Re: Feature Freeze date for 8.4 |
Список | 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 по дате отправления: