Want to stay on top? Ruby Weekly is a once-weekly e-mail newsletter covering the latest Ruby and Rails news.
     Feed Icon

Amp: A Revolution in Source Version Control (in Ruby!)

By Peter Cooper / November 27, 2009

amp.png Amp is a new Ruby based project that aims to "change the way we approach VCS" (version control systems). Currently it's basically a port of the Mercurial version control system - a common alternative to the Git system that's more popular in Rubyland - but it aims to abstract things to the point where it could be used in place of Git, Bazaar, SVN, CVS, Darcs, and so forth.

The creators of Amp believe that while there are lots of great repository formats out there, none of the official clients are "truly good software" and so they're aiming to build something that abstracts away all of the pain into a heavily customizable Ruby library and client. Even now you can add your own commands to Amp or adjust those that already exist, meaning you can totally customize a powerful source control tool to your own taste.

One of the points that's constantly stressed on Amp's rather well designed official site is that the project is actively looking for new contributors and help. They have a repo on GitHub if you want to fork and issue pull requests, as well as an IRC channel on Freenode, #amp.

caliper-logo.png[ad] Find duplication, code smells, complex code and more in your Ruby code with Caliper! The metrics are free and setup takes just one click. Get started!

Comments

  1. seydar says:

    Hey

    Thanks for the post! However, we actually would prefer people to fork from the bitbucket repository (http://bitbucket.org/carbonica/amp) instead of the github repo.

    Thanks,
    Ari Brown / seydar

  2. kenny says:

    so pointless

  3. AW says:

    Shorter version of Amp's description: multi-VCS scripting language.

  4. Stuart Ellis says:

    I hope that this project does well. Git is an incredible piece of technology, and I don't want to go back to Subversion, but I do feel that we lost some things in the transition. Git is built by UNIX hackers for hackers, and that approach runs all the way through from the architecture to the rather bare-metal interfaces, so graphical tools built specifically for Git are probably always going to be what John Gruber calls spray-on usability - http://daringfireball.net/2004/04/spray_on_usability

  5. Jack says:

    On Ubuntu Karmic Koala, I get the following:

    extconf.rb:22: libz2 not found (RuntimeError)

    when installing the gem. However, no libz2 is available via apt.

    Is this tied to Mac currently?

  6. Ashley Moran says:

    I don't see the point of re-implementing every existing VCS. The only marginal one I can see is darcs, as attempting an OO implementation of it's patch engine may produce some useful knowledge (largely as documentation of its patch algebra). But even that is hard to sell without a more compelling reason. Isn't this a huge duplication of effort?

  7. seydar says:

    @Jack - there is already a bug posted on the lighthouse tracker and we are working to fix it.

    @Ashley - have you ever wanted to extend a VCS? Use it from Ruby? Also, there is s0 much to learn by writing Amp. Amp isn't about just duplicating effort. The duplication part, really, was to bring us up to speed with the implementation. The real purpose is in going beyond.

  8. seydar says:

    Also, our IRC channel is #amp-vcs (still on irc.freenode.net), if anyone cares.

  9. JB says:

    @seydar: we do care...don't let naysayers get you down. ;)

  10. Brandon says:

    "Currently it's basically a port of the Mercurial version control system - a common alternative to the Git system that's more popular in Rubyland"

    Are you kidding!? Git is far more popular in Ruby land than Mercurial. I'm not knocking Mercurial, but I really doubt it comes anywhere close to Git in popularity. SVN (as much as its users don't want to admit it) might surpass Git's popularity, but not Mercurial.

  11. Peter Cooper says:

    Brandon, you've highlighted the ambiguity in my phrasing, but it means the opposite ;-)

    I could change "a common alternative to the Git system that's more popular in Rubyland" to
    "a common alternative to Git, a more popular system in Rubyland". But basically I'm saying Git is more popular in Rubyland.

Other Posts to Enjoy

Twitter Mentions