sourceforge issues

sourceforge issues

[Peter Stephenson]

This is various stuff about sourceforge including replies to various
messages.  I'm sure I've forgotten something.

- The developer permissions screen has started working again and all
  developers have admin permissions for things like bugtracking, so
  bugs can be closed (still have to do this to a couple if I remember).

- Clint, I'm assuming this is you.
    Login: clint                            Name: Clint Adams
    Directory: /home/users/clint            Shell: /bin/bash
    Last login Mon Apr  3 12:30 (PDT) on pts/77 from ghanima.ps.nyc.globix.net
  I think I need to wait for the next cron update for the web stuff to
  see this, so either Adam or I can add you tomorrow.  It worked when
  I added `clint' but it showed up as `Clint', so I smelled a rat.
  Using the uid 25200 was rejected, hence my current thesis.

- 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.)

- 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.

- Adam, the only files I can find under /home/groups/zsh on sourceforge
  which are still in group users rather than zsh  (I've discovered this
  neat shell where you do `chgrp zsh **/*(f:g+w:g:users:)' ...) are links
  for bits of yodl, where the group doesn't matter.

- Oliver: yes my mail address for the zsh list is old, but luckily still
  forwarding.  I'll ask Karsten to change it.

- Idle question, but does anyone know of an automated way of getting the
  latest version of a file from the CVS archive via the web, without CVS?
  What I mean is, can you tell people to `get the latest version of
  _path_files from <URL_prefix>Completion/Core/_path_files<URL_suffix>'?
  As far as I can see the cvsweb.cgi interface needs you to tell it a
  version number which would put paid to this.  The may be some feature
  I haven't seen.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: sourceforge issues

[Adam Spiers]

Peter Stephenson (pws@pwstephenson.fsnet.co.uk) wrote:
> - 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.)

*grin*  But presumably you were already auto-generating these with
emacs (C-x v a) or rcs2log so there wasn't much work involved anyway?

> - Idle question, but does anyone know of an automated way of getting the
>   latest version of a file from the CVS archive via the web, without CVS?
>   What I mean is, can you tell people to `get the latest version of
>   _path_files from <URL_prefix>Completion/Core/_path_files<URL_suffix>'?
>   As far as I can see the cvsweb.cgi interface needs you to tell it a
>   version number which would put paid to this.  The may be some feature
>   I haven't seen.

I don't know of an existing way, but if we set it up so that
the /home/groups/zsh/zsh working copy automatically gets updated after
every commit (easily done) then it would be trivial to write a CGI
which makes this possible.

Adam

Re: sourceforge issues

[Bart Schaefer]

On Apr 3, 10:50pm, Adam Spiers wrote:
> Subject: Re: sourceforge issues
> Peter Stephenson (pws@pwstephenson.fsnet.co.uk) wrote:
> > - 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.)
> 
> *grin*  But presumably you were already auto-generating these with
> emacs (C-x v a) or rcs2log so there wasn't much work involved anyway?

Oops, I mistyped the keystrokes for vc-update-changelog; Adam's got it.

There's also cvs2cl:

	http://www.red-bean.com/~kfogel/cvs2cl.shtml

Re: sourceforge issues

[Clint Adams]

> - Clint, I'm assuming this is you.
>     Login: clint                            Name: Clint Adams
>     Directory: /home/users/clint            Shell: /bin/bash

Yes, that's me.

>   I think I need to wait for the next cron update for the web stuff to
>   see this, so either Adam or I can add you tomorrow.  It worked when
>   I added `clint' but it showed up as `Clint', so I smelled a rat.
>   Using the uid 25200 was rejected, hence my current thesis.

Well, my web login is `Clint' but my unix login was lowercased.
Furthermore, my web uid seems to be 22789 though my unix uid is 25200.
Hmm.

Re: sourceforge issues

[Peter Stephenson]

Clint Adams wrote:
> Well, my web login is `Clint' but my unix login was lowercased.
> Furthermore, my web uid seems to be 22789 though my unix uid is 25200.
> Hmm.

Wunderbar.  I added 22789 this time, and it showed up as `Clint' again, so
I suppose my worries were misplaced.

I'm glad it's not the *same* number, that would have been, er,...

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: sourceforge issues

[Bruce Stephens]

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?

Re: sourceforge issues

[Zefram]

Peter Stephenson wrote:
>- 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.)

Feature.  The lack of this kind of convention is one of the things that
bugged me about the old single-maintainer repository system.

>- 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.

In my personal repository, I always used to include the patch number
(from the mailing list) in the log message.  This doesn't make it *easy*
to extract the patch from the archive, but it makes it possible (it
certainly points you towards a good set of date tags to compare), and in
cases where the patch exists separately (e.g., it's on the mailing list)
it provides a handy reference.  If we're going to have patches in CVS
that don't appear on the mailing list, it's still possible to come up with
unique IDs: we just need to each keep track of our own sequence numbers.

>  As far as I can see the cvsweb.cgi interface needs you to tell it a
>  version number which would put paid to this.  The may be some feature
>  I haven't seen.

The pseudo-label "HEAD" is supposed to evaluate to the latest
version on the trunk.  Does this web interface accept version labels?

-zefram

Re: sourceforge issues

[Bart Schaefer]

On Apr 3,  9:45pm, Peter Stephenson wrote:
> Subject: sourceforge issues
> 
> - 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.)

In Emacs vc, `C-x C-v a' will update ChangeLog by incorporating all CVS logs
since the last commit of ChangeLog.  (This works best if you actually start
by visiting ChangeLog.)  So it's not hard to simply ignore ChangeLog until
you're about to do a release, and then bring it up to date.  That's what I
do with 3.0.x, anyway.

Re: sourceforge issues

[Chmouel Boudjnah]

"Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

> In Emacs vc, `C-x C-v a' will update ChangeLog by incorporating all CVS logs

Humm no :

C-x v a runs the command vc-update-change-log
   which is an interactive compiled Lisp function in `vc'.
(vc-update-change-log &rest ARGS)

Find change log file and add entries from recent RCS/CVS logs.
Normally, find log entries for all registered files in the default
directory using `rcs2log', which finds CVS logs preferentially.
The mark is left at the end of the text prepended to the change log.

With prefix arg of C-u, only find log entries for the current buffer's file.

With any numeric prefix arg, find log entries for all currently visited
files that are under version control.  This puts all the entries in the
log for the default directory, which may not be appropriate.

>From a program, any arguments are assumed to be filenames and are
passed to the `rcs2log' script after massaging to be relative to the
default directory.

not control-v

-- 
MandrakeSoft Inc                http://www.mandrakesoft.com
Pasadena, CA USA                                  --Chmouel

Re: sourceforge issues

[Peter Stephenson]

"Bart Schaefer" wrote:
> In Emacs vc, `C-x C-v a' will update ChangeLog by incorporating all CVS logs
> since the last commit of ChangeLog.  (This works best if you actually start
> by visiting ChangeLog.)  So it's not hard to simply ignore ChangeLog until
> you're about to do a release, and then bring it up to date.  That's what I
> do with 3.0.x, anyway.

I think that's a less good idea when the development is so open, I mean
running C-x v a is all right but it should be done with each commit so that
it's easy to see what's gone in.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: sourceforge issues

[Geoff Wing]

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

If you can see the cvs log information easily then you can just checkout the
source at a certain date (either before or after the patch).  Or if want
something specific to a file or set of files, generate a ChangeLog with
version numbers, e.g. using a fairly current version of rcs2log, then you
can get the affected files by version number.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: sourceforge issues

[Clint Adams]

> - Idle question, but does anyone know of an automated way of getting the
>   latest version of a file from the CVS archive via the web, without CVS?
>   What I mean is, can you tell people to `get the latest version of
>   _path_files from <URL_prefix>Completion/Core/_path_files<URL_suffix>'?
>   As far as I can see the cvsweb.cgi interface needs you to tell it a
>   version number which would put paid to this.  The may be some feature
>   I haven't seen.

Stock cvsweb checks the revision for the Perl RE /^[\d\.]+$/, so
while CVS will happily take a -r HEAD, cvsweb won't.  I assume that
SourceForge's custom version doesn't have this changed.

I see two other groups on our server have their own cvsweb.cgi,
so one might assume that we can put a custom version up ourselves.

Alternately, someone could set up a cronjob to export -r HEAD
to the web dir repeatedly, but that's a bit uglier, IMO.