«

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

Or do we want to let Python win the race?

Regards,

Michael

Michael Neumann ha scritto:
> 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
>
> Or do we want to let Python win the race?

have you considered joining forces with Zed Shaw's FastCST?
I don't know what features you're planning to take out from monotone,
but since FCST is based on the idea of plugins to add functionalities, I
imagine you could possibly add them..

Am Monday 27 June 2005 18:35 schrieb gabriele renzi:
> Michael Neumann ha scritto:
> > 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
> >
> > Or do we want to let Python win the race?
>
> have you considered joining forces with Zed Shaw's FastCST?

Yes, I wrote him an email just before writing this.

> I don't know what features you're planning to take out from monotone,
> but since FCST is based on the idea of plugins to add functionalities, I
> imagine you could possibly add them..

Mainly how Monotone works internally. But the plugin idea is definitly an
interesting idea...

Main problem is that it has to be accepted and used by a couple of people.
Using a CM system alone is no fun.

Regards,

Michael

Michael Neumann wrote:

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

I don’t want to poop on your parade, but isn’t the
SCM/RCM/whatevergoddamacbbreviationwereusingtodayforit market kind of
flooded at the moment? What do you hope to bring to it that isn’t
already being brought to you in GNU Arch (1|2|Bazaar(-ng)?), Darcs, git,
and (to a lesser extent) Monotone, subversion, Aegis, svk, cvs, OpenCM,
Perforce, Visual Sourcesafe.

This is another brand of software that everyone sooner or later writes
their own version of, along with text editors, IRC/FTP clients, and
programming languages, yet no one seems to get right,
nikolai

--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Hi Everyone,

Already replied to you (Michael) offline, but thought I'd throw this out
there.

I know I've been totally delinquent in the FastCST development, but I
promise I am actually working on it, just kind of indirectly.

* I'm currently polishing off the Ruby/Odeum code so that I can use it
in FastCST for full text search over code and revisions. This should
replace just about all the tagging and "revisions follow moves" stuff
out there. My recent tests show that this approach just rocks.
* I'm finishing off the CookbooXUL application since I want to provide a
nice XUL based interface to FastCST.
* I'm working on the Linda distributed stuff so that I can include
zero-config setup.
* And I'm doing a libevent binding so...I can do a libevent binding.

Anyway, just thought I'd throw that out so folks don't lose hope.
Anyone who's interested in kicking me in the butt and motivating me to
actually work with them on FastCST should send a swift kick to my e-mail
address.

Zed

On Tue, 2005-06-28 at 01:11 +0900, 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
>
> Or do we want to let Python win the race?
>
> Regards,
>
> Michael
>
>
>

On 6/27/05, Zed A. Shaw <> wrote:
> Anyone who's interested in kicking me in the butt and motivating me to
> actually work with them on FastCST should send a swift kick to my e-mail
> address.

Before I finished that sentence, I expected you to say, "Anyone who's
interested in kicking me in the butt and motivating me to actually
work with them on FastCST should send a [fifty dollar check] to my ...
address."

I thought, "Yeah, that'd do it."

--=20
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland

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

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

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.

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

Avi

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

On 6/28/05, Michael Neumann <> wrote:

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

Good. But the important thing here is that if your entities are small
enough, you don't need to worry about automatic merging or diffing
within the content of the entity. You only need to compare different
content versions for equality. This makes a *huge* difference to the
complexity of the SCM. So it's not really about whether you could
implement something method-based on top of something that was file
based (clearly you could), but how much work and complexity you can
avoid by doing it method-based from the start.

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

That's definitely the most challenging problem of this approach. To
start with you could have an entity (maybe represent it as a singleton
method called "initialize" on the class, if you like) that would
gather up all of the "loose" code inside the class def. In most
cases, I think just keeping this in a single block at the top of the
class def would be ok. However, you would definitely need to provide
some structure for cases where ordering was important. One TSTTCPW
strategy would be to use RDoc-like comments to mark off blocks of code
that should be treated as individual entities, combined with a general
inclination on the part of the SCM to keep entities in the same order
where possible. So:

class A
#RCM
attr_accessor :a
#/RCM

def b
end

#RCM
C = 4
#/RCM
end

> Do you know if Codeville is usable for C code? Or is a very regular
> object structure (packages, classes, methods) required?

Codeville doesn't require any structure, it's line-based. Monticello
2 uses the Codeville approach (or at least I think it's the same, we
came to it independently) of a 2-way merge + independent ancestry info
for each fine-grained entity, but in Codeville's case the entity is
the line whereas in Monticello's case it's the method. I do think the
idea works much *better* if there's a regular structure (how do you
uniquely identify a line to attach ancestry to it?) but I think it's
still worth looking at even for a more language-agnostic system.

One thing that's really cool about this, though I don't know if
Codeville itself takes advantage of it, is that you can do a perfect
merge having *only* the two versions you're merging plus their
metadata. So a formal repository becomes completely unnecessary: you
never need to look up any previous history. You could build this as
an extension to RubyGems, for example: each gem version would carry
around enough info to let it be merged into any other gem version, and
they could just be emailed or FTP'd or whatever around without any
special protocol. It's about as distributed as it gets.

Monticello 1 did this as well, but with a Monotone-style three-way
merge, which means that you still need enough of a repository to find
and retrieve the common ancestor.

Cheers,
Avi

Zed A. Shaw wrote:
> Hi Everyone,
>
> Already replied to you (Michael) offline, but thought I'd throw this out
> there.
>
> I know I've been totally delinquent in the FastCST development, but I
> promise I am actually working on it, just kind of indirectly.
>
> * I'm currently polishing off the Ruby/Odeum code so that I can use it
> in FastCST for full text search over code and revisions. This should
> replace just about all the tagging and "revisions follow moves" stuff
> out there. My recent tests show that this approach just rocks.
> * I'm finishing off the CookbooXUL application since I want to provide a
> nice XUL based interface to FastCST.
> * I'm working on the Linda distributed stuff so that I can include
> zero-config setup.
> * And I'm doing a libevent binding so...I can do a libevent binding.

Wow! All that sounds impressive. Please, keep us informed.

Could you explain more detailed what you mean with: ...tagging and
"revisions follow moves"?

Could you give a practical example (e.g. how it would work on the
command line), so that I can understand it?

Regards,

Michael