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...
