Ruby projects and interfaces to revision control systems (Darcs vs.Cogito)

[Alan Garrison]

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

 

[M. Edward (Ed) Borasky]

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.

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

 

[James Edward Gray II]

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.

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

James Edward Gray II

 

[Alan Garrison]

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.

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 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.

 

[Tom Copeland]

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

 

[Alan Garrison]

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

Err, make that 'SVN'.

 

[Chad Perrin]

* Cogito's core is basically a bunch of shell scripts (ewww 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.

 

[Ollivier Robert]

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,

 

[Kirk Haines]

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 Haines

 

[Alan Garrison]

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,

Ah, yet another option to explore

 

[Ross Bamford]

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...

 

[M. Edward (Ed) Borasky]

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.

Alan Garrison 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,

 

[James Edward Gray II]

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 Gray II

 

[Chad Perrin]

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.

Ditto that. The day-to-day uses of svn are quite simple enough to use
from the command line without any frustration.

 

[Gregory Brown]

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.

Same here. Then again, I also use elinks to view the web a lot of the time=

But seriously, if you're comfortable with the shell, to me command
line SVN is easier to deal with than TortoiseSVN which we use in work.

 

[Ollivier Robert]

I just saw Mercurial, it looks cool.... but, why not FastCST? It's
also
distributed, extensible... and written in Ruby

It has not been tested as much as Mercurial, still lacks some important
features (merging for example)... These are important. Sure, I'd love
to see Mercurial in
Ruby but Mercurial is there now and works.

 

[Ollivier Robert]

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.

Trac has now an unofficial Mercurial plug-in so...

<http://projects.edgewall.com/trac/wiki/TracMercurial>