[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sourc
Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
Wed, 4 Sep 2002 09:32:57 -0400
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
> 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),
> > 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
> > 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