info-cvs
[Top][All Lists]
Advanced

[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


From: Eric Siegerman
Subject: Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
Date: Tue, 3 Sep 2002 15:45:49 -0400
User-agent: Mutt/1.2.5i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]