This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: branching
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>
- Cc: Keith Seitz <keiths at redhat dot com>,Kevin Buettner <kevinb at redhat dot com>, gdb at sources dot redhat dot com
- Date: Fri, 20 Sep 2002 20:45:30 -0400
- Subject: Re: branching
On Friday, September 20, 2002, at 08:18 PM, Andrew Cagney wrote:
In fact, if you really want to be advanced, and not deal with the
slowdown on merged files that haven't been modified by you on the
branch, but have been on the merge (This is hard to explain. If you
merge from the head, and commit the result, it makes a new revision
in the file, even if you haven't made changes on the branch. This
eventually makes accessing the branch *quite* slow), you can just
move the branch tags on the files you haven't modified on the branch,
so that they refer to the new mainline revision.
Sounds more difficult complex than it is.
You don't happen to have a script? (Yes, for long lived branches
things do start to get slow). The other option is to fix CVS I guess.
cvslines can do it (http://cvslines.sourceforge.net).
Looking at the perl, it does it like so:
sub branchtag
{
my ($file, $spec, $rev) = @_;
print TTYO "$Myname: set branch tag \"$spec\" to revision $rev...\n";
&do_system("cvs tag -F -r $rev -b $spec $file");
}
....
print TTYO "$Myname: first, spoof cvs with a branch tag update...\n";
&branchtag($file, $branchtag, $rootrev);
print TTYO "$Myname: next, spoof the cvs up-to-date check...\n";
&do_system("cvs update $file"); # required for inane
up-to-date-check
Andrew