Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Making Sense of Revision-Control Systems 268

Posted by kdawson from the only-constant-is-change dept.
ChelleChelle writes "During the past half-decade there has been an explosion of creativity in revision-control software, complicating the task of determining which tool to use to track and manage the complexity of a project as it evolves. Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial. It is important to keep in mind that whether distributed or centralized, all revision-control systems come with a complicated set of trade-offs. Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works. This article outlines how to go about finding the best match between tool and team."
This discussion has been archived. No new comments can be posted.

Making Sense of Revision-Control Systems More

Making Sense of Revision-Control Systems

Comments Filter:
  • We've had great luck with Perforce for several huge projects. I use it at home for smaller personal work too. It's excellent (no connection with the company, just satisfied customer).

  • Git and Mercurial? (Score:4, Insightful)

    by capnchicken ( 664317 ) on Tuesday August 25, 2009 @06:24PM (#29194463)

    Git and Mercurial are more popular than Subversion? That's the big news to me, with all snarkyness aside. I best be getting out of my bubble.

    • Re:Git and Mercurial? (Score:5, Interesting)

      by Vanders ( 110092 ) on Tuesday August 25, 2009 @06:32PM (#29194547) Homepage
      I share your scepticism. Given the vast numbers of CVS repositories that exist and the ease with which you can transition to Subversion, I don't think it's popularity is going to wane any time soon. It also has some of the widest range of plugins for IDEs such as Visual Studio and Eclipse and the largest number of tools and clients, which make it a popular choice for a lot of new projects. Outside of Linux development Git is almost unheard of, but may gain popularity and although I've worked with Mercurial professionally I've yet to see it used anywhere for Open Source development, yet.

      • Outside of Linux development Git is almost unheard of, but may gain popularity and although I've worked with Mercurial professionally I've yet to see it used anywhere for Open Source development, yet.

        I guess I must be living in my own bubble then. Not that subversion isn't the most dominant version control system out there, it still is I think, but recently I've been using github (which uses git) and google code (which uses Mercurial) most of the time -- and I can see why someone could mistakenly think that github and google code are the only thing there is (after all, who uses sourceforge/tigris anymore? I'm sure some people still do use those repos, but I certainly wouldn't start a new open source pro

      • Re: (Score:2)

        by pthisis ( 27352 )

        Given the vast numbers of CVS repositories that exist and the ease with which you can transition to Subversion, I don't think it's popularity is going to wane any time soon.

        git to CVS transformation and a server that servers git repos to CVS clients exist, too.

        SVN is in a weird place: it's not exactly legacy. There are certainly new projects choosing it. But almost all of those know that it's an intermediate step that'll be out the door in a few years.

        There's 1 major reason to choose SVN over git: better

        • There's 1 major reason to choose SVN over git: better GUI clients.

          I think SVN Apache/DAV integration is much more polished than git's. Things like VisualSVN give you out the box Active Directory integration, with a management interface to boot.

    • Git and Mercurial are more popular than Subversion? That's the big news to me, with all snarkyness aside. I best be getting out of my bubble.

      No shit. Most of my conversations about revision control systems involve whether or not there is any real reason to move from CVS to Subversion. I've used SVN at each of the last few places I've worked, and in my private life, everybody seems to use SVN.

      Git seems to bewilder most people I know. I think part of it may be that most of the repositories I deal with are

    • Re: (Score:2, Informative)

      by Antique Geekmeister ( 740220 )

      Please do. For many corporate purposes Subversion is opular, but its truly awful security models (storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted, and refusal to publish workable configuraitons for purely anonymous access), coupled with its designers absolute refusal to support deleting contents from the repository (even if they're accidentally stored DVD images or copyrighted code) leads to a very harsh conflict between the idea of "source control deletes

      • Re:Git and Mercurial? (Score:5, Insightful)

        by ckaminski ( 82854 ) <slashdot-nospam.darthcoder@com> on Tuesday August 25, 2009 @09:54PM (#29196119) Homepage
        <quote>coupled with its designers absolute refusal to support deleting contents from the repository</quote>

        I don't necessarily disagree with you, but in places I've worked, if we removed code in such a fashion and an audit found out about it, we'd get pummeled. Especially if it was discovered after a public release. It's one thing to ship code copyrighted by someone else, it's something completely different to go about covering up the fact.

        So I'm torn on this "feature."

      • Re:Git and Mercurial? (Score:5, Informative)

        by orzetto ( 545509 ) on Wednesday August 26, 2009 @02:17AM (#29197669)

        [Subversion's] designers absolute refusal to support deleting contents from the repository [is bad]

        That is one great feature of Subversion: absolutely no way to screw up stuff that was committed. Revision control is about keeping track of stuff, any model that allows a user to remove information from a repository is a disaster quietly waiting to happen; sorry you did not understand that.

        If you absolutely need to remove something from a SVN repository, you can do that with svndumpfilter, meaning you have to ask the repository's administrator. That's a good safeguard against accidental deletions.

        "throwing useless things away makes cleaner code"

        For "cleaner code" you just need svn delete.

      • Its not so much a refusal to support full deletion than a problem that the task is difficult - subversion was designed not to delete anything placed in the repository (except as a awkward admin task), and now everyone realises that it is desirable to do this occasionally, they're finding it'll be a hard job to do - so it gets put off until next the major version. Its been put off like this since v1.2 IIRC.

        Google for svn obliterate for the full details, the svn docs has a spec for the work. If you want to wo

      • storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted

        Call me crazy, but exactly how is this insecure? It's the filesystem's job to provide security, hence the access for the directory is 700. Exactly what kind of scenario would an unauthorized person having access to your home folder not already be enough of a security breach so as not to matter? Even then, you can turn off password caching entirely if you want if you're really worried about it (store-password

    • Git and Mercurial are more popular than Subversion? That's the big news to me,

      For more recent projects, hell yes, subversion still has the larger installed base at the moment, but the speed with which git is being adopted is scary.

      After learning git myself though I can see why, it's just a superior system. Even when working with SVN repositories I now use git because of the better functionality.

  • I have experience using rcs and it seemed good enough. Now I'm currently using subversion that someone else set up in the name of progress (not my decision). My problem is it's cluttering up my working directories with meta data, plus I run into consistency problems as I'm moving and merging code from temporary experimental folders and other teams folders that are not in the same repository. All of this was perfectly fine with rcs (I would just check out something, make whatever changes I needed to and chec

    • It sounds like you're manually doing things that svn would rather handle itself - specifically, copy and merge. If you're doing those outside of the tool then you're going to confuse the hell out of the repository, which will in turn do its best to confuse the hell out of you :-)

    • Copying code between repository sounds like a bad idea to begin with - it means that you are losing the history of the files.

      Also the temporary experimental folders should be done with branches. Unfortunately any centralised system sucks at doing branches, compared to git or mercurial.

      Honestly, I think you should spend a few hours learning svn, and then get "git svn" and learn and use that.

    • svn is a vast improvement over rcs and your use case sounds fairly common so I'd guess that you are doing something wrong.

      As a sidenote, terms like 'experimental folders' and 'other teams folders' sound really bad: if your source control was sane you wouldn't need 'experimental folders'... What you really want is a tool that makes branches so cheap you can always create new ones... Any time you need to experiment, you just create a new branch on your local repo (and you can work on the main branch at the sa

    • Re: (Score:2)

      by Jack9 ( 11421 )

      To get a "clean" copy of a directory, use the "Export" command from your local repo. Subversion is nice because it limits the number of commands that you can (and would need to) run but names them as strangely as any other Revision Control System. You do need to produce process for how branching is done.

  • Errata (Score:5, Informative)

    by kabloom ( 755503 ) on Tuesday August 25, 2009 @06:39PM (#29194607) Homepage

    Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.

    This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.

    • Re: (Score:2)

      by kabloom ( 755503 )

      Additionally, he mentions (at the end of the article) that distributed systems have issues with old projects that have long histories as an area for further research. He doesn't discuss bzr, which has a SVN-like mode for working with repositories when an overly-large history size is a real issue. He also doesn't discuss git clone --depth which may help with such issues. The git documentation is overly conservative when describing what you can do with a depth-limited repository -- there are plenty of conditi

    • Re:Errata (Score:4, Insightful)

      by forkazoo ( 138186 ) <wrosecrans AT gmail DOT com> on Tuesday August 25, 2009 @06:54PM (#29194763) Homepage

      This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.

      Yes and no. It is possible to only update/checkin at a certain level in the directory hierarchy, and miss a change to a header outside of the scope you are interested in. You have to be slightly beligerent to get into such a situation, but it can happen.

      • Re: (Score:2)

        by kabloom ( 755503 )

        I guess I misunderstood. He must have been talking about the project standpoint where alice updates foo.c and bob updates bar.c. I don't think they have to see each other's changes to commit. But if they touch the same file, even though their changes don't textually conflict, then they do have to see each other's changes.

  • No they don't. (Score:5, Informative)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Tuesday August 25, 2009 @06:42PM (#29194623) Journal

    Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works.

    Ok, yes, some tools do. For example, subversion supports trivial branching, but sucks at merging, so it encourages people to work on a common "trunk" branch. It also only supports a central server, so it "encourages" developing with a central server.

    Git, on the other hand, "encourages" people to not put multi-gigabyte files in version control.

    However, Git can be used to talk to an SVN repository. It can also talk to a central repository, or work purely via ssh between workstations, or with something like Gitjour, in a truly distributed fashion. Github is a strange and wonderful mutation of the two.

    Perhaps, by making branches and merges so awesomely fast, Git "encourages" lots of little local branches, and keeping a neat patch history. But to sum it up:

    SVN can handle large binary files and Windows better than Git, and is better integrated into IDEs.

    Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.

    • Re:No they don't. (Score:5, Interesting)

      by russotto ( 537200 ) on Tuesday August 25, 2009 @06:58PM (#29194803) Journal

      Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.

      When I first looked at git, it wasn't even clear how simple revision control tasks could be done, e.g. simply checking in a file, or reverting changes to it. Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things (and it's not just because it's distributed, as mercurial was much more straightforward). I assume that's changed as people aside from Linus actually use the thing, but it was very off-putting in the beginning.

      • Re:No they don't. (Score:5, Informative)

        by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Tuesday August 25, 2009 @09:40PM (#29196037) Journal

        It has changed, somewhat -- but mostly, I think there's just better documentation.

        But, for example...

        Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things

        That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?

        Generally, you learn to use relative terms, instead -- for example, HEAD^ to refer to the revision just behind HEAD.

        mercurial was much more straightforward

        I thought so, too...

        I think I tried mercurial, and then bzr, and eventually settled on Git for three reasons:

        1. It's obscenely fast
        2. Everyone's doing it, which has a network effect (github)
        3. I can hold its data model comfortably in my head.

        I should clarify that last part... Maybe some things are cryptic, and I'm sure I don't know all of the possible commands I could run -- but at a very basic level, I know exactly what's going on, just like I did in SVN.

        Just for fun, here's the data model in a paragraph: There are commits. Each commit has a parent commit that it includes, except for merges, which have two parents. A branch is just a pointer to a commit.

        That's it.

        And knowing that, everything else starts to make sense... but it's more than I want to get into in a Slashdot post.

        • That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?

          Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?

          To me, it would make more sense if there was an incremental part to a git changelist id, even if it was "number of seconds since 2000" or something else unreadable, as long as you could ask someone "which revision crashed" and get back an answer you could easily use to tell if they were up-to-date or miles out of date.

          • Re: (Score:3, Informative)

            by PeterBrett ( 780946 )

            Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?

            You may wish to investigate the git describe command. For example:

            [peter@harrington git (master)]$ git describe
            v1.6.3.2-225-gb836490

            The output contains the latest annotated tag, the number of commits since that tag, and the first 7 hex digits of the current commit hash prefixed by a "g". All the information you need to quickly or precisely identify a revision.

            Documentation is here [kernel.org].

          • Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer?

            No, but I could tell with a quick 'git log' of each.

            Can you tell me when I would ever, ever need this? I never look at revision numbers outside of a log anyway. The last time I can remember caring what those numbers were, or holding them in my head for longer than a copy/paste (if that), is when I had to manually feed revision numbers into 'svn merge'.

            Well, guess what? 'git merge' is smart enough to not need that. The "merge tracking" feature of SVN that's supposed to give it similar functionality also slow

        • Re: (Score:2)

          by wrook ( 134116 )

          This is a stupid "me too" post, but hopefully it will lend credence to what you say.

          I originally used SVN because at the time there weren't any other credible options. I moved to bzr because I wanted distributed version control and bzr's syntax seemed easier than Git. Now I'm in the processes of moving over to Git. Git's documentation has vastly improved and that's a big reason for my change. I can't even really understand why I thought it was more difficult than bzr now. I also think that if people tr

          • The SHA1 hashes may look scary at first, but it really is the best approach.

            This is the only thing I'm not sure I agree with -- SHA1 is kind of weak by now, and it was already old-ish when Git was written.

            But I definitely agree on that much -- I prefer a globally unique number (though maybe a GUID would be better?) to a kludgy attempt at preserving revision numbers.

            There was actually another reason I preferred bzr -- it's written in Python. Git is written in C, Bash, and Perl, which means a lot steeper of a learning curve if I were to ever hack on it. But I'm starting to realize I'

  • "More Popular"? (Score:3, Insightful)

    by adamkennedy ( 121032 ) <adamk@c[ ].org ['pan' in gap]> on Tuesday August 25, 2009 @06:52PM (#29194733) Homepage

    > Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial.

    I think you might be confusing Internet "buzz" with popularity.

  • TortoiseSVN (Score:4, Insightful)

    by ImustDIE ( 689509 ) on Tuesday August 25, 2009 @06:59PM (#29194807)

    I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.

    I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.

    There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.

    • I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.

      I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.

      There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.

      Tortoise is also cross-platform, for when that's important. And there's even TortoiseCVS, if that's your style.

      • Re: (Score:2)

        by N7DR ( 536428 )

        Tortoise is also cross-platform, for when that's important.

        I beg to differ.

        From http://tortoisesvn.net/node/58 [tortoisesvn.net]:
        TortoiseSVN is only available on Windows.

        That page lists clients similar to tortoise for other OSes, but the real, genuine tortoiseSVN is Windows-only.

    • Re: (Score:2)

      by IMightB ( 533307 )

      I work for a company which switched from CVS->gnuarch->Mercurial (For the gnuarch, switch it was when we were small and the lone diva developer made the decision for us) (For the mercurial (Hg) switch we evaluated SVN, Git and a few others before settling on mercurial)

      Hg has made merging a dream, and everything else is really easy. The biggest headache from the dev's was for a period of about two weeks where they had issues with the extra "Push" step.

      I believe that Netbeans and Eclipse have Hg plugi

    • even if your company uses a central SVN repo, you can still use git yourself, 'man git-svn' it allows you basically all of the advantages of git without any svn users even knowing that you're using it.

      When you get used to the workflow you'll wonder how people ever used svn.

      • Re: (Score:2)

        by Gr8Apes ( 679165 )

        When you get used to the workflow you'll wonder how people ever used svn.

        No they won't - SVN pretty much sucks all around. There'll be no wonder if Git's actually better. I've considered looking over Bazaar and AccuRev, but the latter costs too much, and I ran out of time for the former.

    • Re: (Score:3, Informative)

      by Lally Singh ( 3427 )

      Ugh, I can't stand Tortoise. It just *kills* the speed of my file-open/save dialogs. In exchange for a few labels (and not in visual studio! just the explorer) and right-click commands (hint: a menu and some dialog boxes do not constitute a GUI) I literally go get coffee when the dialog box is loading my checked-out repo.

      psvn.el for Emacs, however, is an absolute dream. I see my repo (or subfolder thereof) as one dired-like list. diff, checkin/update, etc. are live and just update my buffer.

  • how about the tps report system for each change the PHB makes a big fuss about it when you don't do them and gets on your ass when you take the time to do them and your other work fail behind when you take the time to do them.

  • No mention of ClearCase? (Score:4, Informative)

    by gillbates ( 106458 ) on Tuesday August 25, 2009 @08:39PM (#29195587) Homepage Journal

    What I find interesting is there's no mention of ClearCase. Maybe the author is unaware of it, or considers it obsolete? Then again, the author didn't seem that experienced with the debacles into which one can get with revision control SW. The example he posits is the least of the problems which can crop up.

    I've used both ClearCase and CVS. First, CVS:

    1. I instinctively save files. And this is a bad thing to do with CVS; when I do a commit, my otherwise unchanged file can overwrite another engineer's more recent changes because I happened to save the file at a later date than him. The interesting thing is that this is not immediately apparent to either of us until we check out a fresh copy of the repository and he notices his changes are gone. And then I'm listed as the last modifier, and he comes to me...
    2. You can't (or shouldn't) copy one directory to another within a source tree. Nor should you do it between repositories. CVS will commit your changes to the copied directory back to the original repository, unless you delete all of the CVS folders. This little quirk cost a few of my colleagues a few hours of debugging to figure out why their changes kept disappearing...
    3. CVS does not (or did not when I used it) enforce strict version control protocol. I can commit an entire repository back to mainline even if I have outdated files. Even if others have made more recent updates. I didn't know this was happening for a good few months of use...

    Now for ClearCase

    1. ClearCase can manage extraordinarily large codebases spread across several geographical locations.
    2. It can be integrated with version control and bug tracking databases.
    3. It allows two or more developers to work on the same file at the same time, with the last one to commit having to perform a manual merge *only when there are conflicts*. Most of the time, it gets the merges right.
    4. With proper tagging procedures, I can always reproduce the last build bit-exact. No matter how badly an engineer subsequently mangles the codebase, I can always build from the last tag. My impending release can't be sabotaged by another developer committing code-breaking-but-it-compiles-on-my-machine-oh-silly-me-I-forgot-the-headers kind of changes.
    5. It does have problems with cache-coherency. Modifying files on machines other than the build machine may end up with stale files being linked...
    6. It has dynamic views, which don't require a full copy of the source tree on the local machine. There are some big advantages to this, among them being not having to worry so much about the theft of a developer's laptop, and using the server's storage pool for building, rather than the local hard disk. From a developer perspective, it is nice not to have to wait an hour or so for the repository download should I need to make a change to an older codebase. I can work on multiple versions of the same code base at the same time, without having to maintain a separate local copy of the entire tree for each of them.
    7. Managing ClearCase is an administrative position. Yes, it is exceedingly complex.
    8. Suppose I merge several bug fixes for a build. And later, one of those fixes needs to be backed out (didn't fix the problem, conflicts with other SW, etc...). I can do that with ClearCase rather easily, without having to reconstruct all of the interim versions between the two.
    9. I can apply the same bugfix to two different branches of a source tree without checking out and modifying both branches. That is, I can check the changes into one branch, and merge them into another branch (or just pick them up) without having to checkout the repository from the other branch.

    Now, granted, a lot of FOSS products are not trying to be SEI level 5*. They don't have to demonstrate a repeatable process. The often don't incorporate bug fixes into older releases, or maintain several concurrent branches of the same codebase. It is also important to show which

    • Essentially everyone who knows anything about modern version control considers CVS obsolete. Many of the things you discuss in your comment were considered, discussed, and resolved years ago, though different systems went about solving them in different ways.

      SVN is essentially CVS with most of the annoying problems fixed, and several other advantages besides. Most other systems are completely different. There are even many people who consider any version control that isn't distributed to be obsolete.

      It's ra

      • Re:No mention of ClearCase? (Score:4, Insightful)

        by ztransform ( 929641 ) on Wednesday August 26, 2009 @05:35AM (#29198893)

        Essentially everyone who knows anything about modern version control considers CVS obsolete.

        Clarification: everyone who thinks they know everything about modern version control considers CVS obsolete.

        CVS still has advantages, in my opinion:
        - simple underlying storage structure that any administrator can understand
        - ability to simply administratively repair obscene or damaging check ins (investigate the cvs admin -o command, few other version control systems can do this)
        - simple file numbering scheme

        At the end of the day your needs may be more complex (regular branching, regular directory moves, etc) but in some commercial situations simplicity and ease of administration can be valuable points (and I think often outweighs the perceived benefits of SVN).

        As for Git with it's advanced learning curve of at least a week, sometimes you have not just programmers contributing to a project but front-end designers, template producers, who have never seen a version control system in their life. Subjecting them to Git can be both cruel and potentially uneconomic - particularly if they are all on short term contracts.

    • Re:No mention of ClearCase? (Score:4, Insightful)

      by Ztream ( 584474 ) on Wednesday August 26, 2009 @01:02AM (#29197235)

      I use Subversion on a daily basis, and I believe everything positive you said about ClearCase holds true for Subversion, except point 9. There are some philosophical objections to 9 (you should test the resulting code before committing it anyway), but I don't know if it's a design decision or a missing feature.

      That's not to say that Subversion doesn't have problems of its own though, but using CVS as a representation of the state of version control systems is like judging proprietary software on the basis of Windows 95.

    • Re: (Score:2)

      by wrook ( 134116 )

      Git an Mercurial are fundamentally different from the others you mentioned. They are distributed version control systems. You are free to set up your own topologies and methods for synchronizing. The biggest disadvantage is in not being able to easily checkout partial trees. This affects your workflow. IMHO, it results in a better workflow since you are forced to decouple the release of separate projects. But I'm sure I would get some stiff arguments from some people on that point. (My main argument i

  • Clearcase. (Score:3, Insightful)

    by Ungrounded Lightning ( 62228 ) on Tuesday August 25, 2009 @08:44PM (#29195633) Journal

    I've only tried a few revision control systems.

    Of those I've tried, Clearcase is the hands-down winner function-wise, especially for the diverge-converge model of multi-programmer development.

    Extremely lightweight branching. "View spec" - a little language to specify exactly what version of what you want: (Version x.y.z but override by the foobar feature development branch but override that by anything in /src/garble as of Tuesday at 3:15PM but override all with anything I've got checked out in MY development branch...). Integration into the filesystem so your tools "see" containing just what version of the sources you specified. A make variant that imports already-built objects that some OTHER developer made from the equivalent sources, rather than compiling them again, etc.

    Downside: It's commercial and 'way pricey.

    But if you're a commercial shop you should at least evaluate it. The functionality is fansastic.

    (I hear some of the core functionality came from an open-sourced student project. I've often wondered why there isn't a FOSS clone of the important features - or if there is and I just missed it.)

  • Savana - transactional workspaces on top of SVN (Score:4, Interesting)

    by SashaMan ( 263632 ) on Tuesday August 25, 2009 @10:35PM (#29196377)

    Friends of mine have open-sourced savana, http://savana.codehaus.org/ [codehaus.org] a thin layer on top of Subversion that makes it easy to do all work in private branches before promoting to the trunk. A common workflow is:

    sav createuserbranch mybranch --calls svn copy under the covers to create user branch named mybranch ... normal checkins using svn commit go to YOUR private branch ... when you are ready to promote your changes back to the trunk:
    sav sync -- pulls in any changes made to trunk since your private branch was created so you can test locally
    sav promote -- merges your changes back into the trunk

    The thing I like about this thin "workspace managing" layer on top of Subversion is that for the most part you can take advantage of existing tool support for subversion (like integrated IntelliJ Idea and Eclipse support), as all of the savana commands just call svn commands under the covers.

Slashdot Top Deals

If all else fails, lower your standards.

Close