Ruby projects and interfaces to revision control systems (Da

Ruby
1

Our company, which is beginning to use Ruby in production systems, has
been using Darcs[1] for a little while with general success. My
co-worker has even released a preliminary ruby-darcs interface on
RubyForge. However, a few of Darcs bottlenecks have come up and we’ve
also run across the Cogito[2] project. I’ve seen that Darcs has gotten
a fair amount of attention in the overall Rubysphere, but I don’t recall
reading anything about Cogito. From either an ordinary SCM standpoint
for maintaining Ruby projects or using Ruby to interact with the SCM,
has anyone chosen Cogito over Darcs?

[1] http://www.darcs.net/
[2] http://www.kernel.org/pub/software/scm/cogito/README

2

I just took a brief look at the Darcs web site and the Cogito web site.
Given that Darcs is written in Haskell, I’d be inclined to blow it off
out of hand, since I don’t know Haskell.

Cogito claims to be a front-end to git. I don’t know much about git. I
think it’s what the Linux kernel developers use for their source tree as
a replacement for what they used to use, the non-free bitkeeper.

For most purposes, the “big two” open source revision control systems –
CVS and Subversion – are good choices. They are free, widely used and
have wonderful web interfaces. I think Rubyforge uses CVS, so despite
the folks who swear undying love for Subversion and think that anyone
who doesn’t immediately leave CVS for Subversion is missing out on
something wonderful, my choice would be CVS over either Darcs or Cogito.
:slight_smile:

Alan G. wrote:

[1] http://www.darcs.net/
[2] http://www.kernel.org/pub/software/scm/cogito/README

–
M. Edward (Ed) Borasky

3

On Jan 3, 2006, at 8:54 AM, M. Edward (Ed) Borasky wrote:

For most purposes, the “big two” open source revision control
systems – CVS and Subversion – are good choices. They are free,
widely used and have wonderful web interfaces. I think Rubyforge
uses CVS, so despite the folks who swear undying love for
Subversion and think that anyone who doesn’t immediately leave CVS
for Subversion is missing out on something wonderful, my choice
would be CVS over either Darcs or Cogito. :slight_smile:

RubyForge now offers Subversion as well, so another excuse not to
switch bites the dust. :smiley:

James Edward G. II

4

M. Edward (Ed) Borasky wrote:

have wonderful web interfaces. I think Rubyforge uses CVS, so despite
the folks who swear undying love for Subversion and think that anyone
who doesn’t immediately leave CVS for Subversion is missing out on
something wonderful, my choice would be CVS over either Darcs or Cogito. :slight_smile:

I’m not an expert in any of them, but from what I can see:

  • “Plain” CVS lacks more advanced functionality and doesn’t appear to
    have any long term evolution goals (and, from a security standpoint, it
    allegedly has more holes than a HEPA filter (hence OpenBSD’s
    implementation, OpenCVS)).
  • SCM appears to be just a marginal improvement to CVS from a functional
    standpoint.
  • Darcs, while written in Haskell (not being judgemental, just saying
    that it isn’t a common language for most folks), appears to be a much
    more flexible system (despite a few shortcomings that could possibly be
    fixed in the near future).
  • Cogito’s core is basically a bunch of shell scripts (ewww :wink: with
    assorted interfaces, and given the developer base being Linux kernel
    hackers I’d imagine it’s highly functional.

I’d lean towards Darcs for overall use, and I’m sure each of the above
is a perfectly legitimate solution for various individuals. I’m simply
curious as to other Rubyist’s preferences towards the last 2 on the
list.

As always, YMMV.

5

Alan G. wrote:

  • SCM appears to be just a marginal improvement to CVS from a functional
    standpoint.

Err, make that ‘SVN’.

6

I think Rubyforge uses CVS

Yup, we support both Subversion and CVS now, and folks seem to be
choosing svn over CVS in droves:

http://tomcopeland.blogs.com/juniordeveloper/2005/12/subversion_wall.htm
l

Yours,

Tom

7

On Wed, Jan 04, 2006 at 12:14:19AM +0900, Alan G. wrote:

  • Cogito’s core is basically a bunch of shell scripts (ewww :wink: with
    assorted interfaces, and given the developer base being Linux kernel
    hackers I’d imagine it’s highly functional.

This is hearsay, so take it for what it’s worth:

My understanding is that git is an implementation of a very thin slice
of bitkeeper functionality – just the stuff the kernel developers use.
In other words, it seems to be extremely well suited to the kernel
developers’ needs, but probably isn’t an ideal solution for more generl
source/version control tasks.

I could be wrong.

–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]

“Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts.” - Paul Graham

8

Alan G. wrote:

I’d lean towards Darcs for overall use, and I’m sure each of the above
is a perfectly legitimate solution for various individuals. I’m simply
curious as to other Rubyist’s preferences towards the last 2 on the
list.

Please don’t limit yourself to just Darcs and SVN/CVS. Consider your
usage and first choose between a centralised VCS (SVN/CVS) and a
distributed one (Mercurial, Darcs, svk). This first choice will shape
your workflow.

If you choose a distributed one, I’d like to turn you towards
Mercurial[1]. It is written in something easier to play with (Python),
very fast and does not share some of Darcs limitations (like having the
whole tree in memory at commit time).

It has its own of course but I find it very powerful and can handle big
trees such as FreeBSD’s /usr/ports and the Linux kernel.

Cheers,

[1] Mercurial SCM

9

On Tuesday 03 January 2006 9:03 am, Ollivier R. wrote:

If you choose a distributed one, I’d like to turn you towards
Mercurial[1]. It is written in something easier to play with (Python),
very fast and does not share some of Darcs limitations (like having the
whole tree in memory at commit time).

I’m just a fledgling user, slowly converting my projects to use
Mercurial, but
so far I have found it to work quite well for those things that I need.

Kirk H.

10

On Jan 3, 2006, at 9:26 AM, Alan G. wrote:

Our company, which is beginning to use Ruby in production systems,
has been using Darcs[1] for a little while with general success.
My co-worker has even released a preliminary ruby-darcs interface
on RubyForge. However, a few of Darcs bottlenecks have come up and
we’ve also run across the Cogito[2] project. I’ve seen that Darcs
has gotten a fair amount of attention in the overall Rubysphere,
but I don’t recall reading anything about Cogito. From either an
ordinary SCM standpoint for maintaining Ruby projects or using Ruby
to interact with the SCM, has anyone chosen Cogito over Darcs?

This is tough (I’m going through this process myself right now).
Basically I think the non-commercial contenders are CVS, SVN and
darcs. I can’t see how someone would go with CVS given SVN (we use
CVS for historical reasons only and want to move to something
better). SVN is a modern CVS and I don’t mean that as a slight. Darcs
is different. It is based on a very nice theory of change sets. It is
really easy to use and trouble shoot. Written in haskell – this is
no negative from my point of view, and really, who mucks about with
their source control system so who cares what it is written in?
Cognito… git… why? I can’t think of a single reason (unless you
are working on the linux kernel).

SVN is probably the conservative choice. Darcs might well be the
right choice.

Cheers,
Bob

Bob H. – blogs at <http://www.recursive.ca/
hutch/>
Recursive Design Inc. – http://www.recursive.ca/
Raconteur – http://www.raconteur.info/
xampl for Ruby – http://rubyforge.org/projects/xampl/

11

Ollivier R. wrote:

[1] Mercurial SCM

Ah, yet another option to explore :slight_smile:

12

Bob H. wrote:

Cognito… git… why? I can’t think of
a single reason (unless you are working on the linux kernel).

There’s a shall-not-be-named open source PHP-based project that we’re
trying to make patches to to contribute back – unfortunately due to the
overly-engineered size, inconsistency of source formatting, and other
factors doing complicated patches breaks Darcs on some occasions (said
PHP source quality could politely described as an “unholy demon
abortion”).

The git/cogito option is being explored only for this particular
circumstance, but I thought I’d get some Rubyist’s opinions on it for
general purpose use.

Thanks for the feedback everyone, very informative.

13

On Tue, 03 Jan 2006 14:54:15 -0000, M. Edward (Ed) Borasky
[email protected] wrote:

Cogito claims to be a front-end to git. I don’t know much about git. I
think it’s what the Linux kernel developers use for their source tree as
a replacement for what they used to use, the non-free bitkeeper.

Git looks actually pretty cool, though it’s not really a full SCM, but
AIUI more like a transactional filesystem with versioning built in. I
read
recently (this month’s Linux Magazine) about some ongoing problems with
Cogito (can’t remember what exactly) and made a little note at the time
to
look into using Ruby with Git. I imagine one could do some deeply
interesting things with the two if you could get them to talk…

14

It’s lunch time, so here are my own (very opinionated) thoughts on
the matter:

  • CVS: As a large project maintainer, I’ve come to hate it. It does
    “enough”, but then falls down in places like commit atomicity.
    Trying to isolate a commit by bracketing timestamps isn’t fun.
    Multiple merges to a branch are also so painful that branches
    should be considered “single-use”. No disconnected operation.

Verdict: You’d have to be insane.

  • SVN: Unambitious, but solid. Clean. Tries to fix the things
    wrong with CVS. Succeeds, mostly. Unfortunately, merging with
    branches is even worse than with CVS in the sense that you’ve got
    to manually grovel through logs to find merge points. No
    disconnected operation.

Verdict: Not bad. A reasonable choice for most centralized
projects.

  • SVK: Uses SVN repositories, mirroring them locally. Adds
    disconnected operation and a number of other things – among them,
    ‘svk smerge’, which is the branch merge SVN should have had.
    Written in Perl. A bit slow occasionally.

Verdict: Decent. I use it for the SVN-hosted projects I
participate in.

  • arch: I’ve admittedly been a bit put off by the weird file naming
    conventions. Mister SCM, stay out of my project’s namespace,
    thanks. But it does the things you want an SCM to do. Focuses on
    the whole “distributed development” thing, and of course supports
    disconnected operation.

Verdict: Probably good, but I can’t bring myself to use it.

  • Bazaar: Frontend to arch repositories, if I understand correctly.
    I think it’s supposed to be the next-generation arch. Also, Bazaar
    NG is the next-generation Bazaar.

Verdict: Probably great, but I’ve got no experience whatsoever with
it.

  • monotone: Interesting piece of kit. Another decentralized SCM;
    repositories are .db files containing records of “facts”.
    Conceptually, a content-addressable filesystem. Emphasis on
    digital signatures. Configuration file is a lua script which is
    both good and bad. Was maturing rapidly until one of the core
    developers had to leave because his employer used certain software.

Verdict: Good, used it for a while but moved on.

  • git: A fairly raw content-addressable transactional filesystem;
    objects and metadata are stored in a .git directory, gzipped and
    named by the hash of their contents. Also supports “packed”
    repositories, with files containing blobs of deltas. V. nice
    because you can easily throw repositories around with rsync, HTTP,
    etc. Provides tools for performing transactions in a working
    directory, and cloning repositories. It isn’t really a complete
    SCM in the traditional sense, though you could use it that way if
    you’re determined.

Verdict: Great if you’re Linus and/or trying to work around (for
example) some SCM-related no-compete clause.

  • cogito: Shell scripts on top of git which turn it into a real SCM.
    Works nicely; takes advantage of the benefits of git, and adds
    quite a lot of usability. You still occasionally have to dip into
    a raw git command here or there, but things go pretty smoothly
    nonetheless. Not as nice about renaming directories as some modern
    SCMs. Nice in that the SCM metadata directory is hidden, so you’ve
    not got an “MT” or a “CVS” or whatever directory staring you in the
    face. You can glob with impunity.

Verdict: Very good. I use it for all my writing, art, and personal
software projects.

  • Darcs: Repository is a _darcs directory containing a pristine
    snapshot of the tree and a bunch of patches. Darcs is based on a
    formal approach to performing operations on patches. Favorite of
    Haskellites for many reasons.

Verdict: Good, possibly very good. Not used it much though; Cogito
fills the void for me.

Have I missed any?

-mental

15

Here’s missing one important point: While SVN ist generally
much friendlier then CVS, it’s also more fragile. Especially
the BerkeleyDB-backend should be avoided at any cost as
berkdb is fragile on its own.

Yup, I’ve heard that too. All RubyForge svn backends are using fsfs; I
even compiled Svn --without-berkeley-db just to avoid any possibility of
using that…

Yours,

Tom

16

[email protected] wrote:

It’s lunch time, so here are my own (very opinionated) thoughts on
the matter:

Well, if we’re doing opinions:

CVS: Works well if you’re a development team of 1 person with good
connectivity to your CVS server. Not a good idea for large teams,
distributed teams, or large projects.

SVN: Used to be an absolute PITA to get working, because it relied on
WebDAV & Apache2. I instinctively dislike anything which keeps all your
code in a weird binary format, which was also a problem with SVN at
first. If I were going to use it (which I might), I’d go with the flat
file back-end and dedicated SVN server.

Arch: Does all the back-end stuff right. Keeps your source in its
original format, keeps releases and diffs as .tar.gz, and so on. Was
severaly broken for a long time, in that it choked on filenames with
spaces in. That was fixed, and I gave it a try, but unfortunately the
command line UI is truly horrendous. I used it for a while, then gave up
because it was too hard to work out how to do anything, even with cheat
sheets.

Monotone: Does the right thing for a very open and distributed project,
where security is an issue. Probably overkill if you know and trust all
your developers, though.

Bazaar: A fork of Arch that attempted to fix the UI hideousness. Dead,
according to the FAQ on the Bazaar-NG pages.

Bazaar-NG: The back-end of Arch with the UI of SVN. Probably pretty
good, therefore. Bad experiences with getting Python working in the past
put me off a little.

git, cogito: A crude hack thrown together because Linus made the stupid
decision to put all Linux’s code in a proprietary RCS (BitKeeper), the
owner of the proprietary RCS threw a hissy fit when people tried to make
open source clients interoperable with it, and suddenly nobody could get
a free license for the client any more. Assembled from shell scripts,
which alone should be enough to convince anyone to stay far away.

Darcs: Looks good. I’d probably use it if it was in a more mainstream
language.

mathew

17

On Wed, Jan 04, 2006 at 01:11:56AM +0900, Kirk H. wrote:

On Tuesday 03 January 2006 9:03 am, Ollivier R. wrote:

If you choose a distributed one, I’d like to turn you towards
Mercurial[1]. It is written in something easier to play with (Python),
very fast and does not share some of Darcs limitations (like having the
whole tree in memory at commit time).

I’m just a fledgling user, slowly converting my projects to use Mercurial, but
so far I have found it to work quite well for those things that I need.

I just saw Mercurial, it looks cool.... but, why not FastCST? It's

also
distributed, extensible… and written in Ruby :slight_smile:

18
  • “Plain” CVS lacks more advanced functionality and doesn’t appear to
    have any long term evolution goals (and, from a security standpoint,
    it allegedly has more holes than a HEPA filter (hence OpenBSD’s
    implementation, OpenCVS)).
  • SVN[1] appears to be just a marginal improvement to CVS from a
    functional standpoint.

Here’s missing one important point: While SVN ist generally much
friendlier then CVS, it’s also more fragile. Especially the
BerkeleyDB-backend should be avoided at any cost as berkdb is fragile on
its own. I had two FUBARs in the last monts which made me switch to the
fsfs-backend in the end.

OTOH CVS is rock-solid (in terms of data-security) as fs-based, thus you
can get to your files in any case.

  • Darcs, while written in Haskell (not being judgemental, just saying
    that it isn’t a common language for most folks), appears to be a much
    more flexible system (despite a few shortcomings that could possibly
    be fixed in the near future).

Darcs’ biggest shortcomming is arguably its performance when merging
“really big stuff”[tm] and I’m afraid that there won’t be substantial
improvement in the near future. Nevertheless it’s the friendliest (free)
distributed SCM I’ve met until now.

19

IIRC the Xen project (virtualizer) uses Mercurial, so they would be a
good reference.

The workflow comment is a valid one. My guess is that there aren’t a
whole lot of people who use SVN and CVS without some kind of software
project management wrapper any more. One such system that seems popular
is Trac.

Ollivier R. wrote:

Please don’t limit yourself to just Darcs and SVN/CVS. Consider your
trees such as FreeBSD’s /usr/ports and the Linux kernel.

Cheers,

[1] http://selenic.com/mercurial/

–
M. Edward (Ed) Borasky

20

On Jan 3, 2006, at 8:30 PM, M. Edward (Ed) Borasky wrote:

My guess is that there aren’t a whole lot of people who use SVN and
CVS without some kind of software project management wrapper any more.

Can’t speak for “everyone”, but I use SVN daily straight from the
shell. Sometimes I’ll do a simple add or commit from my editor, but
it’s just a very thin wrapper over the shell.

I use CVS the same way regularly and there’s no editor wrapper for
that. I’ve almost got the last of these legacy projects converted
now though.

One of my clients does make use of Trac though, so I interact with it
regularly too. It’s a nice tool, but I find Subversion very usable
right out of the box.

YMMV.

James Edward G. II