Slashdot Mirror

← Back to Stories (view on slashdot.org)

Designing a New Version Control System?

Posted by Cliff on from the replacing-rcs-and-obsoleting-cvs dept.

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?"

10 of 536 comments (clear)

  1. We use Perforce at work by WPIDalamar · · Score: 5, Interesting

    I've used CVS and Visual Source Safe (ick) before. But at my current job we use Perforce (a commercial product) and it rocks. There's clients for just about every known platform, a slick graphical GUI for windows (and they're working on a linux one), and there's this local webserver gui that works for all the platforms if you need something graphical to look at. The interfact to it rocks, the merging and branching rocks, and it is super flexible. We have some scripts set up so we can close bugs in our bugzilla database from some special tags in the description of a changelist (a changelist is what gets submitted when you check stuff back in).

  2. One thing must exist by truthsearch · · Score: 4, Interesting

    Absolutely key is (relatively) easy integration with IDEs. Preferably a nice set of APIs for any IDE creators to use to interact with the version control server. I would imagine those same APIs could then be used by any GUI developers of the version control system. IMO without the ability of the system to integrate well with IDEs adoption would be slow.

    --
    Developers: We can use your help.
  3. Need new languages by Bookwyrm · · Score: 5, Interesting

    Probably to make the 'next leap', so to speak, in version control systems for programming is to design or modify a language so it is more version control friendly, or add much more language-sensitivity to the version control system.

    Most people will probably hate this, but for instance, if a comment for a specific line/block of code always had to appear in a specific area or syntactically consistant way such that the version control system can recognize that if a piece of code changed, but not the comments for that code, it could ask if the comments for the code need to be updated as well. Or if a function's parameters or return value have changed, whether or not all instances/uses of that function have also been changed, etc.

    That is not to say that you cannot create a great system on top of existing languages, but that perhaps making some minor tweaks in the language to make the language itself easier to manage/version, then this may open up new tool possibilities.

  4. Version control system minimum requirements by Anonymous Coward · · Score: 5, Interesting

    IMHO, these are the bare minumum requirements:

    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.

    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.

    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.

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

    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.

    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.

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

    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.

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

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

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

    Your humble build servant :-)

    1. Re:Version control system minimum requirements by C-C · · Score: 5, Interesting

      While I agree pretty much with the anonymous post above (which suspiciously matches with BitKeeper's features :-), at least one thing is missing:

      13. Version control on a sub-file granularity.

      While I agree that this is a difficult problem, a typical use case is the "split a file" problem, which is supported by none of the available VC systems.

      Most renames of files I have seen in large projects are not simple renames, but splits, where a file's code is moved to separate files due to a refactoring. Only one of those files can be associated with the old file using a rename-aware version control system. The revision histories of the functions in the other files are lost.

      I don't have experience with implementing version control, so I don't know how solvable this is, but I can dream, no?

      C-C

  5. 10 problems with CVS by j1mmy · · Score: 5, Interesting

    1. Documentation is piss-poor. There's an easy solution to that one, but nobody likes writing documentation.

    2. Updates don't always work as expected. They won't grab new directories and a few other quirky things.

    3. Empty directories should be pruned by default in a checkout or update.

    4. I'm tired of seeing a CVS directory everywhere I look. How about .CVS instead?

    5. Access control is poorly handled. It's good that you can map virtual user names, but it would also be useful to control access by groups.

    6. Local CVS tree file ownership is by user, not the CVS owner. This opens up all manner of problems for users with a local CVS repository. Repository data should be in a non-user account, checkout should force authentication, and the server should handle who has access to what. This would not be tremendously hard to manage, since in the general case a user has access to a project or not. Fine-grained access control of the repository isn't a common necessity.

    7. Plays badly with (most) IDEs. When I want to work on a project in an IDE, it floods my checked out directories with all manner of crap I don't want in the repository. You can set up refuse files to clean these out, but it might break your IDE project. This is more a fault of IDEs than CVS, really.

    8. Needs smarter add functionality. I don't like writing stuff like 'find ./src/ -name "*.java" | xargs -n 100 | cvs add' just to hunt bring in my new source code.

    9. CVS is a boring acronym.

    10. I can't think of a tenth thing.

  6. What Exactly IS Wrong With CVS? by Ivan+Raikov · · Score: 5, Interesting
    Perhaps I don't have very complex needs, but it seems to me that CVS is already incredibly flexible and has all the advantages of Free Software. I'd like to point out the following reasons for continuing to use CVS (in no particular order):
    • Fits well with the Unix philosophy -- CVS, of course, builds upon RCS, and uses other Unix tools, most notably diff to accomplish its tasks. It also allows for custom shell scripts or programs to serve as handlers for various CVS operations. What other source control tool fit so well in Unix, and maintains the tradition of older Unix tools?
    • Customizable behavior -- CVS allows the user to provide three kinds of commit support files (like commitinfo, verifymsg, etc.) which are programs executed whenever files are committed.
    • CVS modules allow for multiple different definitions of collections of source code, so one is not restrained to just a directory and all the files contained in it as the smallest organizational unit.
    • Tags and keyword substitution -- CVS has a very powerful system for tagging files in various manners, and referring to those tags for purposes of commit/checkout/diff/revision history. I don't know how much better than that you can get. Substituting keywords, a favorite feature of mine, lets you include your version history in the sourcefiles -- this is important when you're working with other programmers and you want to spare them the inconvenience of having to do `cvs log' each time they want to see what changes you've made.
    • Repository format is plain text -- well, I am a staunch believer in open file formats, and plain text/diff is about as open as you can get.
    --
    Bush Lies Watch
    1. Re:What Exactly IS Wrong With CVS? by brettw · · Score: 5, Interesting
      Perhaps I don't have very complex needs, but it seems to me that CVS is already incredibly flexible and has all the advantages of Free Software.
      CVS is a proven workhorse. I use it every day, keep my configuration files in a module, etc. in addition to my source code at work. But there are some things that are absolutely maddening about it (the early AC post with 12 must-have's hits several of them on the head). Personally, as my CVS usage is for a relatively small team, the lack of atomic commits just hasn't bitten me yet, although I can see why it's important for a best-of-breed tool.

      But a couple of day-to-day common tasks are painful (or just plain impossible).

      Personally, sharing source files across multiple projects is a real pain. We do it with soft links in the repository (gag) so it can be done, but it's ugly.

      Let's say you want to reorganize your directory structure without screwing up your history. Well, that's hard to do with CVS, so instead we'll just let the organization continue to be cluttered and confusing.

      Heck, let's say you just want to rename a file, let alone a directory:

      cp foo.c bar.c
      cvs add bar.c
      cvs remove -f foo.c
      cvs ci -m "renamed foo.c to bar.c"

      It just gets really annoying, and now bar.c can't be reverted version-wise unless you KNOW that its previous contents were in foo.c. It's a manual, error-prone, and tedious process if you ever need to do that.

      I've been running a subversion server for months now just to test out. I can't wait to move to it. I like being able to say:

      svn mv foo.c bar.c
      svn ci -m "renamed foo.c bar.c"

      and keep my history intact.In fact, writing this makes me want to just start migrating stuff by hand today! Subversion's important bugs (it is still alpha I think, it's slashdotted so I can't check the status as of right now) are almost all in features that CVS doesn't have anyway.

      That said, I haven't really tried any of the other open source projects such as arch which have similar features. The main draw of subversion for me is the fact that I had to learn almost nothing to use it. As an experienced CVS user, subversion is trivial to learn. The effort they have put in to keeping things the same as long as there is no good reason to do otherwise is well-spent (at least from my point of view).

      Plus, the subversion code is super readable and well-commented--honestly the best source I've seen.
  7. There's a big difference between by wls · · Score: 4, Interesting
    Version control systems, as a whole, seem to make a mistake when over-generalizing and combining concepts with implementation. These things are all different:
    • The file you want versioned.
    • The archive that holds it.
    • The workfile you extracted from an archive.
    • The shadow file automatically extracted from an archive.
    • A directory.
    • A project, which is not always 1:1 with a directory.
    • A view, which is not a subset of files or directories.
    For instance, I may have the file archive.c,v which I check out as myfile.c, which is shadowed as mainfile.c, which exists in multiple projects, inside different subdirectories, exposed whenever I have a view of a particular time on a particular branch for a given subset of a module.

    Everytime a version control system tries to combine things you run into problems. Take the GUI version of PVCS, which called Projects a collection of files (from different directories) -- which ended up enforcing that all filenames had to be unique, even if in different directories. And what they call Views is actually a subset of the list of available filenames.

    Ever get the idea developers are so into archiving versions of a file that they gloss over the fact the file organization itself is a structure that also needs preserving?

  8. Get rid of the file system completely - simplify! by stienman · · Score: 5, Interesting

    Maybe it's time for a major shift in cod storage.

    Let's get rid of the file system/directory stucture schema and go with a completely revamped code storage method.

    This has a ton of implications, but one thing that everyone seems to ask for that is difficult to solve on the old model is easy to work with if you remove the files and directories - sub-file VC. Being able to move modules from file to file, split files, move directories, etc.

    The files and directories are there to help us understand the structure of the project, they were not meant to dictate the structure to us. We've locked ourselves into them so much so that we can't restructure the project without losing a lot of the benefits of VC.

    Let's stuff our code into a database (which is like a more powerful file system, if you can't get your head around the idea). Atom updates can be built in. Symlinks are simple. Shifting a piece fo code to another 'file' is simple and the VC is not lost.

    I can't be the first person to have thought of this - why hasn't it been done? Possible cons are:

    Until the compilers and IDEs understand the new schema (regarding header files, includes, etc) the VC will also have to provide scripts to combine portions of code into files that the compilers can use.
    How do we store the data in the database - it would depend largely on the language. Would we put a function in a blob of a record, or maybe even do line by line records. In highly OO languages (java) we could structure the database so there are class records that link to member records that link to variable and function records, etc.

    Eventually the toolchains will attach to the DB directly.

    Consider how this would aid huge and tiny projects alike.

    I swear, the sooner we get rid of the file system (as is) the better - not just for this, but for all our information. But let's not get ahead of ourselves.

    -Adam