sourceforge.net CVS tree ready for use

sourceforge.net CVS tree ready for use

[dmeyer]

In article <000201bf9c8b$a6655830$21c9ca95@mow.siemens.ru> you write:
> I successfully checked out and compiled Zsh from CVS. Congratulations!
> 
> Offtopic: anybody knows, how to find out, what branch was checked out?
> And the date? I mean, now, when reporting problems, we need some way to
> refer to "CVS branch xxx checked out/updated at yyy"

status -v <filename> will tell you if there is a sticky tag -
including sticky branch tag - or sticky date for a particular file.
It's pretty much up to you not to do anything foolish like check out
different files from different branches.

For the "checked out/updated at yyy" problem, I think the best
solution is for most people to use labeled versions, which shouldn't
be too onerous as long as folks are smart about creating new (and
cleaning up old and useless) labels.


-- 
David M. Meyer
dmeyer0@bellatlantic.net

move to sourceforge.net in progress

[Adam Spiers]

Peter Stephenson (pws@pwstephenson.fsnet.co.uk) wrote:
> Adam Spiers wrote:
> > ----- Forwarded message from Drew Streib <ds@varesearch.com> -----
> > 
> > I've looked at this and it doesn't appear to conflict with any part of the
> > OSI definition. I would approve the license on this. :)
> 
> Oh, hell.  That means we've run out of excuses.

Mission accomplished ;->

> Does someone else, such as Adam, want to set this up?

'Tis done.  I'll let you know when the SourceForge admins have
approved the request (assuming they do).  It should be within 24 hours
or so.  In the meantime, it would be good if everyone who hasn't
already got one creates themselves a SourceForge account.  Don't
worry; this is a remarkably painless operation and takes hardly any
time.  Just go to

  https://sourceforge.net/account/register.php

I presume everyone has access to an SSL-enabled browser?

Peter, once you've got an account I'll transfer the relevant project
administrator privileges to you.  Bart, I presume you won't want to
bother making a CVS tree for 3.0.x available, but if you do, let me
know and I'll give you admin privileges too.  Of course, once we have
the repository up and running smoothly, there's no technical
limitation preventing us from having several developers with commit
access to the development tree, but I'll assume that we want to carry
on with Peter as the sole "patch pumpking" unless I hear otherwise.

By the way, the home page is at 

  http://sourceforge.net/ 

if you want to have a look round, although I'm sure you already
figured that out.

> Clint's right that the licence details in the source code needing
> tidying up.

Yep, we definitely need to move all the individual copyrights into
LICENSE or Etc/LICENSE or something.  That's going to be a fun job for
someone :-/

Adam

Re: move to sourceforge.net in progress

[Peter Stephenson]

Adam Spiers wrote:
> Peter, once you've got an account I'll transfer the relevant project
> administrator privileges to you.

OK, I've got an account with the spur-of-the-moment choice of username
`pws'.  Now I need to work out how it works.

I would expect that Bart and Sven would be committing their own CVS
changes.  Those seem to be the obvious choices for now --- due entirely to
where most of the patches and design decisions currently happen to
originate, and no other reason --- though it doesn't need to stay that way,
and anybody it's sensible to add can be added.  I will keep the (much
reduced) workload of adding other people's stuff.

There's also no reason why periodic development versions shouldn't continue
to appear on the existing archive site (= they will).

I'm also less then enthralled about the idea of multiplying experimental
CVS branches, which can get incredibly messy.  To begin with, I think we
should perhaps continue with the policy of just not adding possibly
contentious patches.  At least, what I want to avoid is repeated merges
from experimental branches to the main tree; the world's lunatic asylums
are full of people who've tried that.

I also think it would help solidarity if all patches continue to appear on
the mailing list (this will of course be necessary for anyone other than
the three of us).

> Yep, we definitely need to move all the individual copyrights into
> LICENSE or Etc/LICENSE or something.  That's going to be a fun job for
> someone :-/

As Bart says, the individual copyrights are strictly speaking legal
entities and need to stay there.  I will add a catch-all central licence
(which is how we spell it over here, even if Mandrake's ispell is using an
overseas dictionary), which will make it clear that anything in individual
files takes precedence.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

sourceforge.net CVS tree ready for use

[Adam Spiers]

The CVS repository at sourceforge.net has been prepared from a recent
(everything up to 10250, I believe) copy of Tanaka's repository, and
is now ready for use.  See http://sourceforge.net/cvs/?group_id=4068
for details on how to use it.  Developers with write-access are
recommended to login to the web interface, click on `Account
Maintenance', and then under `Shell Account Information' click on
`Edit Keys' to add an authorized ssh key so that you don't have to
enter a password every time you do a CVS commit.

It would be nice if the web pages (and maybe FAQ?) could be modified
to mention the availability of this resource.  Oliver, had any luck
with that problem yet?

Re: sourceforge.net CVS tree ready for use

[Peter Stephenson]

Adam Spiers wrote:
> The CVS repository at sourceforge.net has been prepared from a recent
> (everything up to 10250, I believe) copy of Tanaka's repository, and
> is now ready for use.

Excellent, thank you very much.  I have added all the changes up to date,
namely my patch for LICENCE.  (Do you want `make prep' to copy that to
LICENSE? :-/) So the usual suspects are welcome to commit their own
changes.

One question is whether we commit CVS changes straight away, i.e. when the
patch is posted to the list, or wait for comments.  The latter will be a
little messy, since other developers would have to apply the patch to try
it, then remove it to avoid CVS reporting a conflict.  So I think with
non-contentious patches we might as well do it simultaneously.

We should certainly think about Andrej's suggestion that the patches can be
moved offlist now we have a regular repository.  As we have write
permission on sourceforge, a way for doing that over the net could probably
be handled.  Or maybe Geoff can think of something he can set up.

Some time, probably tomorrow since I'm zsh'd out, I shall
 - finalise 3.1.6-dev-21 and put it in the usual place, too
 - post an announcement to zsh-announce about the availablity of the CVS
   archive at sourceforge
 - all the other stuff I've forgotten to do which you're going to
   remind me.

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

Re: sourceforge.net CVS tree ready for use

[Bart Schaefer]

On Apr 1,  9:51pm, Peter Stephenson wrote:
} Subject: Re: sourceforge.net CVS tree ready for use
}
} One question is whether we commit CVS changes straight away, i.e. when
} the patch is posted to the list, or wait for comments. The latter will
} be a little messy, since other developers would have to apply the
} patch to try it, then remove it to avoid CVS reporting a conflict.

CVS will only report a conflict if the checked-in version differs from
the patched version. Otherwise it'll just say "... already contains the
changes ...". The most likely source of actual conflicts would be when
some patches have been applied from the list but aren't yet in the CVS
repository, or the reverse.

} We should certainly think about Andrej's suggestion that the patches
} can be moved offlist now we have a regular repository. As we have
} write permission on sourceforge, a way for doing that over the net
} could probably be handled. Or maybe Geoff can think of something he
} can set up.

A shortcoming of CVS is that there's no reasonable way to generate a
patch from it without either (a) tagging both before and after every
commit (and the before-tag also had better be after updating, or you
create overlapping patches), or (b) generating the patch by diffing
against the modified sandbox before committing.  Of course, only the
developer who actually made the changes can do (b); if he wants anyone
else to be able to regenerate his patch, he has to do (a).

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

Re: sourceforge.net CVS tree ready for use

[Adam Spiers]

Peter Stephenson (pws@pwstephenson.fsnet.co.uk) wrote:
> One question is whether we commit CVS changes straight away, i.e. when the
> patch is posted to the list, or wait for comments.  The latter will be a
> little messy, since other developers would have to apply the patch to try
> it, then remove it to avoid CVS reporting a conflict.  So I think with
> non-contentious patches we might as well do it simultaneously.

I'm in agreement with that, FWIW.

> We should certainly think about Andrej's suggestion that the patches can be
> moved offlist now we have a regular repository.

It's a nice idea, doesn't it then become hard to refer to
individual patches?  There needs to be some clearly accessible
many-to-many relationship between e-mails to zsh-workers and
patches (including patches which don't ever get committed).

> As we have write permission on sourceforge, a way for doing
> that over the net could probably be handled.  Or maybe Geoff
> can think of something he can set up.

I propose the following system (which should probably be taken
with a pinch of salt, as I am very far from being a core
developer):

We set up automatic e-mail notification of any commits.  (This
would be easy enough[0].)  These notifications would contain the
CVS commit log message (a brief summary of the patch in the same
style as pws' ChangeLog entries, i.e. including zsh-workers
referral numbers) and the patch itself, and they would go to
zsh-workers in some computer-filterable format.  (They could go
to a separate list, e.g. zsh-cvs-commits.  The important thing
is that they get stamped with a sequence number for referral
like all e-mails to the lists currently do.  Personally I would
prefer them to go to zsh-workers, as we probably all have basic
filtering capabilities, and we don't want to have two sets of
overlapping sequences numbers which we're regularly referring
to.)

Patches continue to be sent to zsh-workers with the normal
accompanying explanation; however in the cases where a developer
with write-access[1] is making a trivial non-contentious change,
this could probably be skipped, as the CVS commit log message
would suffice as an explanation.

Patches sent to the list by a developer with write-access would
simultaneously be committed to the tree.  Patches sent to the
list by anyone else would either be rejected or committed to the
tree by the pumpking (currently Peter).

This system would mean:

 - most importantly, not too much extra work for those with
   write-access (I think?),

 - also importantly, the flow of discussion interspersed with
   patches would not be interrupted,

 - there would be a clear distinction between ideas (patches
   proposed) and action (patches used), and developers without
   write-access would have a nice easy way to see whether their
   own patches have made it into the tree,

 - developers could choose quite precisely how closely they wished
   to monitor development (some may only want to follow
   discussion, others may only want to see commits to the tree), and

 - the pumpking wouldn't have to worry about
   last-minute-before-release minor tweaks being hidden and
   hence puzzling people as to how they happened.

Does it have any problems I've missed?


>  - all the other stuff I've forgotten to do which you're going to
>    remind me.

One small change to the guide -- in 6.5.3, under `URLs for web
browsers', you wrote `Arguably the system should be able to scan your
browser's bookmarks file, but currently it won't.'  This isn't
entirely true, as the distribution includes Misc/make-zsh-urls for
this purpose.


Adam


[0] We've already done this at the place I work at.

[1] Incidentally I include myself in this category even though I
currently have write-access -- I'm not a core developer, so I'm
deliberately using the repository via :pserver:anonymous to avoid
messing anything up.

Re: sourceforge.net CVS tree ready for use

[Bart Schaefer]

On Apr 2,  1:45am, Adam Spiers wrote:
} Subject: Re: sourceforge.net CVS tree ready for use
}
} We set up automatic e-mail notification of any commits.  (This
} would be easy enough[0].)

I'm curious whether you've found a way to prevent the generation of
one message per subdirectory when a commit spans several subdirs.
CVS is rather insistent that every directory is a "module" ... and
given that there are 8 subdirectories under Completion alone, we
certainly don't want one mesage per directory per commit fired off
to zsh-workers (or even to some new zsh-cvs-commits list).

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

Re: sourceforge.net CVS tree ready for use

[Geoff Wing]

Bart Schaefer <schaefer@candle.brasslantern.com> typed:
:On Apr 2,  1:45am, Adam Spiers wrote:
:} Subject: Re: sourceforge.net CVS tree ready for use
:} We set up automatic e-mail notification of any commits.  (This
:} would be easy enough[0].)
:I'm curious whether you've found a way to prevent the generation of
:one message per subdirectory when a commit spans several subdirs.
:CVS is rather insistent that every directory is a "module" ... and
:given that there are 8 subdirectories under Completion alone, we
:certainly don't want one mesage per directory per commit fired off
:to zsh-workers (or even to some new zsh-cvs-commits list).

Yes, I was about to request this.  Aggregation of commit messages which
occur at the same time, plus or minus a few seconds (to account for
directory spanning when people might use ! to CVS to reuse a log message),
and with the same log info would be very nice.  Somewhere I've got a perl
program to insert into CVSROOT/loginfo, though it depends on what we can
run on their server.  Otherwise some external aggregator should/could be
set up.

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.net CVS tree ready for use

[Adam Spiers]

Geoff Wing (mason@primenet.com.au) wrote:
> Bart Schaefer <schaefer@candle.brasslantern.com> typed:
> :On Apr 2,  1:45am, Adam Spiers wrote:
> :} Subject: Re: sourceforge.net CVS tree ready for use
> :} We set up automatic e-mail notification of any commits.  (This
> :} would be easy enough[0].)
> :I'm curious whether you've found a way to prevent the generation of
> :one message per subdirectory when a commit spans several subdirs.
> :CVS is rather insistent that every directory is a "module" ... and
> :given that there are 8 subdirectories under Completion alone, we
> :certainly don't want one mesage per directory per commit fired off
> :to zsh-workers (or even to some new zsh-cvs-commits list).

The program we use at work does cope with commits spanning multiple
subdirs, but I suspect this only happens when all files/dirs being
committed are mentioned on the command-line.

> Yes, I was about to request this.  Aggregation of commit messages which
> occur at the same time, plus or minus a few seconds (to account for
> directory spanning when people might use ! to CVS to reuse a log message),
> and with the same log info would be very nice.

Very nice, but probably very hard!

> Somewhere I've got a perl program to insert into CVSROOT/loginfo,
> though it depends on what we can run on their server.

We can put anything we want in our CVSROOT/loginfo, so I don't think
we're limited by sourceforge.

Re: sourceforge.net CVS tree ready for use

[Bart Schaefer]

On Apr 2, 11:02pm, Adam Spiers wrote:
} Subject: Re: sourceforge.net CVS tree ready for use
}
} The program we use at work does cope with commits spanning multiple
} subdirs, but I suspect this only happens when all files/dirs being
} committed are mentioned on the command-line.

I almost never mention *any* files or directories on the command line.
I just "cvs commit" (implicitly recursively) from the top-level dir.

} Geoff Wing (mason@primenet.com.au) wrote:
} > Aggregation of commit messages which occur at the same time, plus or
} > minus a few seconds (to account for directory spanning when people
} > might use ! to CVS to reuse a log message), and with the same log
} > info would be very nice.

I often find myself editing the commit message at each directory to be
specific about what's changing in that set of files. Aggregating by the
process ID of the originating cvs process, rather than by time, would
be far more useful.

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

RE: sourceforge.net CVS tree ready for use

[Andrej Borsenkow]

I successfully checked out and compiled Zsh from CVS. Congratulations!

Offtopic: anybody knows, how to find out, what branch was checked out?
And the date? I mean, now, when reporting problems, we need some way to
refer to "CVS branch xxx checked out/updated at yyy"

-andrej

Re: sourceforge.net CVS tree ready for use

[Geoff Wing]

Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> typed:
:I successfully checked out and compiled Zsh from CVS. Congratulations!
:
:Offtopic: anybody knows, how to find out, what branch was checked out?
:And the date? I mean, now, when reporting problems, we need some way to
:refer to "CVS branch xxx checked out/updated at yyy"

If you didn't specify a branch then you're using the main branch (the trunk).
Otherwise you can find branch names by doing a ``cvs log -h <...>'' on some
existing file (provided it's branched).  Symbolic names with two numbers (one
dot) are names on the main branch (i.e. static tags).  Those with four (or
six or eight ...) numbers are branch tags.  If you're going to report a
problem for a branch (or the main trunk) then presumably you would have
updated your tree to be current.  Then the problem can be believed to be
existing at the time you post a problem report.

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.net CVS tree ready for use

[Bart Schaefer]

On Apr 2, 10:35am, Geoff Wing wrote:
} Subject: Re: sourceforge.net CVS tree ready for use
}
} Symbolic names with two numbers (one dot) are names on the main branch
} (i.e. static tags). Those with four (or six or eight ...) numbers are
} branch tags.

However, CVS only assigns new branch numbers when absolutely necessary,
so there may be files on the main trunk that have four or more numbers
in their revision.

IIRC, Tanaka was maintaining his repository entirely as "cvs import"s of
a master patch tree.  Thus before PWS's commit, every file in the whole
repository appeared to be on the "vendor branch."  Now, only those files
that PWS updated (patches between 10250 and 10376, so far) have trunk
revision numbers (mostly 1.2) while the rest still appear to be on the
branch (even though you get them with a main trunk checkout).

Confused enough yet?

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

Re: sourceforge.net CVS tree ready for use

[Geoff Wing]

Bart Schaefer <schaefer@candle.brasslantern.com> typed:
:IIRC, Tanaka was maintaining his repository entirely as "cvs import"s of
:a master patch tree.  Thus before PWS's commit, every file in the whole
:repository appeared to be on the "vendor branch."  Now, only those files
:that PWS updated (patches between 10250 and 10376, so far) have trunk
:revision numbers (mostly 1.2) while the rest still appear to be on the
:branch (even though you get them with a main trunk checkout).

The other thing about doing imports:  >1200 tags - Umm, do we really need
all these still?  >1000 are of the form: zsh-workers_* 
I think sometime in the future when the tree is considered to be in 
a correct state, most or all of those can get deleted.  They make
``cvs log'' somewhat cumbersome (especially when it's nice to glance at
a tag list) and won't really serve any useful purpose.

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.net CVS tree ready for use

[Oliver Kiddle]

Adam Spiers wrote:

> It would be nice if the web pages (and maybe FAQ?) could be modified
> to mention the availability of this resource.  Oliver, had any luck
> with that problem yet?

I can checkout the zsh source from the sourceforge CVS so maybe my
company's firewall wan't the problem. I'll try again when my new modem
arrives and then can atleast discount the firewall as the problem.

I know I don't do much more than the odd patch to the completion
functions but it would be useful if I could be added to the developer
list on sourceforge (my username is opk).

Oliver

Re: sourceforge.net CVS tree ready for use

[Adam Spiers]

Oliver Kiddle (opk@u.genie.co.uk) wrote:
> Adam Spiers wrote:
> > It would be nice if the web pages (and maybe FAQ?) could be modified
> > to mention the availability of this resource.  Oliver, had any luck
> > with that problem yet?
> 
> I can checkout the zsh source from the sourceforge CVS so maybe my
> company's firewall wan't the problem. I'll try again when my new modem
> arrives and then can atleast discount the firewall as the problem.
> 
> I know I don't do much more than the odd patch to the completion
> functions but it would be useful if I could be added to the developer
> list on sourceforge (my username is opk).

I've added you to the list, but for now there seems to be some problem
with sourceforge (maybe related to the error handler bug Bart spotted
earlier, which does in fact affect me too) preventing me from updating
developer permissions, so if you don't have enough permissions there's
not much I (we?) can do right now.  I've submitted reports of these
bugs to sourceforge's own bug tracker so hopefully they'll be resolved
soon.  Noone's awake on the #sourceforge IRC channel unfortunately.