Re: [HACKERS] Contributing
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Contributing |
Дата | |
Msg-id | 10494.932145682@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Contributing ("Ansley, Michael" <Michael.Ansley@intec.co.za>) |
Список | pgsql-hackers |
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes: > What is the ideal setup to have when contributing to PG development? I can > always just download the latest CVS tree, and then presumably run diff when > I want to send something in. > However, my understanding is that using CVSup allows me to replicate the cvs > tree into my own repository, which I then check out/update/commit from/to. AFAIK, the main advantage of CVSup is that you have a complete copy of the CVS archive on your own machine, which means you can examine cvs commit log messages, pull old versions, and so forth without having to contact hub.org. If you just use "cvs update" periodically then you only have the current sources, and have to use remote cvs to do things like checking log messages. If you've got the disk space to spare for the full archives, and have a fairly slow link to hub.org, then a local archive is worthwhile. I am not sure of the implications of trying to commit into your own copy of the archive when you are using CVSup. I would think that the commits might get lost at next CVSup run ... can anyone who uses CVSup clarify? Personally I use the "cvs update" method because I don't have a lot of disk space to spare for Postgres work, and I don't mind using remote cvs operations to get at the logs... cvs update is pretty good about merging changes from the repository into files that you have changed locally. Dunno how well that works with CVSup. Probably you have to do a local "cvs update" into your working files after each CVSup run, and the net result on the work files is just the same. regards, tom lane
В списке pgsql-hackers по дате отправления: