Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: [OT] Advanced CVS usage

by autarch (Hermit)
on May 29, 2003 at 17:37 UTC ( [id://261623]=note: print w/replies, xml ) Need Help??


in reply to [OT] Advanced CVS usage

Advanced CVS = Subversion

Subversion is coming along very nicely, and I've been using it for some small 1-2 person projects for a while with no trouble at all. I'd strongly suggest taking a look at it before investing too much time in CVS.

Replies are listed 'Best First'.
Re: [OT] Advanced CVS usage
by hacker (Priest) on May 29, 2003 at 18:28 UTC
    There are several problems with Subversion in its current state, which prohibit people using CVS from migrating over to it (yes, my asbestos flamesuit coveralls are zipped up tightly):
    1. There is no import/upgrade path from existing CVS repositories to Subversion repositories. Until svn can completely import an existing cvs repository, with full branches, revisions, and historical data intact, it will not be an easy migration.
    2. There is currently no way to run Subversion without DAV or a webserver. I'm speaking from experience here, because I run a fairly high-volume public CVS repository system called SourceFubar, and the repositories themselves do not live on a server with a webserver. It just doesn't make sense to do so. Subversion (in its current incarnation) requires a webserver to operate.

    There are really only a couple of things stopping CVS from being better; atomicity at the directory level, and finer-grained control over access methods. Now with CVS having ACLs and no need to have local user accounts to have protected access to repositories, that is not such an issue. You can also have anonymous ssh access to repositories if you wish.

    There's two schools of thought about the ssh vs. pserver security "problem".

    1. Using pserver presents a security issue, because your password to log into the repository to commit data, check out data, etc. is passed in the clear, over the pserver protocol. Some see this as a major security problem. It isn't. If you have proper ACLs set up on the repository itself, where the users committing data do not have any local accounts on the box, all any attacker can do with that password is either commit more data, or delete existing data, and since it's all in cvs, you can just roll back if it happens (and connections are logged anyway, so you'll know who and where the attack came from).
    2. Using ssh is more secure, and your password can never be gleaned during a man-in-the-middle attack. Although this is true, it puts your cvs server itself at risk of further attack. Not only can you never verify the security of a client machine (what if someone else (an attacking client) decides to ssh into your cvs server with a "valid" account from the "valid" box?), but you have to give the user a local account on the server itself, which means there is much more access to the server than there needs to be. All to save from having a password sniffed?

    There are good points and bad points to either approach, but in the long run, using pserver is much safer for the code and for the server and the user's account itself. Not only is that password not the same as any other password that the user has, but since they don't have a local account on the box, getting that password gets the attacker absolutely nothing of value.

    The atomicity can be an issue, if you don't know what you're doing. I've done major CVS surgery on directories, file renames, moving entire trees of directories under other subdirectories, and so on.. without losing a single byte of the historical data. It's possible, but it takes a bit of planning to get right.

    That being said, Subversion looks good, but until someone can cleanly, seamlessly, and securely use it on a box that does not require a local account or a webserver, with the ability to import an existing CVS repository into it (full historical data intact), it will not catch on as fast as people hope.

    CVS is well-seated, and lots of very high-volume projects use it, and continue to use it every day, including myself. I've wrapped a lot of tools around my public repositories to help developers manage their code better (4 different web-based code view/diff/graphing tools, cvs statistics pages, and other tools that enhance the usability of the repositories themselves), and these things just don't exist for Subversion. I'm sure that in a few years time, they will, but right now, it would be traumatic to migrate existing codebases over to Subversion.

    YMMV though. For a completely new project where security isn't an issue, Subversion may be a perfect fit.

      I've been running svn on my laptop without going through Apache or mod_dav for at least eight months. See Single-User Subversion and the followup Multiuser Subversion.

      I'm pretty sure the cvs2svn.py program in the distribution is stable, though I haven't tried it.

        Thanks for the links to the articles! I'm glad to hear you can run subversion w/o Apache, but since we'll be using version control to control the production servers (located in a colo facility) network access is necessary.

        And according to the Subversion book, the cvs2svn utility does works. FYI, it took about 30 minutes to import the Subversion code from the original CVS repository.

        Have you looked at OpenCM. I havn't used it. but I've heard good things.
Re: Re: [OT] Advanced CVS usage
by drewbie (Chaplain) on May 29, 2003 at 19:35 UTC

    I did look at Subversion as part of this project, and I've heard lots of good things about it. It certainly has some features I'd love to have (atomic commits & easy renaming come to mind). But it seems more complex to install than CVS, and we already have a working CVS installation & are familiar with it. I also am not crazy about the fact that it requires a webserver (Apache 2 at that IIRC). We are using mod_perl w/ Apache 1.3 and I'm not very interested in adding a 3rd server into the mix.

    Subversion is definitely something I'll keep my eye on for the future. But I don't think it's the answer for right now, at least at work.

      Subversion has its own server now that can run over an ssh connection. It's just called svnserve.

        Now that you mentioned it, I do remember reading in an FAQ about the SSH option... Hmmm, subversion is looking better & better. I printed off Chapters 1-6 of the Subversion book yesterday & will look over it this weekend.

        Any gotchas I should be on the lookout for if we switch to subversion?

        ..which again suffers from a larger security hole than a properly-scoped ACL that does not require local user accounts.

        As far as I know, without a SERIOUSLY locked down chroot (i.e. no logins allowed whatsoever), you can't let non-local users use ssh. You need to create a local account for them on the physical box (or LDAP, or whatever you use). This opens a potential hole in your security, pending someone exploiting the client machine or network (which, as you know, you can never trust or validate).

        If someone has a trusted account on your box(es), they can always try "Exploit-of-the-week" to try to gain root or consume unnecessary resources of the machine proper. These can be controlled with limits(5) and chroot(8), but those too, require considerations of their own.

        With a system using ACLs, and no local user accounts, you can be sure that even if the user's machine, network, or password were somehow sniffed or exploited in some way as to compromise their access to their repository, it does not compromise your server running those repositories.

        Requiring a local account, ssh, cvs, login, or otherwise, is always going to be less secure than a system that works without the use of that constraint. See comp.security.misc and comp.security.ssh for more information on these issues.

        Subversion is definately a contender for personal repositories, and public repositories where absolute security is not an issue, but those should be determined by the administrator who needs to install, maintain, and manage those repositories.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://261623]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2024-03-28 08:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found