info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS version 1.11.17 vs. 1.11.22


From: Mark D. Baushke
Subject: Re: CVS version 1.11.17 vs. 1.11.22
Date: Wed, 27 Sep 2006 02:27:36 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jacky <address@hidden> writes:

> Sorry to intrude the thread,
> 
> Has anyone come across tutorials on how to upgrade my cvs server? I am
> using 1.11.17 as well, I need to upgrade to 1.11.22 so that I can use
> acls.

The CVS version you have now would work with the cvs_acls.pl script that
you can get by browsing the sources on savannah.nongnu.org
http://cvs.savannah.nongnu.org/viewcvs/ccvs/contrib/?root=cvs with
documentation in the cvs_acls.html file.

The CVSNT folks have a more native implementation of acls if that is
what you think you want. You should visit http://www.cvsnt.org/ for more
details on that fork of the CVS sources.

To upgrade from cvs 1.11.17 to cvs 1.11.22, do the following:

  1) download, configure, build, make check, make install

  2) You may find it desirable to do a 'cvs init' command on your
     repository to create any new default templates and triggers that
     are not present in your current CVSROOT, otherwise there is nothing
     else you need to do.

If you are considering the cvsacl.sourceforge.net project, that is
outside of the scope of this mailinglist/newsgroup. 

Fwiw: I have never used those set of patches and I have no idea if they
work or what changes you might need to make to your CVS repository to
get them to work. My understanding is that those patches are only useful
if your conneciton method is :pserver: ... you may wish to search out
the various postings on :pserver:, but I personally believe it is a
really bad idea to ever run a :pserver: for any purpose other than as an
anonymous reader to a mirror of your main repository. Using it to
control write access to your repository is a really bad idea in our
current hostile network environment called the Internet. Using it inside
of a given organization and/or company is foolish as you may as well
provision a separate account for each member in any case and doing it to
allow the operating system to authenticate and authorize actions on the
repository is a safer thing to do than to hack a mostly anonymous system
mechanism to do things it was never really intended to do.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFGkQICg7APGsDnFERAq2/AKCBw3UxbRbpRozMBwJPeK/tmy9nzwCffeig
CgMUDEsQK8Te8TN00llL0P8=
=CzhX
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]