Thread: Developer setup, what works?
I am thinking about a project that may change a large number of source files. It may also take a fair amount of time, so I expect the main source tree to get changed a fair amount during my work. What is the best way of setting up my source tree to support mergeing my changes later later? Or maybe another way to ask is how do I make the best use of cvs and cvsup etc to support concurant development? Or even, what are the active pgsql developers doing now? Do you try to stay up to date on the patchs for you own source tree? Do you maintain a local cvs repository? If so, how do you handle branching and merging? Do you use "vendor branches"? I am sure I can puzzle something out, but if you have already developed ways of organizing this that are 'standard procedure' or that work especially well, I would like to take advantage of them. Thanks, -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - Linux. Not because it is free. Because it is better.
> > > I am thinking about a project that may change a large number of source files. > It may also take a fair amount of time, so I expect the main source tree > to get changed a fair amount during my work. > > What is the best way of setting up my source tree to support mergeing my > changes later later? Or maybe another way to ask is how do I make the best > use of cvs and cvsup etc to support concurant development? Or even, what > are the active pgsql developers doing now? > > Do you try to stay up to date on the patchs for you own source tree? Do you > maintain a local cvs repository? If so, how do you handle branching and > merging? Do you use "vendor branches"? > > I am sure I can puzzle something out, but if you have already developed > ways of organizing this that are 'standard procedure' or that work especially > well, I would like to take advantage of them. Good question. If I can do it in stages, I do, and commit my changes every few days. Even if you break the system doing it, that is OK. We may or may not ask you to at least keep it running minimally so others can test. Another way to do it is to 'claim the tree' and we will stay out of it and hold our patches until you are finished. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian: > David Gould: > > I am thinking about a project that may change a large number of source files. > > It may also take a fair amount of time, so I expect the main source tree > > to get changed a fair amount during my work. > > > > What is the best way of setting up my source tree to support mergeing my > > changes later later? Or maybe another way to ask is how do I make the best > > use of cvs and cvsup etc to support concurant development? Or even, what > > are the active pgsql developers doing now? > > > > Do you try to stay up to date on the patchs for you own source tree? Do you > > maintain a local cvs repository? If so, how do you handle branching and > > merging? Do you use "vendor branches"? > > > > I am sure I can puzzle something out, but if you have already developed > > ways of organizing this that are 'standard procedure' or that work especially > > well, I would like to take advantage of them. > > Good question. If I can do it in stages, I do, and commit my changes > every few days. Even if you break the system doing it, that is OK. We > may or may not ask you to at least keep it running minimally so others > can test. Another way to do it is to 'claim the tree' and we will stay > out of it and hold our patches until you are finished. I guess I am asking a more basic question than this. For the past 10 years or so I have been using either SCCS or RCS or ClearCase (Blech!) for source control. I have not used CVS or cvsup. So I am really asking what is the best way to setup up a source tree on my machine? I have read the CVS manual so I can make it work however, I am just wondering about what the most usual configureation is. Do I make a local cvsroot and use the "import vendor branch" feature? Or do I try to configure to use a remote CVS server (ie at postgresql.org). Should I maintain my own branch? And how does cvsup fit in with this? Sorry for the lamity, but a 5 minute guide to how to set up a convenient pgsql CM environment would save me a bit of time. Thanks, -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - Linux. Not because it is free. Because it is better.
> I guess I am asking a more basic question than this. For the past 10 years or > so I have been using either SCCS or RCS or ClearCase (Blech!) for source > control. I have not used CVS or cvsup. So I am really asking what is the best > way to setup up a source tree on my machine? I have read the CVS manual so I > can make it work however, I am just wondering about what the most usual > configureation is. Do I make a local cvsroot and use the "import vendor > branch" feature? Or do I try to configure to use a remote CVS server > (ie at postgresql.org). Should I maintain my own branch? And how does cvsup > fit in with this? Sorry for the lamity, but a 5 minute guide to how to set up > a convenient pgsql CM environment would save me a bit of time. See tools/FAQ_DEV. We cvsup the source, then use tools/make_diff/difforig to generate patches. We then post them to the patches list. Or, if you have a postgresql.org telnet account from Marc, you do a cvs checkout in that account to set up a tree, ftp the patch to your telnet account on postgresql.org, run 'patch' with the diff we just ftp'ed, and do a 'cvs update' to apply the patch, with an appropriate description. After that, everyone sees your changes. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Sun, 5 Apr 1998, David Gould wrote:
> I guess I am asking a more basic question than this. For the past 10 years or
> so I have been using either SCCS or RCS or ClearCase (Blech!) for source
> control. I have not used CVS or cvsup. So I am really asking what is the best
> way to setup up a source tree on my machine? I have read the CVS manual so I
> can make it work however, I am just wondering about what the most usual
> configureation is. Do I make a local cvsroot and use the "import vendor
> branch" feature? Or do I try to configure to use a remote CVS server
> (ie at postgresql.org). Should I maintain my own branch? And how does cvsup
> fit in with this? Sorry for the lamity, but a 5 minute guide to how to set up
> a convenient pgsql CM environment would save me a bit of time.
I don't know if anyone has tried this yet, and I've only just
barely tried it here...
If you take the README.cvsup file that is found at
ftp.postgresql.org:/pub/CVSup and comment out the line that states
'*default tag=.', it will pull down the actual RCS files.
So, for instance, if you were to setup a CVS repository on your
machine and, using the above, pull the RCS files into $CVSROOT (and
created an appropriate $CVSROOT/CVSROOT directory), you could grab the
current source tree easily, and then checkout (and update) a local source
tree)...
Then you'd just have to send in patches periodically, while
keeping your local source tree in sync with the master...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Marc G. Fournier has a great idea: > I don't know if anyone has tried this yet, and I've only just > barely tried it here... > > If you take the README.cvsup file that is found at > ftp.postgresql.org:/pub/CVSup and comment out the line that states > '*default tag=.', it will pull down the actual RCS files. > > So, for instance, if you were to setup a CVS repository on your > machine and, using the above, pull the RCS files into $CVSROOT (and > created an appropriate $CVSROOT/CVSROOT directory), you could grab the > current source tree easily, and then checkout (and update) a local source > tree)... > > Then you'd just have to send in patches periodically, while > keeping your local source tree in sync with the master... This sounds like exactly what I was looking for. So I am still a little hazy on the interaction between CVS and cvsup so perhaps you could spell this out a bit: Suppose I want to work in ~/pgsql and refer to the module as pgsql. And I want to store all my CVS trees under /local1/cvsroot. If I have understood you I need to do export CVSROOT=/local0/cvsroot cvs init $CVSROOT mkdir $CVSROOT/CVSROOT # is this right? why? cat >$CVSROOT/modules pgsql ??? what goes here ??? ^D And then how do I keep in sync with the master? I am embarrassed to keep asking about this, I really do know about databases, but I have never used CVS and cvsup so all help is appreciated. Thanks -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 "I was pleased to be able to answer right away, and I did. I said I didn't know." -- Mark Twain, Life on the Mississippi
On Sun, 5 Apr 1998, David Gould wrote:
> Marc G. Fournier has a great idea:
> > I don't know if anyone has tried this yet, and I've only just
> > barely tried it here...
> >
> > If you take the README.cvsup file that is found at
> > ftp.postgresql.org:/pub/CVSup and comment out the line that states
> > '*default tag=.', it will pull down the actual RCS files.
> >
> > So, for instance, if you were to setup a CVS repository on your
> > machine and, using the above, pull the RCS files into $CVSROOT (and
> > created an appropriate $CVSROOT/CVSROOT directory), you could grab the
> > current source tree easily, and then checkout (and update) a local source
> > tree)...
> >
> > Then you'd just have to send in patches periodically, while
> > keeping your local source tree in sync with the master...
>
> This sounds like exactly what I was looking for. So I am still a little hazy
> on the interaction between CVS and cvsup so perhaps you could spell this
> out a bit:
>
> Suppose I want to work in ~/pgsql and refer to the module as pgsql. And I want
> to store all my CVS trees under /local1/cvsroot. If I have understood you
> I need to do
>
> export CVSROOT=/local0/cvsroot
> cvs init $CVSROOT
Neat, I don't believe I used this when I created mine...:(
> mkdir $CVSROOT/CVSROOT # is this right? why?
From what I just scanned through in the info pages, isn't this
what cvs init is supposed to do?
> cat >$CVSROOT/modules
Same as above...
> pgsql ??? what goes here ???
I don't recall what platform you are running on, but as long as
you have cvsup available, use the attached 'README.cvsup' (cvsup -L 1 -g
README.cvsup) to pull down the CVS repository and deposit it into your
$CVSROOT directory...
Run that out of cron, once a night, or once a week (base it on the
commit messages going through)...never commit your changes to your cvs
repository, except just before you are ready to make a patch, as the next
CVSup you do will overwrite your changes, but you can do checkouts and
updates as appropriate...
> I am embarrassed to keep asking about this, I really do know about databases,
> but I have never used CVS and cvsup so all help is appreciated.
That's okay...I'm embarressed that I don't remember how to do
this, after doing it so many times lately :(
# This file represents the standard CVSup distribution file
# for the PostgreSQL ORDBMS project
#
# Defaults that apply to all the collections
*default host=postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
#*default tag=.
# base directory points to where CVSup will store its 'bookmarks' file(s)
*default base=/local0/cvsroot
# prefix directory points to where CVSup will store the actual distribution(s)
*default prefix=/local0/cvsroot
# complete distribution, including all below
pgsql
> > I am embarrassed to keep asking about this, I really do know about
> > databases, but I have never used CVS and cvsup so all help is
> > appreciated.
> That's okay...I'm embarressed that I don't remember how to do
> this, after doing it so many times lately :(
Oh yeah? Well _I'm_ embarrassed that I couldn't figure out how CVSup and
cvs could be used together on my machine! This was a useful discussion
David; keep up with the stupid questions.
David/someone, would you want to take a crack at consolidating this
discussion into either SGML/docbook source or into plain text that I can
mark up? This should go into the developer's guide...
- Tom
> > > > I am embarrassed to keep asking about this, I really do know about > > > databases, but I have never used CVS and cvsup so all help is > > > appreciated. > > That's okay...I'm embarressed that I don't remember how to do > > this, after doing it so many times lately :( > > Oh yeah? Well _I'm_ embarrassed that I couldn't figure out how CVSup and > cvs could be used together on my machine! This was a useful discussion > David; keep up with the stupid questions. > > David/someone, would you want to take a crack at consolidating this > discussion into either SGML/docbook source or into plain text that I can > mark up? This should go into the developer's guide... OK, now I am confused. Why would you use cvs on your local machine? I just use cvsup to download the most recent code, and log into postgresql.org to use cvs to update my changes. After the 'cvs update', I run cvsup again to re-sync my local source with the current tree. What am I missing? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Mon, 6 Apr 1998, Bruce Momjian wrote:
> >
> > > > I am embarrassed to keep asking about this, I really do know about
> > > > databases, but I have never used CVS and cvsup so all help is
> > > > appreciated.
> > > That's okay...I'm embarressed that I don't remember how to do
> > > this, after doing it so many times lately :(
> >
> > Oh yeah? Well _I'm_ embarrassed that I couldn't figure out how CVSup and
> > cvs could be used together on my machine! This was a useful discussion
> > David; keep up with the stupid questions.
> >
> > David/someone, would you want to take a crack at consolidating this
> > discussion into either SGML/docbook source or into plain text that I can
> > mark up? This should go into the developer's guide...
>
> OK, now I am confused. Why would you use cvs on your local machine? I
> just use cvsup to download the most recent code, and log into
> postgresql.org to use cvs to update my changes. After the 'cvs update',
> I run cvsup again to re-sync my local source with the current tree.
>
> What am I missing?
The fact that you can login to postgresql.org and update the
source tree so that your work doesn't diverge greatly from that which is
the main source tree? :)
> > ... I couldn't figure out how CVSup
> > and cvs could be used together on my machine!
> OK, now I am confused. Why would you use cvs on your local machine?
> I just use cvsup to download the most recent code, and log into
> postgresql.org to use cvs to update my changes. After the 'cvs
> update', I run cvsup again to re-sync my local source with the current
> tree.
>
> What am I missing?
I _think_ what this will do is allow me to do my CVSup any time I want,
then do "cvs update ..." on my local machine. Working changes I have
made _won't_ get erased (as they do when you work directly in your CVSup
target area), but rather cvs will show them as modified. It may be that
I _only_ want the cvs repository, and then can set my local CVSROOT to
point at it.
Will let you know; I've got the cvs repository downloaded now...
- Tom
On Mon, 6 Apr 1998, Thomas G. Lockhart wrote:
> > > I am embarrassed to keep asking about this, I really do know about
> > > databases, but I have never used CVS and cvsup so all help is
> > > appreciated.
> > That's okay...I'm embarressed that I don't remember how to do
> > this, after doing it so many times lately :(
>
> Oh yeah? Well _I'm_ embarrassed that I couldn't figure out how CVSup and
> cvs could be used together on my machine! This was a useful discussion
> David; keep up with the stupid questions.
Actually, for that, I had to go to the man pages...took me a while
to figure that one out too :)
> > OK, now I am confused. Why would you use cvs on your local machine? I > > just use cvsup to download the most recent code, and log into > > postgresql.org to use cvs to update my changes. After the 'cvs update', > > I run cvsup again to re-sync my local source with the current tree. > > > > What am I missing? > > The fact that you can login to postgresql.org and update the > source tree so that your work doesn't diverge greatly from that which is > the main source tree? :) No, he seems to want to have cvs running on his local machine, at least that is what I see Thomas saying. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Mon, 6 Apr 1998, Bruce Momjian wrote:
> > > OK, now I am confused. Why would you use cvs on your local machine? I
> > > just use cvsup to download the most recent code, and log into
> > > postgresql.org to use cvs to update my changes. After the 'cvs update',
> > > I run cvsup again to re-sync my local source with the current tree.
> > >
> > > What am I missing?
> >
> > The fact that you can login to postgresql.org and update the
> > source tree so that your work doesn't diverge greatly from that which is
> > the main source tree? :)
>
> No, he seems to want to have cvs running on his local machine, at least
> that is what I see Thomas saying.
Okay...put yourself in his shoes...no access to postgresql.org...
Now, he can do a cvsup of the sources, which, if he makes any
changes to his sources, overwrites those changes...or, he can cvsup the
cvs repository itself, and manipulate that as if he were connected
directly to postgresql.org...
Basically, he can do a "cvs update pgsql" to bring in any new
changes, *plus* have CVS auto-merge his changes into it...
Once way, he submits a whole bunch of little patches, the other he
can work until he ready, on his home machine, and submit one large
patch...both ways he succeeds in staying in sync with any changes that we
make, or anyone else does...one is less convienent to us all then the
other though :)
BTW...got cheque today...thanks...:)
> > No, he seems to want to have cvs running on his local machine, at least > > that is what I see Thomas saying. > > Okay...put yourself in his shoes...no access to postgresql.org... > > Now, he can do a cvsup of the sources, which, if he makes any > changes to his sources, overwrites those changes...or, he can cvsup the > cvs repository itself, and manipulate that as if he were connected > directly to postgresql.org... > > Basically, he can do a "cvs update pgsql" to bring in any new > changes, *plus* have CVS auto-merge his changes into it... > > Once way, he submits a whole bunch of little patches, the other he > can work until he ready, on his home machine, and submit one large > patch...both ways he succeeds in staying in sync with any changes that we > make, or anyone else does...one is less convienent to us all then the > other though :) OK, now my head hurts. So he basically keeps his copy of CVSROOT current with our tree, and has a personal copy of that that he uses to make changes. And he can run 'cvs update' and that will change his personal tree to stay in sync with our changes? Yikes. If you are over-writing the CVSROOT with remote changes via cvsup, is cvs smart enough to realize how to keep his sources in sync? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Mon, 6 Apr 1998, Bruce Momjian wrote:
> > > No, he seems to want to have cvs running on his local machine, at least
> > > that is what I see Thomas saying.
> >
> > Okay...put yourself in his shoes...no access to postgresql.org...
> >
> > Now, he can do a cvsup of the sources, which, if he makes any
> > changes to his sources, overwrites those changes...or, he can cvsup the
> > cvs repository itself, and manipulate that as if he were connected
> > directly to postgresql.org...
> >
> > Basically, he can do a "cvs update pgsql" to bring in any new
> > changes, *plus* have CVS auto-merge his changes into it...
> >
> > Once way, he submits a whole bunch of little patches, the other he
> > can work until he ready, on his home machine, and submit one large
> > patch...both ways he succeeds in staying in sync with any changes that we
> > make, or anyone else does...one is less convienent to us all then the
> > other though :)
>
> OK, now my head hurts.
>
> So he basically keeps his copy of CVSROOT current with our tree, and has
> a personal copy of that that he uses to make changes. And he can run
> 'cvs update' and that will change his personal tree to stay in sync with
> our changes? Yikes.
>
> If you are over-writing the CVSROOT with remote changes via cvsup, is
> cvs smart enough to realize how to keep his sources in sync?
Try it on hub.org sometime...
Go into a file and make a change to it...then do a 'cvs update
<dir>'...that file you modified will be marked as 'M' (Modified)
Now, if he makes changes to the same file that you made changes
to, cvsup's the new *RCS* files (which is what we've detailed how to do),
when he does a 'cvs update', it will actually take your changes and merge
them with his changes *unless* there is a conflict with that change (ie.
the section of the file he changed is identical to the one that you
changed)
Its what CVS was designed for...two ppl can work on the same file
without little to no conflicts between them when it comes time to
re-introduce the changes into the main stream...
I've seen several people give some fairly (IMHO) icky "solutions" to
this.
I consider them icky because they didn't support the following:
- local availability of "cvs log" messages
- local availability of cvs branches (may not be important if pgsql
doesn't use many branches, but this was an absolute requirement with
the FreeBSD repository)
- ability to commit partial changes of a work in progress easily without
upsetting the main cvs branch. (This was required since we often had
a number of people locally using or working on these changes).
I only know of two ways to do this:
1) setup and use cvs in client mode assuming that pgsql has (or can)
setup their cvs to act as a server.
One drawback to this for David is that he will be working on a long term
project which will break things if he commits them to the main branch
(and he won't want to keep all his changes uncommitted if he's smart).
A simple solution to this is that he could use a branch in the main
repository and merge that into the main branch when he's all done. This
would be ideal assuming David's got a fast connection to postgresql.org
and there are no security problems with the postgres cvs gods allowing
cvs client access.
If no body else will be working on the same branch then there isn't a
need to have the changes go to the main pgsql tree right away so it
may be better to do the following:
2) setup a local cvs repository, use cvsup to keep all the bits up to
date with the main pgsql repository. David creates a local branch
(see caveat bellow) and puts all changes there.
Whenever he feels like syncing the source he's working on he runs cvsup
and either
a) merges changes from the main branch into his branch on his tree
or
b) merges his changes into a new branch on the head (I prefer this method).
CVS assists with either of these operations making them mostly painless
except, of course, if there are conflicting changes.
When he's all done and wants his work committed to the main branch he
does one of the above and then he can trivially generate a huge patch
relative to the current head of the main repository suitable for anyone
to commit. (Or you could do fancy tricks with cvsup to get David's
branch into the main tree in order to keep his intermediate commit
messages).
Caveat:
The problem with this (that no one here has mentioned how to get
around) is that with the "delete" option cvsup will blow away any
local changes you make since if the checksum on the resulting files
don't match it resends the whole file. Okay, so you remove the "delete"
option, right? Only partially correct. Cvsup will still blow away any
changes with the same revision numbers.
Here's an example of what happens:
1) cvsup fetches version 1.69 of a file
2) you locally make changes and commit version 1.70 of this file
3) everything is cool until some time later when someone commits 1.70 to
the pgsql main repository then:
4) cvsup fetches version 1.70 and blows away your version 1.70
So how do you get around this? Simple (sort of) you create a branch
point. Now your changes go to 1.69.0.1, 1.69.0.2, etc. Cvsup will
merrily add 1.70, 1.71, etc without disturbing your 1.69.0 branch.
EXCEPT if there is a branch created in the main tree at the same point
(thereby causing a collision of version numbers).
To avoid this you can make a small change to your local cvs program to
use a higher branch number instead of starting at zero. For example,
make it use 1.69.42.1, 1.69.42.2, etc, that way for a collision to occur
the main pgsql repository must be branched more than 20 times at a
single point (cvs uses only even numbers for branching).
For those that are lost here is a step by step summary of what I've done
with the FreeBSD repository in the past (modified here to work with the
pgsql repository):
My $CVSROOT=/cvs (created long ago via cvs init) and I want the pgsql
repository to be rooted at $CVSROOT/pgsql. Change the appropriate paths
bellow to match whatever you prefer.
Create a pgsql.cvsup file as follows:
pgsql release=cvs host=postgresql.org base=/cvs/pgsql prefix=/cvs \
backup compress use-rel-suffix
Note: This is actually a single line, I'm not sure if cvsup understands
the '\' character.
Note2: There is no delete option present.
The "base" argument tells cvsup were to create a "sup" subdirectory
for it's bookkeeping (here it is put in /cvs/pgsql/sup). The "prefix"
argument is where to dump the actual files, since all the pgsql files
start with pgsql/ this actually puts everything into /cvs/pgsql
If you didn't add pgsql to the root of the local cvs repository (as I
did) then add something like this to the modules file:
pgsql -a path_from_cvsroot_to/pgsql
Run cvsup to fetch the files. (I do "cvsup -g -P - pgsql.cvsup")
Checkout the version you want to work from (probably the head).
Tag the branch point:
% cvs tag BLAH_BLAH_BP
Create the branch:
% cvs tag -b BLAH_BLAH
Now work on the files and commit things whenever you like. Run cvsup as
often as you like and when you want to sync your working sources up do
one of the following:
a) merge changes between the branch point and the head into your branch:
(add an -r option to the rtag command if you don't want to use the head
of the main branch)
% cvs rtag some_tag pgsql
% cvs update -j BLAH_BLAH_BP -j some_tag
Next time use:
% cvs rtag some_other_tag
% cvs update -j some_tag -j some_other_tag
The extra tags are required so that you don't try merging the same
changes multiple times. (There may be a better way to do this, I've
never actually done it this way).
Instead I do:
b) merge changes on your local branch to a new branch
Get the head (or use a -r option if you don't want the head)
% cvs update -A
Create a new branch
% cvs tag NEW_BRANCH_BP
% cvs tag -b NEW_BRANCH
Merge in your own changes
% cvs update -j BLAH_BLAH_BP -j BLAH_BLAH
This merge operation can happen as often as you like since it's mostly
automatic (although the tag operations can take awhile). With FreeBSD
I used the (b) approach and did the merge every time there was a new
stable release.
ie I did:
% cvs update -rRELENG_2_2_6
% cvs tag DDM_2_2_6_BP
% cvs tag -b DDM_2_2_6
% cvs update -j DDM_2_2_5_BP -j DDM_2_2_5
Occasionally I'd use cvs to merge in specific important changes without
merging everything else.
When you want to submit things to the main pgsql repository you can
create a huge diff like this:
% cvs diff -uN -r LAST_BRANCH_BP -r LAST_BRANCH
This may seem overly complicated but I found it worked quite well with
the FreeBSD repository. If you don't fully understand branches under
cvs I highly suggest a full reading of the cvs.info file.
Hope this helped.
--
Dave Chapeskie, DDM Consulting
E-Mail: dchapes@ddm.on.ca
The Hermit Hacker wrote: > > On Mon, 6 Apr 1998, Thomas G. Lockhart wrote: > > > > > I am embarrassed to keep asking about this, I really do know about > > > > databases, but I have never used CVS and cvsup so all help is > > > > appreciated. > > > That's okay...I'm embarressed that I don't remember how to do > > > this, after doing it so many times lately :( > > > > Oh yeah? Well _I'm_ embarrassed that I couldn't figure out how CVSup and > > cvs could be used together on my machine! This was a useful discussion > > David; keep up with the stupid questions. > > Actually, for that, I had to go to the man pages...took me a while > to figure that one out too :) > While we're on the topic of stupid cvsup questions, does anyone know how to get this thing to use a firewall? Ocie
Attached is the man page...there is a -P option that is for getting around
Firewalls...supposedly...
On Mon, 6 Apr 1998 ocie@paracel.com wrote:
> The Hermit Hacker wrote:
> >
> > On Mon, 6 Apr 1998, Thomas G. Lockhart wrote:
> >
> > > > > I am embarrassed to keep asking about this, I really do know about
> > > > > databases, but I have never used CVS and cvsup so all help is
> > > > > appreciated.
> > > > That's okay...I'm embarressed that I don't remember how to do
> > > > this, after doing it so many times lately :(
> > >
> > > Oh yeah? Well _I'm_ embarrassed that I couldn't figure out how CVSup and
> > > cvs could be used together on my machine! This was a useful discussion
> > > David; keep up with the stupid questions.
> >
> > Actually, for that, I had to go to the man pages...took me a while
> > to figure that one out too :)
> >
>
> While we're on the topic of stupid cvsup questions, does anyone know
> how to get this thing to use a firewall?
>
> Ocie
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org