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 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". 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. | [reply] |
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. | [reply] [d/l] [select] |
by drewbie (Chaplain) on May 29, 2003 at 21:56 UTC | |
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. | [reply] |
by autarch (Hermit) on May 30, 2003 at 04:07 UTC | |
by Anonymous Monk on May 30, 2003 at 00:37 UTC | |
| [reply] |
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. | [reply] |
by autarch (Hermit) on May 30, 2003 at 04:08 UTC | |
| [reply] |
by drewbie (Chaplain) on May 30, 2003 at 13:54 UTC | |
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? | [reply] |
by hacker (Priest) on Jun 02, 2003 at 00:36 UTC | |
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. | [reply] |