Re: PATCH: AIX dep.&doc fix; development guidelines

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 5,  5:52pm, Oliver Kiddle wrote:
} Subject: PATCH: AIX dep.&doc fix; development guidelines
} 
} 1. Has there been a final solution on how we are supposed to create the
} ChangeLog entries.

Peter wants each developer to create his own.  This causes some oddities
e.g. when Sven and I were both patching today -- article number refs get
out of order, and I had to restart my commit because Sven sneaked one in
between my "cvs update" and finishing writing the log message.

} It'd be nice to have a solution that doesn't depend on using emacs
} (I'm more than happy to learn cvs but don't have the time, inclination
} or disc space to learn emacs).

You don't need emacs.  The ChangeLog format is pretty obvious.  The only
reason for emacs (or for a perl tool like cvs2cl) is to automatically
insert the date and create the ChangeLog entries from the commitlogs.
Which of course means that you have to edit and commit ChangeLog after
you've commited the rest, which is slow and subject to races like the
one I just described when working with a remote server.

So I've pretty much decided I'll have to edit ChangeLog by hand and
commit it at the same time as everything else.

} Is the ChangeLog modified just like any other file on the cvs server?

Yes.

} If people can only send a patch should they still include a patch for
} ChangeLog?

I'd say no; let the person who actually applies the patch write the log.

} 2. Should we still post patches for everything in addition to commiting
} to cvs? For some things (like these AIX dependencies) it is hardly
} worth it.

I confess I've already fixed a couple of minor typos (no-op things, the
equivalent of whitespace changes) without sending a patch to the list.

But with e.g. my patch to Makefile.in, I mailed off the "cvs diff" output
and then waited for the patch to come back to me before committing, so I
could reference the article number in the commitlog.  It appears that Sven
has been doing this too.

} 3. The .distfiles thing should be mentioned. I take it that we just add
} and remove files from the list in it if we add and remove files?

That's correct.

I forget how the CVS commitinfo script works with a remote server.  On a
local server it's possible to write a commitinfo to check that .distfiles
mentions any files that are being added.

BTW, I've just been putting the finishing touches on a script to keep my
local repository in sync with the sourceforge one while still preserving
all my local hacks.  It approximately implements "cvs update -j..." on
two sandboxes (one updated from cvs.zsh.sourceforge.net, the other from
my local repository) by way of an intermediate tree that serves as the
common ancestor (I used the -dev-21 release).  So it means keeping three
copies of the source, but I only have to type three words to download
everything from sourceforge and merge it into my local sandbox.

If anyone is interested in this script I can post it.  It requires GNU
diff with diff3, and patch.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com