Michael Neumann wrote:
Hi all,
Is there anyone interested in joining a project that aims at creating a
Monotone (www.venge.net/monotone) inspired distributed configuration
management system in Ruby?
Major goal is clean and understandable code, good abstractions and high code
quality, from which further ideas could be implemented more easily than is
the case for Monotone (at least for me).
Ultimate goal of course is the switch from CVS to RCM for the development of
the ruby interpreter 
Hi Avi,
This wouldn't make any sense for the development of the interpreter,
but for library level code, it would be interesting to consider a
Ruby-specific approach: rather than model a file in terms of lines of
text, model it as Ruby class and method definitions, and do all of the
merging and diffing based on that. What you lose is any ability to
version other kinds of code, like associated C or YAML files. But you
gain a much simpler and cleaner model (almost all of the hard, annoying
problems when writing an SCM have to do with textual diffs; take that
away and you're left with the fun conceptual part), and a much
friendlier tool to use: spurious merge conflicts become a thing of the
past; you can autogenerate meaningful, detailed changelogs; you can
properly track changes that a traditional SCM would never notice
(forget file renaming, think about moving a single method or class
between two files...).
The core of RCM would allow this kind of SCM as it knows nothing about files, only entities and their names. In the case of files, the name would be the file name, and the entity the content of the file. But in the same way, you could version classes and methods.
BTW, a had a similar idea some time ago, but then realized, that in Java or Smalltalk (where you already store classes/methods in the image), this is easy, but how would you version this Ruby source code:
class A
attr_accessor :a, :b
eval %{
...
}
end
Ruby is simply too dynamic
And I'm not sure whether I'd like to store:
def a
@a
end
def a=(v)
@a = v
end
instead of attr_accessor :a, :b
Smalltalk evaluates those things only once, and then the original code that generated those methods is gone.
Or how would you split this file as methods, classes etc.?
class A
attr_accessor :a
def b
end
C = 4
end
You can't simply reorder the statements inside the class!
This is the approach we took when building the Monticello version
control system for Squeak. The first version, which is currently in
widespread use (hundreds of packages and several large commercial
projects), has a very similar design to monotone (unfortunately we
hadn't seen monotone yet when we wrote it, and so didn't think to use
public key crypto the way monotone does, which is too bad because it's
a very cool idea). The second version, which is only now nearing
usability, is much closer to Bram Cohen's Codeville - which has turned
out to be a great model in terms of code elegance and potential
flexibility, although we've yet to see how it works out in real-world
use.
Do you know if Codeville is usable for C code? Or is a very regular object structure (packages, classes, methods) required?
Of course it's easier to take this approach for Smalltalk (which
already has a method-level IDE) than it would be for Ruby, but since
the SCM only needs to "understand" Ruby code at about the same level as
RDoc, it shouldn't be all that bad either.
I fear, we'd loose some kind of dynamism. Another approach is of course, to store diffs with knowledge of Ruby's syntax. Sure, you're approach would be much more elegant.
I don't really expect people to jump on this bandwagon - I realize that
part of the appeal of Ruby over Smalltalk is that it lives firmly in
the world of text files, and this would take it slightly away from
that. But I thought I'd give it a shot anyway. 
Thanks for sharing those ideas with us.
Regards,
Michael
···
avi.bryant@gmail.com wrote:
