[Top][All Lists]
[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
- Prev by Date:
[commit aborted] cannot rename file ,xxx, to file,v: file exists
- Next by Date:
Re: [commit aborted] cannot rename file ,xxx, to file,v: file exists
- Previous by thread:
Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
- Next by thread:
Re: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
- Index(es):