Return-Path: 
 <dev-return-34946-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 30397 invoked by uid 500); 30 Nov 2002 07:24:02 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
list-post: <mailto:dev@httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 30383 invoked from network); 30 Nov 2002 07:24:01 -0000
Date: Fri, 29 Nov 2002 23:24:13 -0800
Subject: Making the same change on two branches (Re: cvs advice)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez?= <wsanchez@wsanchez.net>
To: dev@httpd.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.WNT.4.50.0211292149080.804-100000@Poste3947>
Message-Id: <B9CC691A-0434-11D7-B8E2-000393A5892E@wsanchez.net>
X-Mailer: Apple Mail (2.548)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Friday, November 29, 2002, at 06:53  PM, Joshua Slive wrote:

> Say I have a file checked out at HEAD, and I know that it is identical 
> to
> the version at APACHE_2_0_BRANCH.  Now I make a change, and I want to
> commit the changed file to both HEAD and the branch.  What is the 
> easiest
> way to do this?  Do I really need to have a separate tree checked out 
> with
> the branch, copy the file, and commit over there?  I tried various
> combinations of cvs up -r and cvs commit -r, but I couldn't make it 
> work.

   I was just doing this when I back-ported the build changes I just 
made.

   If you let CVS do the merging, the file does not need to be identical 
on HEAD and on APACHE_2_0_BRANCH (though there is of course the 
possibility of a conflict if they aren't).

   I find it easier with two trees checked out; I have both an httpd-2.0 
and an httpd-2.1 now.  So I know what I'm working on based on the path. 
  But it's not necessary.  Say you're on HEAD:

	cd httpd-2.0
	<tweak file "foo">
	cvs commit foo						# check into HEAD
	<CVS says, checked in version 1.43>
	cvs up -r APACHE_2_0_BRANCH foo		# switch to 2.0 branch
	cvs up -j 1.42 -j 1.43 foo			# merge the change
	<deal with conflicts, if any>
	cvs commit foo						# check into 2.0 branch
	cvs up -A foo							# go back to HEAD

   So when you want to back-port (or forward port) a change, you find 
the two versions your change happened from/to and use -j flags the 
apply the change on the other branch.

   Instead of updating to the other branch and back, I switch the the 
other checkout and do the merge there.  Yes, you can just copy the file 
over, but not if they weren't identical before you started.

   This is still a bit annoying if you have many files to merge, though. 
  There is a more automated way, which is the branch-per-bug thing I was 
referring to earlier.  The problem is that CVS doesn't give you a 
virtual tag with which you can refer to the version a branch started 
from.  On Mac OS X, you might notice some scripts I wrote.  With those, 
you'd do the following:

	cd httpd-2.0
	<tweak files">
	cvs-make-branch <name>
	cvs commit						# commit to <name> branch
	cvs up -A
	cvs commit						# commit to HEAD
	cvs up -r APACHE_2_0_BRANCH
	cvs-merge-branch <name>
	<deal with conflicts, if any>
	cvs commit						# commit to 2.0 branch
	cvs up -A foo

   cvs-make-branch tags the current base revision (as <name>-base), 
makes a branch, and updates to that branch.  cvs-merge-branch merges 
diffs from <name>-base to <name>.  You can obviously do all that by 
manually; adds a few more steps.

   This isn't less steps, unless you have lots of changes files.  The 
drawback is that it starts putting lots of tags into CVS, and that it 
branches the whole tree, which in CVS can be slow.  But better to waste 
the computer's time than mine, I figure.  I used to have a script that 
would delete all <name>-base and <name> if there were no changes 
between them, which I would use to clean up old tags, but that's 
cosmetic.  One does have to get use to seeing *lots* of tags in the 
repository, though.

	-wsv