zsh-workers
 help / color / mirror / code / Atom feed
From: Bruce Stephens <bruce+zsh@cenderis.demon.co.uk>
To: zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: Re: sourceforge issues
Date: 03 Apr 2000 23:14:24 +0100	[thread overview]
Message-ID: <87itxyomrj.fsf@cenderis.demon.co.uk> (raw)
In-Reply-To: Peter Stephenson's message of "Mon, 03 Apr 2000 21:45:11 +0100"

Peter Stephenson <pws@pwstephenson.fsnet.co.uk> 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?


  parent reply	other threads:[~2000-04-03 22:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-03 20:45 Peter Stephenson
2000-04-03 21:50 ` Adam Spiers
2000-04-04  0:13   ` Bart Schaefer
2000-04-03 21:52 ` Clint Adams
2000-04-04 19:38   ` Peter Stephenson
2000-04-03 22:14 ` Bruce Stephens [this message]
2000-04-03 23:00 ` Zefram
2000-04-04  0:09 ` Bart Schaefer
2000-04-04  0:14   ` Chmouel Boudjnah
2000-04-04 19:31   ` Peter Stephenson
2000-04-04  1:27 ` Geoff Wing
2000-04-04  3:23 ` Clint Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87itxyomrj.fsf@cenderis.demon.co.uk \
    --to=bruce+zsh@cenderis.demon.co.uk \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).