> From: discuss-boun...@lopsa.org [mailto:discuss-boun...@lopsa.org] On > Behalf Of John BORIS > > I am looking for a Version control system that will fit correctly in my > environment. I manage a few applications, web sites and a servers. I am > looking for a version control system that is: > > 1. Open Source (Free Software) > 2. Server based > 3. Windows client > 4. Easy Reporting
I've seen a bunch of people writing sort of generalizations, like "use git, or mercurial, or svn" I think the best place to start is an understanding of what makes one better than another. The biggest fundamental difference here, is that git and mercurial are decentralized. Svn and perforce are centralized. This means ... Decentralized version control means each user has their own working copy. There is no central server. When Joe and Mary will merge their two trees together, and it has no effect on anyone else. Then finally, one day, Linus announces to everybody, "Everybody merge with me." When people try to merge with him, if there is any conflict, it lands on that person to figure out what to do with it. Fundamentally, decentralization can be a good thing, as long as the source files are highly mergeable, such as C files, or other text files. Fundamentally, decentralization hurts very badly, if you are working on unmergeable files, such as jpg, zip, and so on. A centralized server would be a better choice if you are working on unmergeable files. Also, a centralized server can have an administrator performing backups on it ... and while I know it's easy to get a centralized server available via a hole in the firewall... I don't know how that's done decentralized. > I then tried Subversion. Great package but it > wasn't > easy for us to use. Maybe I am too dense but my programmers did not > like > it. I'm nearly an svn expert. I don't want to bias you toward it necessarily, since it sounds like you work on highly mergeable files, you may actually benefit from decentralization, but since you have a small group, you might find svn easier to manage. But I do want to say a few things specifically about svn: In the easiest setup, you use svnserve. It's not very secure, but it's really fast, and easy to setup. In the medium setup, you run it over http, via apache. This is equally secure, but tougher to setup. And the most complex configuration is to run it in apache with https. If you've never done this before, it would be better to take it one step at a time (start with svnserve) but if you want to make it available over the Internet, it's very wise to use https. This also makes it easy to interface with your IT group. No VPN necessary, just open up port 443 (or whatever you like). I cannot believe that you have software developers who don't understand svn. I can understand, there's a lot of complexity, and nobody needs to become an expert. But to do "checkout, update, commit, add, rm, ls, and status" if you can't get that ... sorry, that's pathetic. No matter how good your developers are, even I myself sometimes refer to this resource: This is very good. Simple, clear, basic svn understanding: http://betterexplained.com/articles/a-visual-guide-to-version-control/ The official book, usually more than you wanted to know: http://svnbook.red-bean.com/ _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
