Re: sourceforge issues

[Bruce Stephens <bruce+zsh@xxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx> writes:

[...]

> - Sven (and everyone else), I'm afraid you're now responsible for adding
>   your own ChangeLog entries, ideally in the same commit.  Bummer.  (Tee,
>   hee, hee.)

Do you mean RCS log messages, or really ChangeLog entries?  If the
latter, surely that can be generated from the RCS information?
(That's how most free software projects do it, anyway: just run
vc-update-change-log in Emacs.)

> - Geoff, I agree the number of tags makes things difficult.  I won't
> be adding per-patch tags myself, though I can see the point of it
> since CVS doesn't make it easy for you to regenerate a patch
> otherwise.  It would probably be good to remove the old ones, though
> it's quite useful to be able to go straight to what a patch did.

At work, for committing things we construct a special file (a change
report) which lists all the files associated with this change together
with the change messages.  (I'm sure lots of other places use the same
duct-tape type approach.)  Then, we have a Perl script which
automatically commits the files with the given log messages (it
prepends the name of the change report, for easy cross-referencing).
It also updates the change report, including the RCS version number of
all the committed files.

So, before, it might look like this:

# ------------------------------------------------------------
Source-change: zsh/functions/foo
Source-change: zsh/functions/bar
        Update for zarf.

Source-change: zsh/functions/zap [new]
        New file.  Function for zapping trops.
# ------------------------------------------------------------

and after, it gets the version numbers

Source-change: zsh/functions/foo (1.2)

and so on.

And the log messages in the files look like:

        CR20000403A.  Update for zarf.

Presuming that CR20000403A is the name for the change report.

Obviously, the change report contains lots more information which
probably isn't relevant here, but the basic idea provides a way of
getting from a change in a file to related changes in other files (via
the change report, whose identifier is in the RCS logs), and it offers
a way of using the same change logs across multiple directories.
Well, the script does, anyway.  All without using a single extra tag.

And with a suitable script, one can reconstruct a patch for a specific
change report, since the change report contains the version numbers
for the relevant files.  Branches make this a bit fiddly, but
generally it's easy.

I probably don't have permission to supply the relevant Perl scripts,
but they probably do more than we'd want for this, and given the basic
idea, anybody could produce similarly functional scripts very quickly.

Hmm, I guess all this relies on having somewhere to store change
reports (or their equivalent).  We just use a directory (and keep them
under RCS, so we can track changes to the change reports, too).  Maybe
use another module in CVS or something?