[cvsnt] Switching from CVS to CVSNT
arthur.barrett at march-hare.com
Wed Feb 18 23:22:23 GMT 2009
> 1-Is it possible to switch from CVS 1.10.x to CVSNT w/o
> compromising the repository structure or format?
I've no idea what you mean by 'compromising'. CVSNT will automatically
detect that the repository is an old CVS one and upgrade it for you as
you change/commit files. If you want to force CVSNT to upgrade your
whole repository then checkout the whole repository and do a 'force
commit' - however that is not usually required.
Once your repository is used with CVSNT there is no going back to CVS.
You should be aware that CVSNT is much more secure than CVS and in
* the 'repository path' used in the $CVSROOT does not need to be the
same as the physical path (configure in /etc/cvsnt/PServer)
* the permissions/mode of checked out files does not need to match the
permissions/mode of the RCS files in the repostiory
* CVSNT has it's own ACL's
* CVSNT can run in a chroot jail
> 2-Does anything special need to be done to the repository or
> are both flavors of CVS able to read the repository
> universally w/o any additional formatting or tweaking?
The simple answer is: CVS cannot read a CVSNT repostiory. There are
much more complicated answers available in the newsgroup archive.
> 3-Once we switch, is there any way of going back to CVS or
> switch to Subversion w/o tweaking the repository or does
> CVSNT has some proprietary format and won't allow you to switch back?
You can instead switch to CM Server (EVS/CVSNT 3.1) which is a single
server that allows both CVS and Subversion clients. A migration utility
Unless there is a measurable benefit to the organisation moving to a
different SCCM tool then it is going to cost you money (ie: a negative
cost/benefit). Moving from CVS to CVSNT has a low cost (since the
upgrade is seamless and the CVSNT workflow a superset of the CVS
workflow) however it still has costs (time, training etc) but many
people find the benefits outweight those costs (eg: failsafe audit, user
defined change sets, commit id's (what SVN calls 'atomic commit'),
rename, merge tracking, auto merge point, access control, reliable
process interlocking (lock server), support for reserved and unreserved
methodologies, track and merge change not just files, etc).
If some other SCCM tool provides enough benefit then the costs to
migrate your existing data is largely irrelevant.
> 4-The reason we're switching is because CVS via Pserver
> method doesn't allow users to change their password w/o
> logging into the server and the CVS user group running as
> root in the background has access to all sort of things.
> We're considering CVSNT because of its active directory
Since your server will be on linux but you want AD integration you need
to think carefully about what protocol to use and what configuration
that requires on the server side. Our recommendations are here (got to
the bottom of the page):
Our recommendation is that from windows clients to red hat server you
use the :ssh: protocol, however that will require you AD integrate your
ssh authentication on red hat - this is NOT a topic for this forum, it
is a red hat/ssh/winbind/pam discussion. Alternatively you can use
gserver which is also very secure - but again you firstly need to get
kinit working on your redhat server and that is also not a discussion
for this forum (it's a kerberos/redhat discussion). Other protocol
options include sspi (ntlm only on linux) and pserver (with PAM).
Setting all this up is 'easy' for someone who knows what they are doing
and is not CVSNT specific (but yes CVSNT has particular 'hooks' to take
advantage of it once it is set up).
You probably know all this already, but if you get stuck then I strongly
recommend purchasing pro support (preferably from us since we are the
authors), but even our pro support is limited to fixing problems with
CVSNT, but 'general' authentication problems with the OS (though we do
work closely with customers to help them identify those problems when we
More information about the cvsnt