Forum: Ruby Ruby projects and interfaces to revision control systems (Da

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Alan G. (Guest)
on 2006-01-03 16:27
(Received via mailing list)
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 (Guest)
on 2006-01-03 16:56
(Received via mailing list)
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 G. wrote:

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

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
James G. (Guest)
on 2006-01-03 17:10
(Received via mailing list)
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 G. II
Alan G. (Guest)
on 2006-01-03 17:16
(Received via mailing list)
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. :)

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 C. (Guest)
on 2006-01-03 17:17
(Received via mailing list)
> 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/...
l

Yours,

Tom
Alan G. (Guest)
on 2006-01-03 17:20
(Received via mailing list)
Alan G. wrote:
> * SCM appears to be just a marginal improvement to CVS from a functional
> standpoint.

Err, make that 'SVN'.
Chad P. (Guest)
on 2006-01-03 17:26
(Received via mailing list)
On Wed, Jan 04, 2006 at 12:14:19AM +0900, Alan G. 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 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
Ollivier R. (Guest)
on 2006-01-03 18:03
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] http://selenic.com/mercurial/
Kirk H. (Guest)
on 2006-01-03 19:59
(Received via mailing list)
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.
Alan G. (Guest)
on 2006-01-03 19:59
(Received via mailing list)
Ollivier R. wrote:
>
> [1] http://selenic.com/mercurial/
>

Ah, yet another option to explore :)
Bob H. (Guest)
on 2006-01-03 19:59
(Received via mailing list)
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/>
unknown (Guest)
on 2006-01-03 20:00
(Received via mailing list)
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
Alan G. (Guest)
on 2006-01-03 20:00
(Received via mailing list)
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.
Ross B. (Guest)
on 2006-01-03 20:00
(Received via mailing list)
On Tue, 03 Jan 2006 14:54:15 -0000, M. Edward (Ed) Borasky
<removed_email_address@domain.invalid> 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...
Hynek S. (Guest)
on 2006-01-03 20:53
(Received via mailing list)
* Alan G. <removed_email_address@domain.invalid> wrote:

> * "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.
Tom C. (Guest)
on 2006-01-03 20:59
(Received via mailing list)
> 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
mathew (Guest)
on 2006-01-03 21:39
(Received via mailing list)
removed_email_address@domain.invalid 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
Esteban Manchado =?iso-8859-1?Q?Vel=E1zquez?= (Guest)
on 2006-01-03 23:56
(Received via mailing list)
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 :-)
M. Edward (Ed) Borasky (Guest)
on 2006-01-04 04:31
(Received via mailing list)
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

http://linuxcapacityplanning.com
James G. (Guest)
on 2006-01-04 05:46
(Received via mailing list)
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
Chad P. (Guest)
on 2006-01-04 05:49
(Received via mailing list)
On Wed, Jan 04, 2006 at 12:44:11PM +0900, James Edward G. II wrote:
> 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.

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

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

print substr("Just another Perl hacker", 0, -2);
Gregory B. (Guest)
on 2006-01-04 06:34
(Received via mailing list)
On 1/3/06, James Edward G. II <removed_email_address@domain.invalid> wrote:
> 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.

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 R. (Guest)
on 2006-01-04 11:10
Esteban Manchado =?iso-8859-1?Q?Vel=E1zquez?= wrote:
>     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 R. (Guest)
on 2006-01-04 11:12
M. Edward (Ed) Borasky wrote:
> 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>
Christian N. (Guest)
on 2006-01-04 15:34
(Received via mailing list)
"Tom C." <removed_email_address@domain.invalid> writes:

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

Bah, you can just admit you wanted to avoid all that library trouble!
*g*
Tom C. (Guest)
on 2006-01-04 19:12
(Received via mailing list)
On Wed, 2006-01-04 at 22:31 +0900, Christian N. wrote:
>
> Bah, you can just admit you wanted to avoid all that library trouble! *g*

So true!  I did have a bit of a struggle with getting SWIG to the right
version to get ViewVC running with Subversion; descended into RPM
dependency hell there for a bit.  But, it all got sorted out
eventually...

Yours,

Tom
Eero S. (Guest)
on 2006-01-05 00:11
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 4 Jan 2006 01:40:59 +0900, removed_email_address@domain.invalid wrote:
>
> disconnected operation and a number of other things -- among them,
> disconnected operation.
> * monotone: Interesting piece of kit.  Another decentralized SCM;
> named by the hash of their contents.  Also supports "packed"
> * cogito: Shell scripts on top of git which turn it into a real SCM.
>
> * 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?

You missed Mercurial (hg), actually a fairly good one.

One point that may be important to many is that out of the distributed
SCM's that I have tried (git, monotone, bzr, mercurial, darcs), only
darcs supports output to a generic format, XML.

> -mental


E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDvZmNxvA1l6h+MUMRAklhAJ0Vpc+AfcthKiWFHjcxfejxWC7frwCePQDm
pLJbUwwms0BkaCShPrFt0mM=
=aesI
-----END PGP SIGNATURE-----
Chad P. (Guest)
on 2006-01-05 04:27
(Received via mailing list)
On Thu, Jan 05, 2006 at 07:10:14AM +0900, Eero S. wrote:
>
> You missed Mercurial (hg), actually a fairly good one.
>
> One point that may be important to many is that out of the distributed
> SCM's that I have tried (git, monotone, bzr, mercurial, darcs), only
> darcs supports output to a generic format, XML.

On the other hand, I know people who treat XML as a binary format
because though it's actually plain text with markup, the markup is so
dense and difficult to understand when parsing by eye sometimes that it
might as well be nothing but ones and zeroes.

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

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
Jeffrey D. (Guest)
on 2006-01-05 18:44
(Received via mailing list)
2005 seems to have been a really good year for open-source SCMs.  Many
new ones have come out and the others are maturing.  I think it's pretty
exciting.  I really need to make the time to try more out.

I personally think Darcs is a *great* SCM and possibly the best approach
to source control.  You know how Ruby makes your programming easier?  I
think Darcs does that for SCMs.  That's probably the best compliment I
can give to an SCM.  I think the ideas behind Darcs is very elegant.

However, Darcs isn't for all files.  It was mentioned before in this
thread that Darcs isn't so hot dealing with really large files.  I also
found that to be true.  I have never found this to be a problem dealing
with source code, but I ran into it when I tried to put all my email in
a Darcs repository.

I think Darcs' niche is for "not huge" repositories, which is probably
99.9% of all Ruby projects.

One of the beautiful things about Darcs is the working directory and
repository are basically one and the same.  Throw a copy on a pen drive
and do your work on computers where you can't access the main
repository.  Resync by simply pushing or pulling the new patches when
you get back.

At work, I'm planning on setting up a system to use both Darcs and
Subversion.  Subversion is the main repository.  I'll be able to run a
command like "rake darcs" within one of the subprojects that will make a
new Darcs repo with that subproject and all of its dependencies.  Then
I'll be able to take that Darcs repository to the lab downstairs (where
I can't reach the Subversion repository) for testing or to a client's
site.  I can make any changes necessary.  When I get back to my main
development computer, I'll be able to run something like "rake
darcs-import" which will take each changeset (patch) and commit it to
the Subversion repository.

I was really surprised to see a couple of remarks by people saying they
might use Darcs if it wasn't written in Haskell.  That seems like
reasoning people have been using in the past concerning Ruby projects.

While most SCMs seem to be slight variations of each other, Darcs is
quite different, taking a step toward greater simplicity.  I hope Darcs
continues to improve, and that future SCMs might take a look at
exploring this "patch theory" further.

Whoops, I seemed to have slipped off into a rant about how cool Darcs
is.  Sorry about that.  To summarize, I think Darcs is a great SCM to
store your ruby files.

Jeff
Eivind E. (Guest)
on 2006-01-06 13:44
(Received via mailing list)
On 1/5/06, Jeffrey D. <removed_email_address@domain.invalid> wrote:
> I think Darcs' niche is for "not huge" repositories, which is probably
> 99.9% of all Ruby projects.
[...]
> At work, I'm planning on setting up a system to use both Darcs and
> Subversion.  Subversion is the main repository.  I'll be able to run a
> command like "rake darcs" within one of the subprojects that will make a
> new Darcs repo with that subproject and all of its dependencies.  Then
> I'll be able to take that Darcs repository to the lab downstairs (where
> I can't reach the Subversion repository) for testing or to a client's
> site.  I can make any changes necessary.  When I get back to my main
> development computer, I'll be able to run something like "rake
> darcs-import" which will take each changeset (patch) and commit it to
> the Subversion repository.

Note that for really large projects, Subversion (AFAIK) lack
distribution infrastructure.  That's probably the primary reason *BSD
is still with CVS - we distribute the repositories using cvsup.
There's also developer inertia, of course.  I notice that KDE has
actually switched to Subversion, so it's obviously possible to use
with a fairly large scale now.

Eivind.
Chad P. (Guest)
on 2006-01-06 13:47
(Received via mailing list)
On Fri, Jan 06, 2006 at 08:42:55PM +0900, Eivind E. wrote:
>
> Note that for really large projects, Subversion (AFAIK) lack
> distribution infrastructure.  That's probably the primary reason *BSD
> is still with CVS - we distribute the repositories using cvsup.
> There's also developer inertia, of course.  I notice that KDE has
> actually switched to Subversion, so it's obviously possible to use
> with a fairly large scale now.

That's why we have svk -- svn for large distributed projects.

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

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
Hans F. (Guest)
on 2006-01-06 22:34
(Received via mailing list)
Let me join the chorus of darcs evangelists. About a year ago, I think,
I went on a crusade. I was fed up with CVS, and had heard all kinds of
cool things about distributed version control. I liked the theory of
arch, but no way in a million years could I swallow that terrible
interface. SVN I was already familiar with, but I was interested in
distributed version control. Monotone and another that I can't
remember, and darcs all looked to be in about the same place. I read
their websites and docs and decided darcs and I were a pretty good
match, so I gave it a try.

I didn't care that it was written in Haskell, but wouldn't it be rather
hypocritical for this ruby fanatic to toss away a potentially great
program because it was written in an obscure language? I might have
cared if installation were not as simple as apt-get install darcs.

I'm rambling. Let me try and sum it up. To me, darcs is to version
control as Ruby is to programming. It's simple, elegant, powerful, and
easy to pick up by the majority of developers (see the CVS transition
chapter in the docs). It reportedly has scalability issues and speed
issues on large projects, but I've never hit any limitations (this is
similar to ruby itself, also). The distributed paradigm is wonderful, I
can work on projects in several places without worry, I can work on my
laptop when I have no wireless. I am basically freed from the tyranny
of the version control system. Darcs is my friend, not my enemy. It
helps, not hinders. blah blah blah.

Do yourself a favor and give darcs a try. It's probably not the best
SCM for all situations, just as Ruby is probably not the best language
for all situations, but it's my favorite.

Most importantly, try something distributed, and whatever you do don't
use CVS if you can help it.
Jim F. (Guest)
on 2006-01-07 00:01
(Received via mailing list)
On Jan 6, 2006, at 2:33 PM, Hans F. wrote:

> similar to ruby itself, also). The distributed paradigm is
> wonderful, I
> can work on projects in several places without worry, I can work on my
> laptop when I have no wireless. I am basically freed from the tyranny
> of the version control system. Darcs is my friend, not my enemy. It
> helps, not hinders. blah blah blah.

Can an svn expert comment here? I thought the same was doable in svn.

Thanks


Jim
J. Ryan S. (Guest)
on 2006-01-07 00:19
(Received via mailing list)
Simon S. (Guest)
on 2006-01-07 01:46
(Received via mailing list)
On 1/6/06, Jim F. <removed_email_address@domain.invalid> wrote:
> Can an svn expert comment here? I thought the same was doable in svn.
One unfortunatly not do offline commits with svn..  darcs allows this
(afaik).
Anatol P. (Guest)
on 2006-01-07 02:13
(Received via mailing list)
Darcs have no such definition as "commit to repository" because of each
working copy IS repository. So you changing your code and then record
changes in your local repository. Then you could push (send) all you
patched
to any other repository (for example that placed on central server).
Craig D. (Guest)
on 2006-01-07 02:49
(Received via mailing list)
On Jan 6, 2006, at 6:43 PM, Simon S. wrote:

>>> of the version control system. Darcs is my friend, not my enemy. It
>>> helps, not hinders. blah blah blah.
>>
>> Can an svn expert comment here? I thought the same was doable in svn.
>
> One unfortunatly not do offline commits with svn..  darcs allows
> this (afaik).

I'm no svn expert, but I know a little about this topic. While svn
doesn't work this way, svk (http://svk.elixus.org/), which "uses the
svn filesystem," does. Disclaimer: I haven't used it; just know it's
out there.

Regards,
Craig D.
This topic is locked and can not be replied to.