Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Designing a New Version Control System? 538

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Designing a New Version Control System? More

Designing a New Version Control System?

Comments Filter:

  • pretty gui's (Score:3, Funny)

    by Alric ( 58756 ) <slashdot@ten3.14hundfeld.org minus pi> on Tuesday July 16, 2002 @07:20AM (#3893031) Homepage Journal
    Obviously these new tools should have little functionality masked by really fancy GUI. At least, that's what I've been trained to like.

    • You mean like Starteam [starbase.com]. It looks like a nice package, now if only it could given an accurate status on a file instead of "unknown". It would also be nice if the merge option didn't mangle the code. "1.04" merged with "1.01" somehow works out to be ".1".

      I must admit it's better than SourceSafe from MS.

      • Re:pretty gui's (Score:3, Informative)

        by wls ( 95790 )
        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!

    • Re:pretty gui's (Score:2, Informative)

      by Tei'ehm Teuw ( 191740 )
      Heh, but it doesn't have to be that way. Look at Clearcase. Good gui and gobs of functionality. Too bad it's so expensive.

      • Re:pretty gui's (Score:2, Insightful)

        by _Swank ( 118097 )
        and suprisingly difficult to use to do simple little things (deleting files, etc.) while making it nearly impossible for a normal person (read non-rational expert) to recover a file that had been deleted, but is needed once again. the problem with clearcase is that it's not only really expensive, but it almost requires an admin devoted full-time to clearcase if even a single project is using it. and it's gobs of functionality are great until you realize that 90% of projects don't need some of that stuff (especially integration with all other Rational tools which doesn't seem to work nearly as well as anyone would like) and it ends up making what they do need more complicated than it should be.

  • Shome mishtake? (Score:4, Informative)

    by albalbo ( 33890 ) on Tuesday July 16, 2002 @07:22AM (#3893037) Homepage

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

  • Simple answer. (Score:3, Insightful)

    by Anonymous Coward on Tuesday July 16, 2002 @07:24AM (#3893044)
    "My question is exactly what would this 'better system' look like?"

    You said it, BitKeeper. It's there, it's very good, don't people have anything better to do than nagging about other people just charging for their own work?

    If you want to give away your work, please do (I'm happy to use it) but you are not BitMovers (the company) mom and have no business telling them what to do.

    • Re:Simple answer. (Score:4, Funny)

      by SN74S181 ( 581549 ) on Tuesday July 16, 2002 @07:38AM (#3893127)
      Now it's just a matter of some GNU programmers coming out with a knock-off version that's not as good, but good enough. First, though, we need to come up with a name. It has to be a clever twist on BitKeeper.

      I nominate:

      'ByteLoser'

      Who wants to slap up the SourceFarce page and start working on the icon?

  • We use Perforce at work (Score:5, Interesting)

    by WPIDalamar ( 122110 ) on Tuesday July 16, 2002 @07:25AM (#3893056) Homepage
    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).

    • Re:We use Perforce at work (Score:5, Informative)

      by forgoil ( 104808 ) on Tuesday July 16, 2002 @07:42AM (#3893159) Homepage
      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.

      • Re:We use Perforce at work (Score:5, Informative)

        by digerata ( 516939 ) on Tuesday July 16, 2002 @07:50AM (#3893204) Homepage
        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.
      • I hate to be an also-ran but, we use Perforce here also. In my history as a developer I have used RCS, CVS, Continuus and Visual Source Safe. The only product that comes close to Perforce in functionality Continuus. The difference is that Perforce actually works and you don't have to wait for hours to complete sync and integrate operations while hopeing it won't crash. Perforce is also less expensive than Continuus and the server runs on more platforms including Linux.
    • We use Perforce as well, and I love it. After using Perforce for months now, I can't go back to CVS. Branching, labeling features all make sense.

      Creating a branch is very much like copying all the source to another directory (e.g. you had all your source in mysoft directory, which is your trunk.. when you branch, you copy that to mysoft2 directory and now you have a branch.. best of all, every new branch takes up a miniscule amount of disk space, storing only the files you actually change). And then Perforce supplies you with powerful integration tools to let you synch changes across branches.

      It has some flaws, like no version control on client, branch and label specs, so if somebody messes up the definition of a branch, you can't step back to the last version, but otherwise it's an excellent source code management (or whatever the right term is) system.

      If anyone's curious about P4, they can read the manual [perforce.com].

    • 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 [perforce.com] (scroll down for open source info) and here [perforce.com]

      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.

    • There is also an Emacs client for Perforce. It's not completely full-featured, but it means you don't have to bother with any of the standalone clients when doing basic editing and version control tasks (You are using Emacs as your editor, aren't you?). When I need to do something fancy, you still need to use one of the standalone clients (GUI, commandline, or web).

      Besides the Emacs integration, there are integrations for Developer Studio, Windows explorer, Perl, Python, Forte, Eclipse, etc. These are all available at Perforce User Interfaces & Integrations [perforce.com].

    • Re:We use Perforce at work (Score:3, Interesting)

      by e40 ( 448424 )
      I tried to use Perforce, but I couldn't get my repository (CVS, started in 1990 with version 1.1 or 1.2) converted to a depot. There were two tools for doing it, both user contributed. They just didn't work.

      I talked with the p4 staff and they said they would help me do it (tweaking the tools if need be, I assume). I was just a little too nervous, though, about not being able to try it before I committed all those $'s.

      To be fair to the conversion tools, I believe since my repository is so old, that the format of the RCS files is slightly different than what would be created today by CVS. Back then, CVS actually used the external RCS programs to operate on the ,v files.
    • 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.

  • The choice is clear (Score:5, Funny)

    by BoBaBrain ( 215786 ) on Tuesday July 16, 2002 @07:26AM (#3893059)
    Shouldn't we just use whatever source control system the CVS developers use?

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Tuesday July 16, 2002 @07:27AM (#3893067)
    Comment removed based on user account deletion

  • one word: patchsets (Score:3, Interesting)

    by kix ( 24024 ) on Tuesday July 16, 2002 @07:30AM (#3893083) Homepage


    add that to cvs and make it actually work correctly and it would be pretty good.

    at least that's what I miss the most when using cvs - the ability to change several files and commit them at once and when I do an update on a file it sould figure out all the dependencies on all other files ant update those as well. how sould it figure this out? simple - all the files that were commited at one time sould be also updated together, because it is bloody likely that they depend on each other.

    of course this process should be repeated on all files that are a part of the patchset so that after updating a single file to a new version all the other files are compatible with it.

    and yes, I know this could be theoretically done with tagging but then I would have to tag all files when commiting every time and it still does not handle the case when one file of the patchset depends on some other patchset.
    • and yes, I know this could be theoretically done with tagging but then I would have to tag all files when commiting every time and it still does not handle the case when one file of the patchset depends on some other patchset.

      Not true. CVS allows you to create the so-called modules, which can be groups of files or a directory. Then you can use commands like `cvs ci modulename' or `cvs co modulename' in order to update/checkout only certain sets of files.

      Not sure about your second case, but it sounds more like bad organization than anything else -- have in mind that CVS allows you to create module aliases which refer to groups of modules. Not exactly detecting if a single file in a module depends on files in another module, but still...

    • object changes on tasks (Score:2, Informative)

      by beofli ( 584044 )
      Look at Continuus Versioning Control System: every change on an object belongs to a certain so-called "task" (or more than one task). tasks belong to a certain task-folder and task-folders can used for releases. Continuus has a nice flexible database, but the disadvantage of this is that it makes it complicated for people to learn it fast.

  • One thing must exist (Score:4, Interesting)

    by truthsearch ( 249536 ) on Tuesday July 16, 2002 @07:34AM (#3893105) Homepage Journal
    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.

    • Re:One thing must exist (Score:2, Interesting)

      by pmz ( 462998 )
      Other than adding a great deal of complexity to an already complex system, do graphical IDEs really contribute anything useful?

      The time spent learning an IDE whose scope is pretty narrow is time that could have been spent learning general widely-useful tools, such as vi or emacs, make, and sh.

  • Need new languages (Score:5, Interesting)

    by Bookwyrm ( 3535 ) on Tuesday July 16, 2002 @07:35AM (#3893110)
    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.

    • Re:Need new languages (Score:2, Interesting)

      by des09 ( 263929 )
      I was just thinking exactly the opposite thing... as a developer who works with Java, VB, XML, HTML, JavaScript, SQL and the occasional bash script, I think the problem is that the version control systems know nothing about the languages. I think the main issue is that version control is it is viewed as a control system, not a development tool, something to help deliver the highest quality code.

      Especially with Java and cvs I am always frustrated that CVS does not know the difference between a .properties file, a jar, .java etc, and more to the point, CVS make refactoring across packages a very laborious and time consuming task. Visual SourceSafe and VB are better suited to each other, but still no great match.

    • Re:Need new languages (Score:3, Interesting)

      by jhines ( 82154 )
      Don Knuth's language web had an interesting feature, the ability to generate documentation from the same source code.

      I think coders would be a lot better at commenting their code, and writing documentation if it was all integrated.

      The ability to easily document a functions purpose, used data, and other information would be nice.

    • I agree completely. One of the goals of the system that I'm
      working on (Stellation [eclipse.org]) is the integration of pluggable
      semantic components for particular programming languages.

      Our basic idea is that if you don't know the language that
      something is written in, you treat it as text, providing all
      of the capabilities of a system like ClearCase. But if you
      do know the language, take advantage of that support, and
      provide extra, language specific capabilities.

      -Mark

    • There is a natural extension to this which is just begging to happen: dependancy analysis and locking and/or approval mechanisms on a sub-file basis.

      Essentially, if the SCM can parse the language, it can figure out what its looking at (classes, members, functions, etc), and what other parts of the entire source code use what its looking at.

      Combined with an approval mechanism, the potential for code auditing is staggering: audit a function and mark it as such. No function can be considered audited if it calls a function which is not audited. If a function which was audited is updated, all functions which call it (in the new project revision) are no longer considered audited.

      Functions and function documentation are audited as a unit. The should be obvious, because the idea of invalidating the stamp of approval on functions which call altered code is based on the idea that pre/post conditions may not have been properly disclosed or checked.

      A class cannot be considered audited until all members are audited, and a file requires all contents to be audited.

      Implementing a system like this for a languge like Java would not be tremendously difficult; but C++ (especially) is a very complex language to parse and analyse in this manner.

  • Version control system minimum requirements (Score:5, Interesting)

    by Anonymous Coward on Tuesday July 16, 2002 @07:35AM (#3893112)
    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 :-)

    • Re:Version control system minimum requirements (Score:5, Interesting)

      by C-C ( 67249 ) on Tuesday July 16, 2002 @07:57AM (#3893255)
      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

    • I'll add a couple things:

      • Triggers - must be able to specify a script to run when certain events happen, like checkin, checkout, add label, etc. Triggers should also be able to prevent an action from occurring if the trigger script decides that a condition has not been met.
      • Multi-site - the system must be set up so that developers at multiple sites around the world can collaborate on the same sources fairly easily. This is more of an enterprise feature, I would think.
      • Securable - at least make it tunnelable over SSH or something like that, at a minimum.
      • Transparency - must be able to dig out all of the details about the system and the files and versions contained in it automatically from the command line or some API, so that the system can be analyzed and manipulated by automated tools for metrics reporting, etc.

      Here's a good question that you raised - is a three-way graphical merge really the best way to do a complex merge? I've done a lot of them and it mostly works, but at times it still seems like a sub-optimal solution. Does anyone else have a better system for complex merges that they do?

    • Re:Version control system minimum requirements (Score:5, Funny)

      by Mika_Lindman ( 571372 ) on Tuesday July 16, 2002 @07:58AM (#3893268)
      13. allows version numbers larger than 1. I'm tired of all open source being with version numbers like 0.997
    • The first two are of particular importance.

      By processing the 'commits' as a transaction it guarantees that only one person is committing at a time.

      With both 'Transactions' and 'change list management' commits can be rolled back in reverse order to revert the system to any previous state should a major commit (with many files) go wrong.

      I think good basic operations would be 'Catch up' (merge changes into local workspace) then you can run tests and check everything is ok. Then the atomic 'Commit'. The system would also needs to check that no other transactions has been processed between the 'Catch Up' and 'Commit', or the developer should be forced to catch up again.

      Why do most version control clients have 6 million options but don't contain just these simple 2 operations you want? Probably mainly for historic reasons I guess.

      I think the version control system on VisualAge for Java MicroEdition had a system like this called 'Team Streams'.
    • Honestly this sounds a lot like many of the features that perforce has (which I use at work too).

      Atomic commits -- if perforce can't process all your files in your changelist, it won't submit them. this means if one of hte files in your list is out-of-date with the server version (your revision number is lower than the one on the server, which means you have to resolve the merge) or if you've done something that perforce doesn't like with a file. you can't force it either.

      changelist and access control - perforce sets up "clients" which map it's depot on your local computer. you can create as many changelists as you need and as you check out files add them to various change lists, submit one changelist while you have others open, submit some files from a directory and keep others checked out

      web viewer/graphical diff - there's a web viewer and the windows version has a diff program.

      it does labelling, it supported on EVERYTHING thing (including Mac os pre-X via the Macintosh Programmers Workshop via the Command Line, and OS X via command line)

      • Only problem with perforce is it doesn't support distributed offline work.

        You have to connect to the central database for EVERYTHING. All files are locked until you manually checkout a file. If you have a slow network connection or disconnect periodically, you have to reconnect every time you want to make a change (add a file, edit a file, change attributes on a file, see what files have changed, etc).

        For open source development this can be a major problem.

        Further, a centralized database can be problematic for separate development trees (not branches). The best you can do is copy the database to a new machine and run from there.

        One feature I like of "arch" is that you can have decentralized development with independent trees/databases, and merge them back into the main database at a later date. There are several frustrations/limitations with arch so I'm not recommending it, just showing that someone else has solved this problem.

        In general, I like CVS's (and arch's) view-private meta-data which allows a subset of operations to be performed. Not least of which is which files have been changed,and the ability to modify files without central authority. Other than that, I like just about all the features of perforce.

    • A couple other posts have mentioned Vesta [vestasys.org], 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 [scooter.cx].

      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 [scooter.cx]. 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 [vestasys.org] (which includes several points not mentioned here), that I would recommend anybody interested in better version control/configuration management check out.

  • some thoughts (Score:3, Insightful)

    by TTimo ( 253584 ) <(ten.omitt) (ta) (omitt)> on Tuesday July 16, 2002 @07:38AM (#3893123) Homepage
    CVS may be the best open source version control tool right now, it still suffers from a lot of shortcomings.

    Generally speaking, stuff like commit emails need the addition of specific wrappers (see http://cvsreport.sourceforge.net for instance), and CVS doesn't scale well to big projects .. doesn't handle big binary files in a satisfactory way

    It's quite usable .. but I'm really waiting for subversion to get mature and usable for production..

  • Yes, it is time for a new tool... (Score:5, Informative)

    by mdorman ( 4972 ) on Tuesday July 16, 2002 @07:38AM (#3893128) Homepage
    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.
    • 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.

      Can you back this up? I'm interested to see.

      I have to admit I'm biased to CVS. I love it so much that I used to sleep with a floppy containing the binary under my pillow for a month. (ok slight exageration).

      Anyway I see a big breach in the "open source" way of doing things. In the past a simple project would grow as needed. If features didn't exists or bugs were around. Someone would fix it.

      CVS has been the de facto standard for version control in the "open source" community especially in say SourceForge. Now it's being abandoned like a poor basterd child. I would like to see just why a proven software that in many ways is one of the best, known to out beat VSS the lord and ruler (MicroSoft), is now now a heap of garbage not worthy of the "open source" way of collaborative enhanchments.

      Instead of throwing it away reuse it. If RCS isn't possible rewrite it. Convert CVS to a new and better way. But why destroy the one faithfull servent because it's old or doesn't live up to expectstions. We're smart people. If Linux had the same problem would we abandon it at a whim? No, I'd like to belive we would make it better. Did the GIMP give up when they were faced with a crappy Windows ToolKit?

      It sounds as if it is a tempermental thing that many people are assamed of the CVS name. I, who belives in CVS and sometimes worships CVS; who in my many years of administration have never seen a problem can't fathom why it would be so ridiculed and persicuted in a world that pride themselves on co-operation and "freedom" to enhance and superiorize software at will. A huge efort to give CVS up is underway and no effort to bring CVS to the top of the ladder. It seems counter productive and contrary to what "free software" or "open source" ideals used to be.

  • I think the question is wrong (Score:4, Insightful)

    by lfourrier ( 209630 ) on Tuesday July 16, 2002 @07:39AM (#3893134)
    In fact, you exhibit a common misconception. If you want version control, CVS do the work. But what you seem looking for, and what do many of the alternative proposed in the replies is configuration management.
    Now, what an ideal system would be? I don't think one size fit all. You need very quick local net access (bye bye CC), and you need infrequently, losely connected internet developpers. But not at the same time. So I don't think tere is one unique response to your question.
  • My largest problem with most of these revision control systems for Open source is the Lack of the Windows based Servers...I Know I know...but unfortunately most of the development I do is for the company I work for, and I just don't have a choice in these things. I have to develop for windows here, and I have to use windows systems, NO Linux, BSD, etc allowed. However I can't stand most of the Closed Source systems, I would love to be able to use one of the open source systems at work. Before you get tofar down that road of thought, Cygnus(or VMware, etc) is not the right fix here either, the server team does not allow that sort of software on the servers.

  • Key Feature: directory awareness (Score:5, Informative)

    by antony ( 86710 ) on Tuesday July 16, 2002 @07:46AM (#3893180)
    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!

    • There's a big difference between (Score:4, Interesting)

      by wls ( 95790 ) on Tuesday July 16, 2002 @08:34AM (#3893518) Homepage
      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?

  • Look to ClearCase for some pointers (Score:5, Informative)

    by EasyTarget ( 43516 ) on Tuesday July 16, 2002 @07:49AM (#3893195) Journal
    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.
    • We used clearcase extensively at an old company of mine, and it was great for internal projects. I definately don't think it has any place for open-source, however. Mounting file systems over the internet is definately out.

      As someone pointed out, many of the types of issues questioned in this tread are configuration management issues, not version control issues. Case in point, as powerful as clearcase was, we developed a MASSIVE set of wrapper scripts to automate many regular and complex tasks. These scripts would have been portable to many styles of version control (though probably not CVS).

      The main thing I didn't like about clearcase was it's dependence on the central server. I personally hate operating off mounted file systems. They're great for sharing info, but I've flat out refused to make my home directory nfs'd for a good reason.. It's slow and unreliable. There's always a point where something goes wrong or some administration is going on behind the scenes, and your desktop freezes. Likewise compilations are many times slower due to massive accesses to medium to small sized files.

      It is great for administrators though.. Backups are a sinch (since distributed data is all really stored centrally). It's also somewhat scalable since you can have separate servers perform different functions.

      It is expensive, however; both in licensing and hardware.

      My 10b cents.
      -Michael

  • Two different useage models (Score:2, Informative)

    by nut ( 19435 )

    I think in designing a source control system you have to be aware that there are two different usage models.

    • A small team, working in the building or room, with strong lines of communication, using source control ans integral part of a larger formal development process.
    • An open source or widely distributed project where many or any people can contribute to the project, the lines of communication are weak, and the development process is largely ad hoc.

    CVS has been designed and mostly used for the latter. Tools like SourceSafe and Clearcase were designed, and are almost exclusively used for the former.
    One of the obvious differences in approach is file locking on checkout. Obviously there are others as well.

    I don't see any reason why one tool could address both models, with suitable ruleset configuration for the administrator. But you have to recognise, and design for, one or the other or both models from the start.

  • I have a personal bias on this issue, but for me CVS is all I need. Having lots of fancy features like file-locks in StarTeam, and SourceSafe creates a false sense of security. I don't have 20 yrs of experience like some people, but in the 7 yrs of programming the organizational structure has a the biggest effect on source management and control.

    Trying to maintain a huge source database with hundreds of developers is basically impossible if there isn't a well established team structure with source managers. When there are fewer than 6 developers working on the same project, it is fairly smoothe. With 12 or more developers, it gets exponentially harder to figure what's going on. Unless there are very few check-ins or changes and the source is in maintenance mode.

    In active development phase, there may be dozens to hundreds of checkin's and changes per day, which may cause an unknown number of effects. It doesn't matter which development style you use, because in the end it comes down to whether or not the product is divided into small manageable chunks. Distributed development is a management artform and very few managers know how to do it effectively. I would put forth the idea that the tool for source management is really only 20% of the equation of distributed development/source management. Trying to address the problem by focusing on the symptons isn't a solution to the real cause of the illness.

  • 10 problems with CVS (Score:5, Interesting)

    by j1mmy ( 43634 ) on Tuesday July 16, 2002 @07:53AM (#3893235) Journal
    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.
  • A decent version control system should provide support for change packages - (atomic groups of changes that must be promoted through the system as an single unit). It also needs to provide support to manage a set of stages in the developement cycle so that changes can travel through development, qa, and production in an easily manageable manner. Hooks to integrate with issue tracking systems is also importand. Perforce has most of these features but they are somewhat cumbersome to use. MKS Source Integrity probably also has these features.

  • What Exactly IS Wrong With CVS? (Score:5, Interesting)

    by Ivan Raikov ( 521143 ) on Tuesday July 16, 2002 @07:59AM (#3893273) Homepage
    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.
    • Forgot one thing: integration with Emacs. Duh. What could be more important than the smooth integration CVS has with the One and Only True Editor?

    • Re:What Exactly IS Wrong With CVS? (Score:5, Interesting)

      by brettw ( 27391 ) on Tuesday July 16, 2002 @08:59AM (#3893704)
      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.
    • As a Java developer there is one big thing missing CVS. Code refactoring support.

      For example:

      Lets say you are working on a large project 20 or so developers. And you create a little utility class for the area you are working in. You check in the code to your module (or package ) and use it. A few of you buddies are running into some problems that your utility can solve so the end up using the class. Now a few months later a large amount of code now uses your little utility, and the leads want to move your class to the global utility package. Tools [intellij.com] exist that can quickly move the class and change all of the references that use that class. But to check in this change is a nightmare.

      The thing is in Java this type of operation is common, and is good for the project (keeps the code clean). But until a version control system has proper code refactoring support it will always be hard to do.
      • What kind of support for refactoring do you have in mind? I do Java development with plenty of refactoring (using Eclipse), and most of the time a simple commit of the tree picks up all the changes. The only exceptions are new files, and renamed/deleted files. However, that's not always an issue, and when it is, it's usually not on a lot of files.

        BTW, one thing that can help is to use a GUI interface to CVS. Eclipse integrates with CVS, and on Windows, WinCVS does a good job.

    • At some point you need to develop instead of monkey around with the source code control tool.

  • Why "The Open Source Community?" (Score:3, Interesting)

    by NitsujTPU ( 19263 ) on Tuesday July 16, 2002 @08:02AM (#3893289)
    Basically, does the Open Source Community need new tools in this aspect of development?

    Why only ask about the open source community. Do programmers need new configuration management tools?

    CVS works fine for me. BitKeeper seems nice too. What I hate is that there's so much controversy just because BitKeeper isn't open source.

  • I once started coding a version control system... (Score:3, Funny)

    by gentix ( 559742 ) on Tuesday July 16, 2002 @08:08AM (#3893322)
    I tested it by putting the code under version control, but then I discovered a bug...

    I've never seen my code since...
  • ... that the problem needs to be reimagined.

    I haven't looked at all of the new revision control systems, but they all seem to be evolutionary modifications rather than revolutionary changes to how things are done.

    I don't think we'll see a truly successful next-generation revision control system until somebody tackles the problem from the ground up in an imaginative way.

    • Take a look at Stellation. [eclipse.org]
      Our long-term goal is to fundamentally
      change the way that programmers view and store thier code.

      If you want to use a CVS lookalike, Stellation can do that. But
      in its full-blown form, source files become an illusion. You can
      still edit them, save them, etc... But the versioning is happening
      at a finer grain. Refactor your code to move a method, and Stellation
      preserves the full history of that method. Need to look at a bunch
      of code that's scattered through many files? Issue a query to generate
      a file containing exactly what you want to see. Edit it there,
      and then when you commit the change, it shows up in all of the
      other files where that code lives.

      -Mark

  • CVS is great, but it doesn't know enough about common file types that are checked in to it. It doesn't do diffs between image files that it considers "binary" format. Also PDFs, Word Documents, and the like could have better than "binary" file support. I am constantly annoyed that I can't change tabs to spaces or adjust indentation in source files without causing diffs. Both of those problems would be solved if CVS knew more about the file type. The second can theoretically be solved by CVS by adding checkin and checkout scripts for each file. The script would remove all whitespace from the beginning of each line on commit and then pretty print the output on checkout. However, I haven't found scripts that will do so yet.

  • I would love this: (Score:3, Interesting)

    by idfrsr ( 560314 ) on Tuesday July 16, 2002 @08:31AM (#3893488)
    This type of thing may be out there already, but it would be great to have system to link the CVS like control with bug submission, so checking out files will also give you the set of submitted bugs related to those files.

    Of course a strict bug submission policy would be required to make this possible, but surely something like this could be done?

    An added benefit would be clearer bug submissions which would help development to no end...

  • Look at VESTA (Score:2, Interesting)

    by RollyGuy ( 24873 )
    I use Vesta at work and find that is is better than CVS. One of the major differences is that it is also a build environment. That means that you along with your code, you can have the compiler versions that you used to build the code with. Vesta does the building within itself and then "ships" the executable to where you need it.
    It is also easy to work concurrently.

    I believe that you can also do the following: User X checks out and edits file A.
    User Y checks out and edits file B.
    User X calls user Y to test file A's changes with file B's changes.
    User Y tells vesta to build with the checked out version (X's checkout) of file A.
    User Y builds and tests the two edits together.

    One other important feature for large projects is that Vesta intelligently caches created files. So, if User X and Y are working on the same project, then they can save on compile time by only creating files once and sharing them if possible. This is a necessary feature in large projects.

    Anyhow, check out the webpage at http://vesta.sourceforge.net.

  • Yet Another useless discussion about CVS. (Score:5, Informative)

    by His name cannot be s ( 16831 ) on Tuesday July 16, 2002 @08:34AM (#3893512) Journal
    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.

    • Look, Windows 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 Windows that make it unable to be replaced:

      1. Massive Acceptance: Windows is everywhere. 50 million people use it every day. Another few million elsewhere. It is the common thread that pulls us apart (kinda like the government!)

      2. Massive, Massive Application support: This is my favorite. You can use it about a hundred different ways. Not 1 gui, but 500000!. It doesn't have command line apps, like great!. Show me another OS that has integration with the windows explorer like it has. You Can't. (Don't even try that god-awful WINE's integration:yuk!)

      3. SimplicityIt's REALLY simple to use. It's not that complicated. If Windows throws you for a loop, maybe anything involving computers really isn't where you should be working. The incompetence among users is what makes all software look bad.

      4. Protocols: You can run Windows with SSH, RSH, SMB, 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 Windows in all those areas, AND provides features that "I can't live without" Windows will Rule.

      This is NOT a troll. 100,000 lemmings CAN be wrong.

  • Might as well burn some karma and give my experience with various systems:

    RCS: primitive, but ok

    CVS: hated it. hate, hate, hate automatic merges; don't trust 'em. And WinCVS...man, my Milton's Ant Farm had fewer bugs.

    VSS: not bad, actually. I love file locking, it seems pretty easy to tag various milestone releases, a reasonably clean interface, and easy access to pretty much everything I want to do. Some quirks but nothing major, very usable.

    ClearCase: jury's still out but so far I don't like. Very complex and proccess heavy; it's out to be the manager's buddy, not the engineer's. Everything has to be done in the context of a distict "activity" (plus we've had some trouble settling on rules for if a checkin automatically closes the said activity...) and concepts like "VOBs" and "Integration streams" and "development streams" are hard to keep your head around. And it's slow and generally process heavy.

    EveryOnceInAWhileCopyEverythingToABackupDir: this is the one I usuaslly end up with when I'm on my own.
  • In the middle of the CVS bashing, remember that lack of source code version control is listed as a classical mistake in most software engineering literature - at least in what I've read.

    When things cool down (yeah, right), I'll look at the other projects. Until then, I'll live reasonably happily with CVS.
  • Verizon control? That's a great idea! We should enforce regulations as to how many annoying commercials they are allowed to air in one day!

    Can you hear me now? Good...

  • What about Aegis? (Score:4, Informative)

    by red_dragon ( 1761 ) on Tuesday July 16, 2002 @08:57AM (#3893680) Homepage

    Every time the issue of version control and source code management comes up here, I've never seen anyone mention Aegis [sourceforge.net], 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 [sourceforge.net]:

    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?

  • I've never used subversion, so I may be wrong. However, a brief scan of their web site makes no mention of change sets. If that means it's file based (like rcs, CVS and SCCS), then it stands no chance. Change sets are an essential feature of any modern source control system. I wasn't convinced until I'd played around with TrueChange. Since then, I wouldn't consider going back. BitKeeper is designed from the ground up to support changesets, and it's not something that can be easily tagged on at a later date. For that reason alone, subversion won't succeed. PRCS looks promising, though...

    • 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

  • One word (Score:4, Informative)

    by MuValas ( 91840 ) on Tuesday July 16, 2002 @09:18AM (#3893888)
    "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.
  • Our project just bought into a tool called Speedev [speedev.com]. Anyone heard of them? Anyone using this product?

    The product demo was impressive. Seems to a complete SCM tool. The problem with most source code tools like SourceForge and CVS is that they don't really address the entire SCM process in one integrated tool. Why is that? What tools to you use for Requirements tracking? Defect tracking? Testing?

  • 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

    • That's part of what we're doing in Stellation [eclipse.org]. Our basic
      view is that source files combine storage and organization
      in unfortunate ways. So we want to break that linkage: code
      lives in the database, stored as small pieces. Pseudo-files
      are generated to give you organizational views of the system.
      Because storage and organization are distinct, there's
      no reason that a given chunk of code can't be viewed in multiple
      pseudo-files.

      The big catch is that there
      are an awful lot of very useful tools out there, and they're
      not going to give up their filesystems overnight. So you need
      to be able to both discard the file notion when it's appropriate,
      but at the same time to preserve the ability to use a filesystem
      when necessary. Stellation pseudo files can always be exported
      into a real filesystem to work with tools that don't understand
      it's database storage model.

      -Mark

  • Aegis (Score:2, Informative)

    by PghFox ( 453313 )
    Aegis [sourceforge.net] is a project change supervisor, and performs some of the Software Configuration Management needed in a CASE environment. Aegis provides a framework within which a team of developers may work on many changes to a program independently, and Aegis coordinates integrating these changes back into the master source of the program, with as little disruption as possible. Resolution of contention for source files, a major headache for any project with more than one developer, is one of Aegis's major functions.

    Aegis enforces a development process which requires that change sets ``work'' before they may be integrated into the project baseline. Works includes requiring that change sets build successfully, and (optionally) that they include and pass tests. It also ensures that code reviews have been performed.

    • Transaction based
    • Supports large teams and projects
    • Supports change sets
    • Designed for repository security
      • availability
      • integrity
      • confidentiality
    • Supports distributed and multiple repositories
    • Mature. First release was in 1991 and is still being actively developed
    • Easy to use. Can be learned in under a day
    • Supports multiple simultaneous active branches and branching to any depth
    • Supports both push and pull distribution models, and many distribution topologies
    • Error messages of Aegis are internationalized

Slashdot Top Deals

There are new messages.

Close