From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7353 invoked from network); 3 Apr 2000 22:15:20 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 3 Apr 2000 22:15:20 -0000 Received: (qmail 4139 invoked by alias); 3 Apr 2000 22:15:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10437 Received: (qmail 4128 invoked from network); 3 Apr 2000 22:15:13 -0000 From: Bruce Stephens To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: sourceforge issues References: Date: 03 Apr 2000 23:14:24 +0100 In-Reply-To: Peter Stephenson's message of "Mon, 03 Apr 2000 21:45:11 +0100" Message-ID: <87itxyomrj.fsf@cenderis.demon.co.uk> User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/21.2 (Kastor & Polydeukes) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: bruce@cenderis.demon.co.uk Peter Stephenson 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?