Xapian devel - Mar 2007 - svn-ci script (was: Re: [Xapian-commits] 7830: trunk/xapian-core/)

On Fri, Mar 02, 2007 at 12:20:44PM +0000, richard wrote:
> * HACKING: Add note about how to generate ChangeLog timestamps
>   using the unix date command - and I've started generating them in
>   the same format as Olly is. (I hope.)
I actually use a perl script which does:

    print CO strftime("%a %h %d %H:%M:%S %Z %Y", localtime);

But %b and %h are just aliases and %T is %H:%M:%S, so your date command
should produce identical results.

I guess my "svn ci" wrapper script is probably useful to other people
with commit access, so I've just committed it to
xapian-maintainer-tools.  Feel free to use it as is, hack it about, or
just ignore it:

http://svn.xapian.org/trunk/xapian-maintainer-tools/svn-ci?view=markup

It writes the tedious parts of the ChangeLog entry for you, and pastes
in "svn diff" for the files/directories you are committing, which I
find
helps avoid me checking in other changes that might be in my tree by
mistake, and helps make sure I document all changes in the ChangeLog
entry.  It also massages the ChangeLog entry into a suitable SVN commit
message.  If you fail to delete all the diff fragments or conflict
markers, it won't let you commit.

It has a few foibles, but generally you get to see them before it
commits at least.  The only exception is that if ChangeLog is modified
and doesn't appear to have diff fragments or conflict markers, it will
commit without asking for further confirmation.

It's not always too smart about directories with property changes.

If you just quit the editor (it doesn't commit because there are diff
fragments still) and then rerun "svn-ci" with a different list of
files/directories, the script keeps the old list of files which is
not really the right thing.  The workaround is to "svn revert
ChangeLog"
to reset the ChangeLog.

If you leave the editor window for 3 days, then save, the date on
the ChangeLog entry isn't updated and so can be very different to the
date of the commit, which hinders pulling out patches.  I've been
wondering if adding the SVN revision which this commit will get would
be a better fix, though I'm not totally sure how to find it reliably.
"$Rev$" isn't what we want...

If there's a conflict because someone else has committed since you last
ran "svn up", the current way I would resolve this is:

svn up
[resolve any code conflicts]
[check the tree builds if there have been code changes]
svn resolved ChangeLog
svn-ci [same list of files]
[Delete the 3 lines marking the conflict by hand]

I wrote this long before I saw debian's "dch" tool - it could
probably
usefully borrow ideas from that.

Cheers,
    Olly