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

Re: 1.4.0 CHANGES - or: how to spend a weekend...

From: David Anderson <david.anderson_at_calixo.net>
Date: 2006-05-18 18:57:02 CEST

* Ben Collins-Sussman <sussman@red-bean.com> [2006-05-18 09:16:16]:
> Yes, it will take about 6 hours, based on the fact that I've done this
> process for every release. Unfortunately, I don't have time to do it
> this time around. :-( Would somebody else be willing to volunteer?

I can give it a go. If I sit around pretending to be the release
manager, might as well go all the way :-).

> 1. Run 'svn log -rHEAD:16325
> http://svn.collab.net/repos/svn/branches/1.4.x'. I think this
> should give you every change ever made to the 1.4 line, including
> backports made to the 1.4.x branch. But then, as Peter said, you need
> to *remove* logs of changes that have already been released in 1.3.x
> bugfixes. You can just run 'svn log -q --stop-on-copy' on the 1.3.x
> branch, and then write a script to parse the revnums and remove them
> from your primary log output. Karl and I used to use emacs macros to
> do that. Maybe we should write a more general script. :-)

I think this has problems. What of backports that have been backported
into the 1.3.x branch in prevision of 1.3.2, and that have also been
backported into hte 1.4.x branch? In which version should those
changes go? The filter needs to be adjusted accordingly.

Or maybe we need to release 1.3.2 first, then start writing CHANGES
for 1.4.x, with a clean 1.3.x branch?

Also, if the 1.3.x branch is also being tracked by svnmerge (I can do
the admin to make it so if necessary), it would be fairly easy to
locate which revs have already been backported.

> 2. Read that log from oldest to newest, summarizing points as you go.
> The trick is to know what level of detail to write at: you don't
> want to mention every tiny little commit, but you don't want to be too
> general either. I usually set my filter-level by reading through a
> few pages of the CHANGES file before I start writing the new one, just
> to keep things consistent.

This is a large problem we currently have imho, that the granularity
is pretty much ad-hoc. Hopefully following your advice of reading
back through previous CHANGES will work out okay.

- Dave.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 18 18:56:07 2006

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