Michael Neumann
6/28/2005 11:12:00 AM
avi.bryant@gmail.com wrote:
> 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