Re: [HACKERS] CVS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] CVS
Date: 1999-07-19 15:41:23
Message-ID: 27313.932398883@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
>>> If there is any further activity in the 6.5 branch, it'd be to
>>> produce a 6.5.2 bug-fix release. We don't generally do that except
>>> for really critical bugs, since double-patching a bug in both the
>>> tip and a branch is a pain.

> Double-patching is a pain, but I thought that that was the point of using
> CVS to do your branching. AFAIK, CVS will merge the bug-fixes in, say, the
> 6.5.1 branch back into the main branch. Because you want to fix the bugs in
> 6.5 into 6.5.1, without having to double-patch, but new development must
> only go into the main branch. So, when 6.5.1 is released, it is merged back
> into the main branch to pass the fixes over, and also carries on to 6.5.2 in
> a continuation of the existing branch.

The trouble is that the tip usually diverges fast enough that mechanical
application of the same diffs to tip and stable branch doesn't work
very well :-(.

Also, our usual practice is to prove out a bugfix in the tip and then
consider whether to apply it to stable branches. I'm not sure whether
CVS supports that as easily as merging a branch to the tip, but I'd
be *really* wary of mechanical diff transfer to stable branches...
if the diff extracts too little or too much of the changes in the
tip file, you might not find out till too late.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-07-19 15:55:06 Re: [HACKERS] Why DEFAULT text 'now' does not work for TIMESTAMP columns
Previous Message Tom Lane 1999-07-19 15:34:28 Re: [HACKERS] CVS