Thanks, that makes sense. And you were correct, I made my wholesale single-line revisions to A, and the releases are up to C now. My remaining questions are about the merging step: since I have many one-line changes in each cgi script (e.g. I got rid of all the <font> tagging and bgcolor attributes) will merging the vanilla releases into my source require a manual review of every line differing from the new vanilla, every time? The vendor's B,C and future releases are generally fine-tuning, bugfix kinds of changes, and I need to make sure I don't miss any.
"Eric Siegerman" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Tue, Sep 03, 2002 at 01:28:05PM -0400, Jeff Kowalczyk wrote: > > I have revisions A, B, and C (and D before long), of a released tarball > > package (CGI-perl source). I made some widely scattered (almost 30 files > > touched), but compact (almost always contained within a single-line) > > revisions to revision A (cleaning up the HTML output of the CGI-perl), and I > > want to merge them in to my copy of the evolving trunk ASAP, to minimze > > versionitis. > > See http://www.cvshome.org/docs/manual/cvs_13.html#SEC104 . > > The short version is that you put your modifications on the > trunk, and the vanilla tarballs on a branch (specifically the > vendor branch). That's rather counterintuitive at first, but you > quickly get used to it. > > > (P.S. If this is generally unworkable to 'catch up' to Rev C, I'll just redo > > my changes on that version before Rev D comes out, and start from there) > > Shouldn't be a problem: > - import A > - check out a sandbox > * copy your modified directory tree over top of it > * commit > - import B (if you're feeling in a rigorous mood) > - import C > - merge > - commit > - optionally: > - more changes > - commit > + import D when it comes out > + merge > + commit > > That's assuming I read your post correctly, that your changes are > still with respect to A, i.e. you're two releases behind. If > that's wrong, move the "*"'ed steps to after the appropriate > import. Once you've got it all CVSified, the "+"'ed steps are > what you'll have to do every time you get a new release. > > In the recipe above, I left out all the tags. It's a good idea > to tag the trunk both before and after every merge of a new > vendor version. 90% of the time you won't need those tags, but > when (not if) you do, you'll be *really* glad you made them. > > -- > > | | /\ > |-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED] > | | / > [...] despite reports to the contrary, it is the rare programmer who > permanently loses his sanity while coding ("permanently" being the > operative word). > - Eric E. Allen _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
