Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On Behalf > Of Jerry Feldman > > Our office has been adding some new developers, and I've been asked to > set up GIT. Fortunately our company supports GIT, but the R&D main > source control system is CVS. I'm looking for some rational discussion > from developers who have used both GIT and either CVS or SVN. Linus has > standardized on GIT for kernel development. There is no reason to use CVS anymore. SVN was designed to be a CVS killer, and they succeeded in doing so. The fundamental difference between CVS and SVN is that CVS stores versions of files, while SVN stores versions of a directory tree full of files. As a result, SVN has enormously higher usefulness and features etc that CVS couldn't even dream of achieving. The fundamental difference between Git, Mercurial, and Subversion is the concept of centralized vs decentralized. There are pros and cons of each. If you have a decentralized versioning system (git or hg), it fundamentally operates on the assumption of mergeability. Decentralized versioning is NOT appropriate if you have a significant number of unmergeable files in your source tree. Decentralized versioning is especially useful for projects which have huge numbers of highly disperse people working on it. This is why it's great for the linux kernel. You've got a team of developers working on some module... So they're able to rapidly prototype and merge amongst each other, until they reach a consensus, and then merge their changes upstream. Eventually, decentralized versioning must become centralized. At some point, Linus asks everyone "Hey you guys, I want to release 1.7.x, so merge your changes with me now, or forever hold your peace." This is a manual process (sort of) so it can become a disadvantage for decentralized versioning... If you have regular release cycles, and you don't have hundreds of disperse people working on a project, then centralized versioning is probably a better fit for you. With a centralized versioning system (subversion) there exists a server, and the server is the "authoritative" copy. All the developers downloads a local working copy, and choose to manually sync up & down whatever changes are made. If you want it, this gives you the ability to implement file locking (which cannot be done with decentralized versioning) and this serializes all changes to the directory tree. Both of these characteristics are vitally important for managing unmergeable files. With a centralized system, there is a clear single point of control, for administrators to implement backups and security. So ... pros and cons of each system. You've got to choose whichever one is better for your purposes. Incidentally, commercial versioning systems exist too. Generally speaking the advantages of the commercial systems are higher performance, or tighter integration with specific engineering tools. For example, if you have a large directory full of thousands of files... Whether you use git, hg, or svn, you will have many operations which must "walk the tree" inspecting all the files for changes and scanning for updates etc. This can be a big time waster, depending on your development team's behavior preferences. Commercial solutions such as clearcase and perforce are able to eliminate those, by forcing file locking and centralized management of all updates & changes. And stuff like that. In my environment, this means the difference between ... Every engineer wastes 5 minutes every time they check for updates or do a commit in subversion ... versus ... the same operation is completed instantly every time in perforce.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |