CVS'r'us

CVS'r'us

[Lars Magne Ingebrigtsen]

Thanks to Steven's RCS repository of Gnusae past (along with my
archive of old (ding) patches and releases) I've now constructed a CVS
repository of all Gnus 5 releases -- ever.  (Well, I'm missing a few
releases here and there.)

Anybody want to see a diff between (ding) Gnus 0.73 and (ding) Gnus
0.77?  Huh?  Huh?  No?  Shoot.

I bet it'll come in real handy for that master's student in 2355 when
she's writing "The Semiology Of Primitive Newsreaders: A Case Study Of
The Development Of (ding) Gnus 0.5 To Aleph Gnus 0.99.34.97 In
Relation To Popular Music And Furniture Design In The Previous
Millennium".  Sure to be a best seller!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: CVS'r'us

[Steven L Baur]

Lars Magne Ingebrigtsen writes:

> Anybody want to see a diff between (ding) Gnus 0.73 and (ding) Gnus
> 0.77?  Huh?  Huh?  No?  Shoot.

Yes!  (I'm not a Gnus addict, really!  I can stop any time I like).
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: CVS'r'us

[Lars Balker Rasmussen]

Steven L Baur <steve@miranova.com> writes:
> Yes!  (I'm not a Gnus addict, really!  I can stop any time I like).

More like twice the addict the rest of us are :-)
-- 
Lars Balker Rasmussen             <URL:http://www.daimi.aau.dk/~gnort/>

			   Watch me not care.

Re: CVS'r'us

[Steven L Baur]

Lars Magne Ingebrigtsen writes:

> Anybody want to see a diff between (ding) Gnus 0.73 and (ding) Gnus
> 0.77?  Huh?  Huh?  No?  Shoot.

Yes!  (I'm not a Gnus addict, really!  I can stop any time I like).
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: CVS'r'us

[Samuel Tardieu]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> Thanks to Steven's RCS repository of Gnusae past (along with my
Lars> archive of old (ding) patches and releases) I've now constructed
Lars> a CVS repository of all Gnus 5 releases -- ever.  (Well, I'm
Lars> missing a few releases here and there.)

Great! The next step is to arrange an anonymous (or controlled)
read-only access for those of use who are willing to get incrementally
the latest revision or see at what point things have changed :-)

I know of some people who have done this already. One exemple is the
maintainer of phpfi. Here is an extract of the README file:

"
Getting Updates
---------------

  Entire new distributions of the package are made available frequently
  in the file archive at http://www.vex.net/php/files

  If you don't like re-installing every time you want to update your
  package, or if you are a programmer and want to make sure you always
  have the latest bleeding-edge version of the package, get a package
  called CVS.  It is available at prep.ai.mit.edu:/pub/gnu.  Get version
  1.7 or later.  Compile and install this package.  Make sure you enable
  client support.  Check the cvs-1.7/src/options.h file and verify that
  AUTH_CLIENT_SUPPORT is defined.

  Now type the following:

    cvs -d :pserver:cvsread@vex.net:/u/local/src/repository login

  When it asks you for a password enter: phpfi

  Then type:

    cvs checkout phpfi

  This will create a phpfi directory in your current directory.  It will
  take a bit of time, especially if your network connection is slow.  
  But once it is done, you will have an up to date copy of the master
  CVS source tree.  You can then at any time cd into this directory and
  type:
  
    cvs update

  to update your source tree to be in sync with the master tree.

  [...]

  Keep in mind that the CVS version may not always compile, or if it does
  compile, it may not be stable.  The CVS version is a development version
  and should be treated as such.
"

  Sam
--
Samuel Tardieu -- sam@inf.enst.fr

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

Samuel Tardieu <sam@inf.enst.fr> writes:

> Great! The next step is to arrange an anonymous (or controlled)
> read-only access for those of use who are willing to get incrementally
> the latest revision or see at what point things have changed :-)

[...]

>   You can then at any time cd into this directory and
>   type:
> 
>     cvs update
> 
>   to update your source tree to be in sync with the master tree.

This would be neato-keano.  However, I assume that I'll have to set up
some sort of account somewhere to allow people to access this.  I'm
not sysadmining any reachable system, so this may be a bit tricky...
And what are the security aspects here?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: CVS'r'us

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> This would be neato-keano.  However, I assume that I'll have
  Lars> to set up some sort of account somewhere to allow people to
  Lars> access this. [...]

The great advantage of :pserver: is that people *don't* need an
account to access this.  The CVS server has its own passwd file and
checks that for people who use that protocol to access CVS.  Do not
confuse this with the rsh access to CVS which is also possible where
people need an account on your system.

(The disadvantage of :pserver: is that the password and all data are
transmitted in the clear, but the CVS :pserver: isn't the only program
that has this problem...)

kai
-- 
because I couldn't think of a good beginning.

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:

> The great advantage of :pserver: is that people *don't* need an
> account to access this.  The CVS server has its own passwd file and
> checks that for people who use that protocol to access CVS.  Do not
> confuse this with the rsh access to CVS which is also possible where
> people need an account on your system.

Ah, right.  I've tried looking through the CVS documentation, but I
couldn't find any mention of this.  Is it on the web somewhere,
perhaps?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: CVS'r'us

[Scott Blachowicz]

> > The great advantage of :pserver: is that people *don't* need an
> > account to access this.  The CVS server has its own passwd file and
> > checks that for people who use that protocol to access CVS.  Do not
> > confuse this with the rsh access to CVS which is also possible where
> > people need an account on your system.
> 
> Ah, right.  I've tried looking through the CVS documentation, but I
> couldn't find any mention of this.  Is it on the web somewhere,
> perhaps?

Some CVS web pages...

	http://www.loria.fr/~molli/cvs-index.html
	http://www.cyclic.com:80/
	http://www.loria.fr/~molli/cvs/doc/cvsclient_6.html#SEC5
	http://www.loria.fr/~molli/cvs/doc/cvs_22.html#SEC24

...the last couple of pages are HTML-ized versions of some TeXinfo
documentation in the doc/ subdirectory of the cvs distribution (the one I'm 
looking at is cvs-1.9).

Scott Blachowicz  Ph: 206/283-8802x240   Mathsoft (Data Analysis Products Div)
                                         1700 Westlake Ave N #500
scott@statsci.com                        Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: CVS'r'us

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> Ah, right.  I've tried looking through the CVS documentation, but I
  Lars> couldn't find any mention of this.  Is it on the web somewhere,
  Lars> perhaps?

My CVS manual (version 1.9) contains a section "Remote repositories".
It mentions password authentication, too.

Here's what I perceive as the most relevant paragraph:

,-----
|    When authenticating a password, the server first checks for the user 
| in the CVS `passwd' file.  If it finds the user, it compares against    
| that password.  If it does not find the user, or if the CVS `passwd'    
| file does not exist, then the server tries to match the password using  
| the system's user-lookup routine.  When using the CVS `passwd' file,    
| the server runs under as the username specified in the the third        
| argument in the entry, or as the first argument if there is no third    
| argument (in this way CVS allows imaginary usernames provided the CVS   
| `passwd' file indicates corresponding valid system usernames).  In any  
| case, CVS will have no privileges which the (valid) user would not have.
`-----

kai
-- 
because I couldn't think of a good beginning.

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:

> My CVS manual (version 1.9) contains a section "Remote repositories".
> It mentions password authentication, too.

I've now fetched the full cvs distribution, and have the info file.
It says:

----------
The separate CVS password file (*note Password authentication
server::.) allows people to use a different password for repository
access than for login access.  On the other hand, once a user has
access to the repository, she can execute programs on the server system
through a variety of means.  Thus, repository access implies fairly
broad system access as well.  It might be possible to modify CVS to
prevent that, but no one has done so as of this writing.  Furthermore,
there may be other ways in which having access to CVS allows people to
gain more general access to the system; noone has done a careful audit.
----------

This sounds like something that one doesn't want to have on a systems
that's supposed to be secure, doesn't it?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: CVS'r'us

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> This sounds like something that one doesn't want to have on a
  Lars> systems that's supposed to be secure, doesn't it?

*Blush*  Yep...

kai
-- 
because I couldn't think of a good beginning.

Re: CVS'r'us

[Brian Edmonds]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Thanks to Steven's RCS repository of Gnusae past (along with my
> archive of old (ding) patches and releases) I've now constructed a CVS
> repository of all Gnus 5 releases -- ever.

Sorry for the timewarp, I'm rather behind reading my ding mail.  This
post makes me ask though: when do we get the nncvs backend?

Brian.

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

edmonds@cs.ubc.ca (Brian Edmonds) writes:

> Sorry for the timewarp, I'm rather behind reading my ding mail.  This
> post makes me ask though: when do we get the nncvs backend?

A backend that stores news articles an a CVS repository?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS'r'us

[Steven L Baur]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> edmonds@cs.ubc.ca (Brian Edmonds) writes:
>> Sorry for the timewarp, I'm rather behind reading my ding mail.  This
>> post makes me ask though: when do we get the nncvs backend?

> A backend that stores news articles an a CVS repository?  :-)

Maybe you guys are joking, but I can think of two useful applications
for this.

1.  FAQs.  There are times you want to see the whole document,
    other times you only want to see what has changed.

2.  Templates for other repeated postings.  I'd like to store
    templates for software release announcements.  I need several
    varieties of this too.  Other templates could be form letters
    for patch acknowledgement, spam complaints, etc.

In short, if you put this feature in I have an immediate use of it.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> Maybe you guys are joking, but I can think of two useful applications
> for this.
> 
> 1.  FAQs.  There are times you want to see the whole document,
>     other times you only want to see what has changed.
> 
> 2.  Templates for other repeated postings.  I'd like to store
>     templates for software release announcements.  I need several
>     varieties of this too.  Other templates could be form letters
>     for patch acknowledgement, spam complaints, etc.

Hm...  Each nncvs group would store various versions of the same
article?

I'm having a hard time vizualising how this is supposed to work.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS'r'us

[Brian Edmonds]

Steven L Baur <steve@miranova.com> writes:
> Maybe you guys are joking, but I can think of two useful applications
> for this.

It was only partly a joke.  Version control is very handy, and since
we've been mapping most everying else in this group onto a newslike
paradigm via backends, it seemed a natural idea.

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> I'm having a hard time vizualising how this is supposed to work.  

One approach that comes to mind is that you could open a VC file as a
group, and each article would be one version, threaded to show version
branches.  The "Date:" header would be the checkin date, perhaps with
the log data in a "Comment:" header.

I use RCS myself, so I'm thinking of this in more of a single file
paradigm.  Someone who uses CVS may be able to extend it to deal with
multifile projects.  Perhaps a thread for each file...

Brian.

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

edmonds@cs.ubc.ca (Brian Edmonds) writes:

> One approach that comes to mind is that you could open a VC file as a
> group, and each article would be one version, threaded to show version
> branches.  The "Date:" header would be the checkin date, perhaps with
> the log data in a "Comment:" header.

Yes, that has a very high neatness factor.  `B i' could be used to
import new versions of the file.  Well, `nncvs-request-accept-article'
would simply check the new version in, actually, so it would work as a
normal mail backend, seen from the point of view of the user.  In
fact, once the new mail splitting is in effect (which will allow
people to split to several backends), one could simply split off, say,
FAQs and other such stuff one gets in the mail to the appropriate
nncvs group and things would happen automagically.

Yes.  I think this has to be done.  I've now added it to the todo
list. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS'r'us

[Tony Bennett]

Lars> Yes, that has a very high neatness factor.  `B i' could be used to
Lars> import new versions of the file.  Well, `nncvs-request-accept-article'
Lars> would simply check the new version in, actually, so it would work as a
Lars> normal mail backend, seen from the point of view of the user.

would this have to be cvs specific?  I'd hope it could live on top of
'vc' pkg and thus work with CVS, RCS, SCCS, clearcase, etc.

--tony

Re: CVS'r'us

[Lars Magne Ingebrigtsen]

Tony Bennett <tbennett@chapelhill.hp.com> writes:

> would this have to be cvs specific?  I'd hope it could live on top of
> 'vc' pkg and thus work with CVS, RCS, SCCS, clearcase, etc.

I don't know, really.  If vc provides all the functionality necessary,
then I'll use it, but if not, it'll probably be CVS/RCS specific.  I
guess I'll know when I start writing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS'r'us

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> Hm...  Each nncvs group would store various versions of the same
  Lars> article?

  Lars> I'm having a hard time vizualising how this is supposed to work.  

Well, it could work like the nneething (or is it nndir?) backend: list
the (version-controlled) files in a directory.  Each file is
considered a group (similar to digests), and when you enter the group,
you get a list of versions, threaded to indicate the branch structure.

I'm not sure if I have a use for it.  Particularly with remote CVS
servers it could be quite slow, having to parse the "cvs log" output.
But then, I *am* using CVS, so you never know...

kai
-- 
A large number of young women don't trust men with beards.
(BFBS Radio)