[Savannah-hackers] Re: bug in Anon CVS how to

[Mathieu Roy]

>" Both of the machines i tested this on are running:
> 
>      $ cvs --version
> 
>     Concurrent Versions System (CVS) 1.11.2 (client/server)
> 
>    ... If it's abnormal that this file .cvspass is created
>    automatically, ...
> 
> I do not know whether it is installed abnormally or not; but both
> machines are running Debian testing, which is a major GNU
> distribution.

No problem with 

  address@hidden:~$ cat /etc/debian_version 
  3.0
  address@hidden:~$ cvs --version

  Concurrent Versions System (CVS) 1.11.1p1 (client/server)

  Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn,  
                          Jeff Polk, and other authors

  CVS may be copied only under the terms of the GNU General Public License,
  a copy of which can be found with the CVS distribution kit.

  Specify the --help option for further information about CVS

and

  address@hidden moa]$ cat /etc/redhat-release 
  Red Hat Linux release 7.3 (Valhalla)
  address@hidden moa]$ cvs --version
  
  Concurrent Versions System (CVS) 1.11.1p1 (client/server)
  
  Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, 
                        Jeff Polk, and other authors

  CVS may be copied only under the terms of the GNU General Public License,
  a copy of which can be found with the CVS distribution kit.

  Specify the --help option for further information about CVS
 


It's the two major GNU/Linux distributions, I think. Maybe there is a
bug in cvs 1.11.2.


> Right -- that is why you write and arrange the documentation so it
> helps the reader, rather than arrange it so that the person must read
> it all.  That is why, for example, it did not occur to me to read
> through the FAQ.  My assumption was that only the questions that
> appeared relevant to me would contain information that is relevant to
> me.  As you pointed out, I was wrong.  But your point is right:  a FAQ
> or other help document should be designed so that you do not have to
> read 1459 lines just to find the one line that is relevant.  ,

Yes. If pointers lacks, we can add them.

> I know all that.  The point is, Savannah comes across to me as a
> somewhat flakey site.  I am not sure whether it really is; but that is
> how it appears to me. (I usually contact it once a day for a CVS
> update on another project.)  
> 
> The site administration situation is similar to the one involving
> mailing list creation.  Savannah tells me that the automatic tools for
> a mailing list require several hours.  So long as I know that, all is
> well.  I wait until what I presume is a cron job gets done.  But if
> Savannah were not to tell me to wait several hours, I would check as
> soon as I received an `Update Successful' message.  And if things
> failed then, I would presume that the `Update Successful' message was
> wrong and that Savannah is broken.

Yes, we have problems to tracks problem. This things must be
implemented (remember that Savannah was a SF fork). It requires
time. But it's planned.

> Understanding that document requires that that a reader be more
> interested in CVS than many have time for.  I have looked at it; that
> was among the first things I did when I first began using CVS
> regularly.  It did not help me then so I stopped using it except for
> the occasional look up.  
> 
> Yes, it should be pointed to by a cross reference.  No, you should
> not expect a Project Administrator to have the time or interest to
> read it.  

I never mean that. But if someone want to use CVS with Emacs or any
other interface, he will have to take the time to read Emacs
documentation (or any other interface one) to understand how to do. If
he does not want to do that, he have to use the basic CVS commands.
> 
>    Content is generated dynamically. So it's not texinfo
>    files. 
> 
> The source for all the documentation should be in Texinfo format.  It
> is a bug if it is not.  With Texinfo format, not only is it easy for
> site administrators (or their tools) to create HTML, but it is easy
> for them to print out the info so they can review it in a different
> format than usual (which enables them to see problems that they might
> otherwise miss).  Moreover, Texinfo enables busy Project
> Administrators and others to print out docs to read off line.  Texinfo
> enables efficient people to read the docs in Info, which is much
> better than HTML for navigation, and be disconnected from the Net.

The two documentations (User FAQ and Admin doc)are available as
texinfo. 
Help including directly in the page are tips, not really
documentation. I wonder how texinfo can be included in many differents
files as easily as we can do with text file. But why not doing it, if
it's really possible, if it really simplify content management and if
someone have time to do it now.



-- 
Mathieu Roy
 
 << Profile  << http://savannah.gnu.org/users/yeupou <<
 >> Homepage >> http://yeupou.coleumes.org           >>
 << GPG Key  << http://gpg.coleumes.org              <<