[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

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

Alan Garrison

1/3/2006 2:26:00 PM

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....
[2] http://www.kernel.org/pub/software/scm/cog...


--
Alan Garrison
Cronosys, LLC <http://www.cronos...
Phone: 216-221-4600 ext 308



30 Answers

M. Edward (Ed) Borasky

1/3/2006 2:54:00 PM

0

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

Alan Garrison 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?
>
>
> [1] http://www....
> [2] http://www.kernel.org/pub/software/scm/cog...
>
>

--
M. Edward (Ed) Borasky

http://linuxcapacitypl...



James Gray

1/3/2006 3:07:00 PM

0

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

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

James Edward Gray II



Alan Garrison

1/3/2006 3:14:00 PM

0

M. Edward (Ed) Borasky wrote:
> 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.

--
Alan Garrison
Cronosys, LLC <http://www.cronos...
Phone: 216-221-4600 ext 308



Tom Copeland

1/3/2006 3:16:00 PM

0

> 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/subversio...
l

Yours,

Tom



Alan Garrison

1/3/2006 3:18:00 PM

0

Alan Garrison wrote:
> * SCM appears to be just a marginal improvement to CVS from a functional
> standpoint.

Err, make that 'SVN'.

--
Alan Garrison
Cronosys, LLC <http://www.cronos...
Phone: 216-221-4600 ext 308



Chad Perrin

1/3/2006 3:24:00 PM

0

On Wed, Jan 04, 2006 at 12:14:19AM +0900, Alan Garrison wrote:
>
> * 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.

--
Chad Perrin [ CCD CopyWrite | http://ccd.ap... ]

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


Ollivier Robert

1/3/2006 4:04:00 PM

0

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,
-----
[1] http://selenic.com/...

--
Posted via http://www.ruby-....


khaines

1/3/2006 4:12:00 PM

0

On Tuesday 03 January 2006 9:03 am, Ollivier Robert 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 Haines


Alan Garrison

1/3/2006 4:20:00 PM

0

Ollivier Robert wrote:
> 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,
> -----
> [1] http://selenic.com/...
>

Ah, yet another option to explore :)


--
Alan Garrison
Cronosys, LLC <http://www.cronos...
Phone: 216-221-4600 ext 308



MenTaLguY

1/3/2006 4:41:00 PM

0

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