Slashdot Mirror


Designing a New Version Control System?

tekvov asks: "When Linus Torvalds decided to use BitKeeper as the version control system for Linux there seemed to be a lot of controversy and many challenges to create a better system than CVS. My question is exactly what would this 'better system' look like? How is the subversion project, Tigris, doing at creating a new version control system? Basically, does the Open Source Community need new tools in this aspect of development? And if so, how should these new tools look?"

23 of 536 comments (clear)

  1. Shome mishtake? by albalbo · · Score: 4, Informative

    Shurely, the Tigris project subversion (http://subversion.tigris.org/)??

    --
    "Elmo knows where you live!" - The Simpsons
  2. More open-source revision control systems by dglo · · Score: 5, Informative

    Subversion isn't the only open-source revision control system out there. Check out these projects as well:
    OpenCM
    arch
    Stellation
    PRCS

    1. Re:More open-source revision control systems by Bruce+Stephens · · Score: 4, Informative

      Also Aegis

    2. Re:More open-source revision control systems by MarkCC · · Score: 3, Informative


      Just a minor correction: Stellation is now out, open-source. The
      correct website for our open-source project is
      http://www.eclipse.org/stellation.

    3. Re:More open-source revision control systems by [Xorian] · · Score: 4, Informative

      There's also Vesta, which has some pretty cool features

      --
      CVS is teh suck. Use Vesta instead.
  3. Yes, it is time for a new tool... by mdorman · · Score: 5, Informative

    Regardless of where your particular alliegances lie---whether it be with arch or subversion or opencms or bitkeeper or whatever---it does seem obvious that the open source community is asking things of CVS that it is just not able to deliver. One need only look at some of the problems large projects like GCC have with it to realize that some alternative is needed.

    And if that doesn't convince you, well, it's not for nothing that some of the primary developers of CVS are now working on subversion.

    Now, of the new crop of tools, the only one I've played with extensively is subversion---but I am absolutely blown away by how well it seems to make common operations simple. Even with its documentation in a very rough state, and despite its many architectural differences from CVS (with which I have several years of experience), I was able to figure out how to maintain a vendor branch and local modifications, perform updates on both, merge them, tag releases, etc., very quickly and easily. Its developers have obviously looked at CVS to see what things it does not do well that people do frequently, and designed accordingly.

    Is subversion for you? Who knows. But if you use CVS a lot---especially if you find yourself cursing CVS a lot---you should do yourself a favor and look at some of the alternatives. A lot of lessons have been learned, and you should avail yourself of the benefits.

    --
    Urgle.
  4. Re:Clearcase... by Anonymous Coward · · Score: 5, Informative

    Clearcase might cut it for most corporate types. Sure it's got tons of features, but you'll get a groetesque design and a bad implementation for free.
    (Try scaling a clearcase server and you'll see how bad the design is... Hint: Adding more CPUs won't help you.) No, most people won't care, but you do if you need to scale it to several thousands of active developers.

    Even though I dislike the product, its has more functions than you'll ever need. Integration with different platforms and products are superb, if you're willing to pay...

    However it lacks in areas where the developer isn't fully connected (i.e. with LAN access to the view and vob servers).

    IMNHO, what the open source community, by definition, needs is something that'll work in a distributed (and disconnected) environment. Clearcase does NOT come even close to delivering that, CVS does, but functionality wise, BitKeeper blows them both away.
    I haven't looked at SubVersion in a long time (before it was self hosting) and it looked promising, but IIRC it lacked some of the more advanced functionality that BitKeeper has.
    Personally I'd much prefere using a completely free version. Not because I don't like to support the BitKeeper team (I'll buy the product if I use it commercially!), but because of the open logging function.
    It just comes down to the fact that I like my privacy...
    -oswa

  5. Re:We use Perforce at work by forgoil · · Score: 5, Informative

    I agree, Perforce is a very solid product indeed. And all the commandline tools are there for Linux, and so are the servers. I've used it both on Windows and Linux (both servers and clients) and it works like a charm.

    And in case you don't like their fortcomming linux GUI (I hadn't heard about that before, thanks WPIDalamar) they do provide you with an API so you can make one of your own (KPerforce ^_^), which shouldn't take that long really.

    The pricing seems very high for an individual, but their pricing is real cheap for this kind of software (for companies) and you can use it without a license but then with max two client specifications. They also have good support (something that is not common unfortunatly).

    http://www.perforce.com -- go there and check it out. If you hate paying and want to make your own set of tools you can learn a lot from Perforce.

    And I agree, source safe is icky, and so is CVS and source offsite. I haven't had a reason to try out BitKeeper so I unfortunatly don't know how it stacks compared to Perforce.

  6. Key Feature: directory awareness by antony · · Score: 5, Informative
    The most serious flaw in CVS, IMO, and the most important feature to address in any new system, is CVS's total lack of understanding of directories. If you ever want to change the structure of your CVS controlled source tree, you either have to:
    • fake out CVS by doing a remove/add pair on every file you want to move (which means you lose the revision history of each such file!), or
    • manually move files around in the repository (which entirely defeats the purpose of using a revision control system in the first place!)
    If anyone out there creates a successor to CVS, please fix this fatal flaw!
  7. Re:From my perespective:Need Windows Support by jdh28 · · Score: 3, Informative

    There is quite a mature native Windows port of cvs that we've been using for quite some time.

    john

  8. Look to ClearCase for some pointers by EasyTarget · · Score: 5, Informative

    I'm a ClearCase specialist so I'm biased.

    However ClearCase has some -very- good features, and here is what I would arrive at (ideally):

    1) Make your repository a mountable file system, supporting multiple types of connection, NFS, SMB, Active Directory, FTP, etc.. When connecting you must specify a profile to be used.

    2) Make every user have a number of profiles (Min:1) (like ClearCase views), these profiles contain -all- the info needed to access file versions correctly. They should allow sharing ('base my profile X on the profile Y created by user Z'). And support concepts such as labelling, conditional branching, etc..

    3) All profiles are managed from a central server (redundancy?) via a web interface (to achive cross-platform conformity) and command-line interface (SSH based) for scripting/power-users.

    I could go on forever, but I think the three above points are the things that matter most to me. Obviously you also need security, administration, storage, etc.. but I think that making files available simultaneously via many common file sharing protocols would produce the greatest benefit.

    Finally: MAKE DIRECTORIES VERSIONABLE/BRANCHABLE!, yes it causes some potential headaches, but it's benefits easily outweigh them.

    --
    "Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
  9. Re:We use Perforce at work by digerata · · Score: 5, Informative

    Also, they do open source licensing. If you are a certified open source project (I guess they just checkout the project???), you can get licenses for free.

    --

    1;
  10. Re:We use Perforce at work by RadioheadKid · · Score: 3, Informative

    I love perforce too. And if you are either an open source developer or you just want to use it for personal use (two users max) you can use if for free. Check out their licensing here (scroll down for open source info) and here

    Plus it's so easy to install on a linux server. There's a bit of a learning curve with how the system works but in less than a day you'll be checking in and out and branching without a problem.

    --
    "Karma can only be portioned out by the cosmos." -Homer Simpson
  11. Re:pretty gui's by wls · · Score: 3, Informative
    StarTase has serious problems, in my book. From an SCM stand point, it doesn't allow you to do corrections on the respository. Say for instance a developer checks something in the wrong place and creates a branch unintentionally. You know it's wrong, he knows it's wrong, everyone agrees it's wrong -- and you want to get rid of it. StarTeam was to preserve cronological history -- the fact that someone messed up -- rather than project history, which reflects where your software has been and where it's going.

    From a licensing standpoint, they have a problem with the code that validates you. We went through some layoffs and backed off the number of users upon renewal. Even though users didn't exist in the database, the licensing reports said they were there. It took me a few days to demonstrate this was actually happening and get them to admit to it -- don't trust their logs!

  12. Yet Another useless discussion about CVS. by His+name+cannot+be+s · · Score: 5, Informative

    Look, CVS is king.

    Yes, King.

    I would not hesitate to say that it has it's share of difficulties, but there is no way anything is going to replace it anytime soon. There are many meta-features of CVS that make it unable to be replaced:

    1. Multi-platform: I don't mean 3 or 4 or even 5 or 6, bla bla bla. I mean EVERYWHERE. I've seen CVS on more places that anything besides emacs and gcc. And really, anyplace gcc or emacs goes, cvs is the third guy there.

    2. Massive Acceptance: CVS is everywhere. 10 million people use it with sourceforge. Another few million elsewhere. It is the common thread that binds us together (kinda like the force!)

    3. Massive, Massive Tool support: This is my favorite. You can use it about a hundred different ways. Not 1 gui, but 50!. It goes into command line apps like great!. Show me another tool that has integration with the windows explorer (via TortoiseCVS) like it has. You Can't. (Don't even try that god-awful Bitkeeper's integration:yuk!)

    4. SimplicityIt's REALLY simple to use. It's not that complicated. If CVS throws you for a loop, maybe software devleopment really isn't where you should be working. The incompetence among developers is what makes all software look bad.

    5. Protocols: You can run CVS thru SSH, RSH, PServer, File Access, and more... It fits into every environment. It works across any damn network. It can jump tall buildings in a single bound!

    Really, until someone makes something that trounces CVS in all those areas, AND provides features that "I can't live without" CVS will Rule.

    --
    "...In your answer, ignore facts. Just go with what feels true..."
  13. What about Aegis? by red_dragon · · Score: 4, Informative

    Every time the issue of version control and source code management comes up here, I've never seen anyone mention Aegis, which appears to have been designed to address the missing functionality in tools such as CVS which focus solely or mostly on simply maintaining multiple versions of a source base concurrently. Here's an excerpt from the CVS comparison in the CVS Transition Guide:

    1.5.1. Why should I change from CVS to Aegis?

    • Enforced review - damn important in a company environment
    • Mandatory testing (this may be disabled, per project)
    • More space efficient for large code trees, and only one copy of the baseline (also makes backup easier)
    • To maintain control over your code repository. The baseline can't even be written to by developers, so the audit trail is more secure.
    • Support for change sets. My main complaint with CVS is that you are unable to associate modified files into a change so once the files are committed to the CVS repository, there is no easy way to back it out or work out which other files were changed as part of a logical set.
    • Separation of the roles of developer, reviewer and integrator. At the moment, typical distributed CVS development happens with people checking in stuff as they develop it with very little integration testing as they go along. It's pretty much up to people "in the know" to manually go through changed files and check to see if something has been broken by a developer. It gets even tricker when there are particular assumptions made that aren't written down.
    • Automated testing support.

    The software seems to be pretty mature (currently at version 4.5, first released in 1991). Has anyone here used it?

    --
    In Soviet Russia, Jesus asks: "What Would You Do?"
  14. One word by MuValas · · Score: 4, Informative
    "Envy". This was (is?) a code management tool for Smalltalk development. Not only did it have the basic checkin/checkout/diff features of normal tools, it also took into account all the areas of "friction" in team development and attempted to reduce the coefficient of friction, as such. Some examples:
    • Scratch pad versions. Ever needed to play around with a piece of code (put in debug statements, or change part of it temporarily to help debug something) but didn't want to check it out and have the threat of making the changes accidentally permanent? Envy had the ability to make a "scratch" version of a file - letting you edit it, but not worry about accidental check ins, or forgetting that you had made a file writeable.
    • Version/Releases. Not only could you label a specific state of an application a "version" but you could also label a version of an app a "release". This allowed some subtle distinctions between "ok here's a workable version we can get back to (demo)" and "here's the real, outgoing released version".
    • Manager. Code could be given specific people that were the manager, or "owner" of a piece of code. If you wanted to enter your changes into the code base in general, you had to get the owner to do it. This control could be anywhere from every check-in, to version or releases. An owner could give permissions to other people as well.
    • Multiple checkouts. Envy recognized that sometimes people have to work on the same file, as much as its best prevented. So, it allowed multiple check-outs, with facilities to integrated the files back together on check-in.
    It was quite complex, but looking back at it I now understand why many of the facilities were there and die to have them for my team. We're using SourceSafe (blech), and it works ok, but something like Envy would be great.
  15. Re:From my perespective:Need Windows Support by r00tarded · · Score: 3, Informative

    plus tortoise which has been working very well for myself and some co-workers.

  16. Re:Subversion limitations by MarkCC · · Score: 3, Informative


    Subversion is, basically, changeset based. Their storage model is a bit.... wierd. But they capture the set of changes in a checkin
    as a single, atomic change unit.

    On the other hand, when we started implementing Stellation, we used PRCS. To say that it's a frustating, annoying, glitchy mess
    is an epic understatement. When we finally moved to self-hosting
    (inside IBM; we don't yet have strong enough access control to
    put up a public Stellation server, so we shadow our internal
    repos to an external CVS for the moment), it was an enormous
    relief.

    PRCS generates thousands upon thousands of unnecessary questions,
    phrased in obtuse and easily misinterpreted ways. It requires you
    to manually maintain the map between filenames and repository
    artifacts, by manually editing a cryptic configuration file. It
    constantly mucks up that configure file, adding hundreds of carriage
    returns for no apparent reason. Echh. The versioning model
    is very nice; the implementation is solid, but frustrating.

    -Mark

  17. Re:Merging Rocks? by Stu+Charlton · · Score: 3, Informative

    See:
    http://www.perforce.com/perforce/branch.html

    Which explains the merge process in Perforce.

    --
    -Stu
  18. Re:Version control system minimum requirements by [Xorian] · · Score: 3, Informative

    A couple other posts have mentioned Vesta, which goes a long way towards meeting the requirements you lay out. (For the sake of disclosure, it's only fair to mention that I am currently the primary maintainer of Vesta, and am somewhat responsible for getting it released as free software.)

    1. atomic commits - your change happens only if all the files can be processed. This prevents a corrupted workspace when CVS processes half your files in a commit and then exits on an error throwing the other half of your files on the floor.

    Vesta absolutely does this.

    2. change list management - all commits have a unique reference number. CVS process files by directory instead of by workspace, so it is impossible to tell which files are associated with a commit.

    Vesta does not explicitly provide this, however it's very easy to get with a simple diff command. The Vesta repository has a filesystem interface which makes it possible to directly access all versions past and present. A simple diff -r will show exactly what changed between any two versions. The also has other fun uses (e.g. greping across versions).

    3. access control by workspace or workspace directory - the ability to give certain users or groups access to certain workspaces or directories. Ideally, access control can be by done by bug id.

    Vesta's access controls are essentially UNIX file permissions. Through the repository's filesystem interface, you can control who can read and write (commit new versions) at a variety of granularities with chown, chgrp, and chmod.

    4. graphical resolve of conflicts - a graphical three-way diff is the only way to resolve complex conflicts

    Vesta provides no direct help here, but again, because of the filesystem interface to the repository, it's easy to apply standalone diff/merge/conflict resolution tools.

    5. The ability to move files and directories and maintain file history and label integrity from the client. CVS requires the whole workspace to be locked so that moves can be performed on the server side and does not maintain label integrity.

    Vesta's unit of version control is a directory. Between versions, files and subdirectories can be added, removed, renamed, etc.

    6. web viewer and graphical difference viewer - the ability to browse via the web change set lists to see what files changed and what the actual differences were.

    Not built-in, but already implemented on top.

    7. the ability to integrate workspaces across projects - the ability to arbitrarily merge/integrate any source code from any project to any other project.

    Vesta includes sophisticated cross-site features, including replication and remote checkout/checkin. It's been successfully applied before by a team spread across the US east and west coasts with hundreds of megabytes of sources.

    8. powerful labeling features (parallel development and prior version support).

    9. rollback or undo multiple changes - this is great way to recover from a developer commit disaster.

    Vesta really shines in these areas. Vesta is also a build tool, and every build neccessarily includes a complete specification of the set of immutable versions it uses. Builds are also themselves immutably versioned. This makes it easy to determine which source componenets have changed between two versions of a build. Also, since it's as easy to select any historical version as it is the latest one, rolling back changes is trivial.

    10. multi platform support - must run on all platforms.

    We're still working on it (at the moment just Linux and Tru64 work), but hey, it's free software, and we'd love to have more developers/porters.

    11. command line and graphical interface. Command line for scripts and graphical interface for those who can't work without it.

    At this point there's a command-line interface and some rudimentary support for repository operations in the web interface. Again, it's free software, and we'd love to have somebody contribute more layered tools.

    12. push and pull notifications - built in support for e-mail and news group notification of changes in the workspace.

    Nothing built-in yet, but we've been talking about doing it, and it may happen soon.

    There's a short summary of Vesta's excellent capabilities on it's web site (which includes several points not mentioned here), that I would recommend anybody interested in better version control/configuration management check out.

    --
    CVS is teh suck. Use Vesta instead.
  19. Re:We use Perforce at work by jkujawa · · Score: 3, Informative

    We use perforce, too. We've been less than satisfied with it. I'm don't know the size of the companies people with positive views of perforce are working for, but with a couple hundred developers, and on the order of a couple of thousand different code lines, the perforce server often grinds to a halt. More hardware has been thrown at it, more disk, etc, and no one can seem to figure out where the bottleneck is. It's very unpleasant when checkouts are taking 10 minutes, in the middle of the day.

  20. Re:Any one used Vesta? by [Xorian] · · Score: 3, Informative
    Vesta is great, but even though it's GPL, it still requires the STARLA libraries, which are only available on VMS/OpenVMS.

    I can only assume you're talking about some other Vesta from the one I'm familiar with, because:

    1. It runs just fine on Linux (x86 and Alpha, PowerPC in the works).
    2. I have no idea what STARLA is (and since I'm Vesta's primary maintainer/build master I think I'd know).
    3. AFAIK, Vesta (at least Vesta-2, which is the free software version) never ran on VMS. (It uses NFS and chroot, so I'd be really surprised to see a VMS port.)
    --
    CVS is teh suck. Use Vesta instead.