Обсуждение: Contributing
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. Then, when I wish to send a patch in, I get cvs to produce a diff on the pgsql module. And CVSup allows me to manage changes from the main PG repository into my own repository, right? Is this right? MikeA
[Charset iso-8859-1 unsupported, filtering to ASCII...] > 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. > Then, when I wish to send a patch in, I get cvs to produce a diff on the > pgsql module. And CVSup allows me to manage changes from the main PG > repository into my own repository, right? Yes, CVS can easily produced the diff for you. We only allow a few people cvs commmit privs. Others send patches to the patches list, and we apply them, usually in a few days. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
I think it depends on the level of changes you intend to implement (and your 'net access speed). If you just want to tweak some code, pulling the latest cvs, hacking it up, doing a 'cvs update' and resolve any conflicts, then doing 'cvs diff' will give you a nice patch to send in. (Any recomendations on parameters for cvs diff?) If your planning some major development, where you want to be able to hack and slash and not worry about losing your own changes, a local CVSup mirror may be preferable. Note that if you're behind a slow link, even the first scenario can be slow (the cvs diff requires 'net access to the repository) Ross On Fri, Jul 16, 1999 at 06:10:38PM +0200, Ansley, Michael wrote: > 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. > Then, when I wish to send a patch in, I get cvs to produce a diff on the > pgsql module. And CVSup allows me to manage changes from the main PG > repository into my own repository, right? > > > Is this right? > > MikeA > -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
"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
> I think it depends on the level of changes you intend to implement > (and your 'net access speed). If you just want to tweak some code, > pulling the latest cvs, hacking it up, doing a 'cvs update' and resolve > any conflicts, then doing 'cvs diff' will give you a nice patch to send > in. (Any recomendations on parameters for cvs diff?) pgcvs diff -c > > If your planning some major development, where you want to be able to > hack and slash and not worry about losing your own changes, a local CVSup > mirror may be preferable. You can use our src/tools/make_diff tools to help. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > What is the ideal setup to have when contributing to PG development?
> 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.
The other principle advantage to CVSup is its efficiency in bringing
over updates. It is very fast and really minimizes the bandwidth.
> 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.
Or find that hub.org disappears occasionally, or...
> 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?
CVSup guarantees that the parts of your cvs tree which are in common
with the server are the same. So it is probably not such a good idea
to use it to replicate a checked-out tree if you plan on making any
changes, because it will wipe them out on the next update. It does
allow you to make branches in your local repository, but I don't use
this feature.
> 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.
Yes. As you can tell, I'm a big fan of CVSup...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Sat, 17 Jul 1999, Thomas Lockhart wrote:
> > > What is the ideal setup to have when contributing to PG development?
> > 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.
>
> The other principle advantage to CVSup is its efficiency in bringing
> over updates. It is very fast and really minimizes the bandwidth.
Is this less then when using the -z option for CVS?
> > 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.
>
> Or find that hub.org disappears occasionally, or...
We think we just licked that problem...FreeBSD 3.x and earlier has
a problem with VM fragmentation when you start swapping heavily, so we
just upgraded Hub to 768Meg of RAM from the 384Meg it was...where it used
to die once every 24hrs, its been up ~5days now...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote:
>
> On Sat, 17 Jul 1999, Thomas Lockhart wrote:
>
> > > > What is the ideal setup to have when contributing to PG development?
> > > 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.
> >
> > The other principle advantage to CVSup is its efficiency in bringing
> > over updates. It is very fast and really minimizes the bandwidth.
>
> Is this less then when using the -z option for CVS?
I believe so. I'm just guessing at CVS's behavior, but I *know* that
CVSup only sends compressed diffs of the changes to update a cvs
repository or a checked-out tree. afaik CVS sends the entire file,
compressing it for transmission much as does CVSup.
> > Or find that hub.org disappears occasionally, or...
> We think we just licked that problem...
Not entirely, unless you can guarantee uptime on Internet routing. I
see outages on occasion which I don't think are local to hub.org.
That's no news to anyone, but it does seem relevant when discussing
the merits of local vs remote repositories.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> The Hermit Hacker wrote:
>> Is this less then when using the -z option for CVS?
> I believe so. I'm just guessing at CVS's behavior, but I *know* that
> CVSup only sends compressed diffs of the changes to update a cvs
> repository or a checked-out tree. afaik CVS sends the entire file,
> compressing it for transmission much as does CVSup.
No, CVS will send either a whole file or a diff (the U or P code in its
printout tells you which way it updated the file, ie, Update whole thing
or Patch). Either way, it's compressed if you've specified -z.
It looks like cvs has some semi-intelligent algorithm for choosing
which to do ... probably, it produces the diff and then looks to see
if the diff is bigger than the file.
I would expect CVSup to require more total net traffic just because
it has to transfer more info --- log entries, intermediate versions
(with CVS, if foo.c has been checked in three times since your last
update, you are sent one diff covering all the changes), etc.
I have not tried to time it however. In any case, I suspect other
considerations are going to drive each hacker's choice of which way
to run.
regards, tom lane