Ruby projects and interfaces to revision control systems (Da

On 1/3/06, James Edward G. II [email protected] 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. :wink:
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.

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);

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 :slight_smile:

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.

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… :slight_smile:

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

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

“Tom C.” [email protected] 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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 4 Jan 2006 01:40:59 +0900, [email protected] 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-----

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

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

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.

On 1/5/06, Jeffrey D. [email protected] 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.

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

http://svnbook.red-bean.com/en/1.1/apas03.html

~ ryan ~

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.

On 1/6/06, Jim F. [email protected] 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).

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.

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