Hi Ross, Egon, and all others,
Ross and Egon wrote:
>
> >Hi Jens,
> >I wonna be a anonymous CVS user. Is there any password for an anonymous
> >user?
>
>
> > ... I think its still a bad idea to let download normal users the huge
> >tar.gz file instead of diff's.
> >
>
> I cannot support that view, for the following reasons.
>
> 1. Users should *not* be encouraged to update from diffs.
> Because there are so many files, in different directories,
> it is too easy to not update *all* the required files to
> ensure that the whole system works as intended.
>
> The only way to ensure complete compatibility is to install
> a complete update.
>
>
> 2. The developers' repository is just that: a developers' repository.
> ^^^^^^^^^^
> The latest CVS revisions of individual files are *not* guaranteed
> to be bug-free. They are not even guaranteed to *work*.
>
> It is only the named archives that carry any semblence of a guarantee.
> Even these can have errors, but they should at least work.
> (Except that l2h-devel.tar.gz cannot carry any guarantees.)
>
>
> 3. Access to the latest versions of individual files should only
> be *easily* available to those who have a definite interest in
> working on them, to provide improved functionality.
>
> The repository is *open* in the sense that anyone can find
> any file, if they know where to look. But if you get a file this way,
> don't expect any support or sympathy if you find it doesn't work
> within a non-standard installation.
>
>
> 4. The archives have only just recently hit 1Mb in size (compressed).
> Surely this isn't too much to expect to download,
> for a complete version update ?
>
> Nowadays it's probably quicker to do this, and do a complete
> installation, than to work out which pieces are required to
> perform an incremental update.
[...]
Generally I agree with Ross' view, and that downloading 1MB is likely to
be faster not only because of its small size but also because CVS sets
transaction locks for each incoming 'update' request that slow down the
transfer times not only for the user but also for every other developer
who currently works with CVS. This could in bad circumstances prevent a
developer from checking in new sources in time.
This aside, the only possible solution suited for non-developers would be
to allow CVS updates but disable commit access.
You agree that we cannot grant write access for non-developers.
To achieve that I have to set up CVSROOT/commitinfo in that it denies
commits for any non-developer. With CVS 1.10 I found this problem impossible
to solve, because CVS does not provide information about the CVS login name
during the time it parses commitinfo. This seems to be a bug.
However, I'm not completely against the idea of non-developers with read
only access, provided we get a fix for that bug.
I am interested in more comments on this topic.
Currently the developers' release still contains CVS directories that point
to the CVS Repository in Bayreuth, and *everyone* who is keen enough to
CVS login is able to update whatever he wants.
It's my fault that I chose the silliest password in universe but I could
change this immediately.
So what do you prefer?
Kind regards,
Jens.
--
# Jens Lippmann [EMAIL PROTECTED]
# http://www.informatik.tu-darmstadt.de/TI
#
# Technische Universitaet Darmstadt http://www.tu-darmstadt.de
