[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 16 Jul 2018 21:46:18 +0200

On Mon, Jul 16, 2018 at 6:57 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
>> Actually the "sync merge" way isn't as automatic as I would like. The
>> merge always conflicts when there is a new or modified trunk CHANGES
>> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve
>> that. Haven't tested that.
> We could have CHANGES-1.9, CHANGES-1.10, etc files, and as part of
> rolling a tarball concatenate them into a single (generated) CHANGES
> file. Then it would be much easier to merge just 1.9-and-earlier
> changes to 1.9, etc. (And it would save us writing a parser)

Or, along the same lines, like Julian suggested as third option in his
first mail in this thread:

> 3) Maintain change lists per branch: combine them programmatically

trunk/CHANGES: only contains future stuff (1.11 at this time)
1.10.x/CHANGES: only 1.10.0 and up
1.9.x/CHANGES: only 1.9.0 and up

When a new branch is created, it takes along the CHANGES file from
trunk (as it should), and we clear the CHANGES on trunk as part of
"post-branch housekeeping".

IMHO, no parsing needed, and no concatenation needed either (why would
CHANGES in a 1.9.x tarball need to contain changes of the 1.8 line?)

Hmmm, that would probably break scripts / links / workflows that
expect trunk/CHANGES to contain all of them ...
Maybe we could add a new BRANCH-CHANGES that fulfills the role
described above (only containing changes relevant to that branch),
also on trunk, and ... dunno, do something creative for providing the
concatenated CHANGES on the trunk/CHANGES url :-).

Received on 2018-07-16 21:46:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.