Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
P is for Practical
 
PerlMonks  

Re: [OT] Advanced CVS usage

by hacker (Priest)
on May 29, 2003 at 18:28 UTC ( #261633=note: print w/ replies, xml ) Need Help??


in reply to Re: [OT] Advanced CVS usage
in thread [OT] Advanced CVS usage

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.


Comment on Re: [OT] Advanced CVS usage
Re: Re: [OT] Advanced CVS usage
by chromatic (Archbishop) on May 29, 2003 at 20:40 UTC

    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.

        cvs2svn works fine, but it doesn't handle branches or tags. Since you said in your original post that you guys hadn't ever used branches, it seemed like you were prime candidates for switching to Subversion ASAP, before you started using CVS branches.

      Have you looked at OpenCM. I havn't used it. but I've heard good things.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (15)
As of 2014-04-24 12:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (565 votes), past polls