Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources

[Jeff Kowalczyk]

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" <address@hidden> wrote in message
news:address@hidden
> 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.        address@hidden
> |  |  /
> [...] 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