Status Update 11/1/2010
Michael Edgar
However, I believe making these plugins work will prove to be a testament to Amp's infrastructure. We'll likely need to make tweaks along the way, but I intend to have some basic repository operations working on both hg and git repositories before the RubyConf presentation. I definitely want amp-core at a good enough place that people can dive into amp-hg or amp-git and make real progress.
I also want to update the website. Would anyone (hint hint: Ari) want to help out with that tonight? I have a few things we need to update overall and we should include a news post somewhere somehow mentioning the new repositories and approach.
Ari Brown
On Nov 1, 2010, at 12:32 PM, Michael Edgar wrote:
> I also want to update the website. Would anyone (hint hint: Ari) want to help out with that tonight? I have a few things we need to update overall and we should include a news post somewhere somehow mentioning the new repositories and approach.
I'm free for an hour at about 9. Does that work for you? Skype me.
Justin Love
> However, I believe making these plugins work will prove to be a testament to Amp's infrastructure. We'll likely need to make tweaks along the way, but I intend to have some basic repository operations working on both hg
Awesome. Sorry I haven't been much help; I had to drop in to full
presentation mode. I now have two short preview runs tomorrow.
> and git repositories before the RubyConf presentation. I definitely want amp-core at a good enough place
I was looking through the old code, and the Abstract classes make me a
bit nervous - it sounds like something that belongs in a statically
typed language. Even though there isn't much implementation, I also
found this very interesting:
“inheriting implementation [...] tends to create difficulties in
subsequent evolution and often reflects insufficient understanding.” -
Peter Deutsch, The Past, Present, and Future of Smalltalk, 1989
Obviously having the template and documentation is important, but I
can't help thinking it would be better served by something else.
Possibilities include:
- amp-null, a blank repo skeleton to start from. Probably looking a
lot like the Abstract classes, but not in the ancestor chain.
- full on generators might be too much work given the relatively few
number of repos out there
- a generic repo test suit, a-la RubySpec
If this is interesting, we can refactor later, of course.
--
Justin Love -- http://JustinLove.name/
http://ComputerGeneratedDreams.com/
"[T]he woods would be silent if no bird sang except the best."
- Henry Van Dyke
Michael Edgar
On Nov 1, 2010, at 11:43 PM, Justin Love wrote:
> On Mon, Nov 1, 2010 at 11:32, Michael Edgar <ad...@carboni.ca> wrote:
>> However, I believe making these plugins work will prove to be a testament to Amp's infrastructure. We'll likely need to make tweaks along the way, but I intend to have some basic repository operations working on both hg
>
> Awesome. Sorry I haven't been much help; I had to drop in to full
> presentation mode. I now have two short preview runs tomorrow.
>
>> and git repositories before the RubyConf presentation. I definitely want amp-core at a good enough place
>
> I was looking through the old code, and the Abstract classes make me a
> bit nervous - it sounds like something that belongs in a statically
> typed language. Even though there isn't much implementation, I also
> found this very interesting:
This is a very good point. It's important to note that inheriting from those classes
is *not* required. They're just there to provide a full listing of what we currently
consider to be the required API.
However, inheriting from those classes does have one benefit, which is that it
automatically includes the CommonXXXMethods module, which provides
common functionality on top of the API. So, if you implement the bare API for
VersionedFiles and Changesets, then the CommonXXXMethods module will
provide methods for diffing. This is crucial because it's one way to make
Amp more powerful over time: by moving functionality to those common modules.
As it stands, we could certainly move that stuff to separate classes: make a
ChangesetDiffer class that diffs 2 changeset objects that implement our Changeset
API, to follow the example. This would encourage composition over inheritance, but it
doesn't seem necessary as of yet: most of the current methods in the CommonXMethods
modules seem like they do in fact belong in the given classes, and it makes commands
more natural to write.
Given that perspective, what are your thoughts?
Justin Love
> automatically includes the CommonXXXMethods module, which provides
I've been pretty impressed with the Rails 3 architecture. Applying
this to Amp would mean making every piece a separate module, with one
base module that includes everything else for those who want it. Of
course it might come back to cost/benefit - Rails is built to make
thousands of applications, we might have what, a few dozen formats in
the limit? (And not more than two for quite a while.)
Which reminds me. In the time since Amp was started, the Ruby
community (at least the active portion) has become so Git(hub) focused
that Git support will probably be essential to adoption. I've been
thinking that command-line wrappers and/or grit might be useful
stepping stones.
Ari Brown
On Nov 2, 2010, at 9:28 AM, Justin Love wrote:
> Which reminds me. In the time since Amp was started, the Ruby
> community (at least the active portion) has become so Git(hub) focused
> that Git support will probably be essential to adoption. I've been
> thinking that command-line wrappers and/or grit might be useful
> stepping stones.
Indeed, they are. We used shell wrappers in the beginning to make sure that git was ready to place nice. It was in that that I realized it was going to be a lot more complicated than we thought. Git is like a dog that is fantastic and loves kids (sometimes), but has issues with other dogs. You would never think she has such issues, but she does.
Shelling out is evil and slow, and grit shells out at its core. The old git-ruby does NOT, but it is no longer maintained. We can either plug in that or roll our own git format. I don't *think* it's that hard, but hey, that kind of mentality is just gonna bring us bad luck.
Justin Love
> Shelling out is evil and slow, and grit shells out at its core. The old git-ruby does NOT, but it is no longer maintained. We can either plug in that or roll our own git format. I don't *think* it's that hard, but hey, that kind of mentality is just gonna bring us bad luck.
I was thinking it might be useful to maintain e.g. amp-git-wrap and so
on so that we could run the same function on two amp repo objects
(ruby and wrap) and then compare the results. The main obstacle would
seem to be timestamps.
Michael Edgar
What he means is parsing the output of various commands turned into hell,
because almost none of the output is standardized.
>
> Shelling out is evil and slow, and grit shells out at its core. The old git-ruby does NOT, but it is no longer maintained. We can either plug in that or roll our own git format. I don't *think* it's that hard, but hey, that kind of mentality is just gonna bring us bad luck.
The Git format is actually *pretty* easy to implement without lots of its neat
features like the stash and whatnot. It's all based around objects: commit,
tree (a directory structure), file (which has the file's content in it), tag.
While we'll need to read git's packed-file format (which is where diffing and
patching comes in) to read the repository format, new objects are just put
in compressed format in its own file in .git/ . So to start, our #commit methods
only need to create those objects (I call them LooseObjects in the source)
which is much easier. That's one nice part of the fact that the object format
is different from the compression/archival format. In retrospect, we could have
not handled diffing/patching with Mercurial's format... but that would permanently
slow down a repo, whereas with Git, it's no big deal.
I've almost got the existing Git code passing all its tests. Most of the issues are
the lack of the old support monkeypatches. I'm rebuilding them in a shared
StringUtils library that comes with amp-core.
Mike
Ari Brown
On Nov 2, 2010, at 10:24 AM, Michael Edgar wrote:
> The Git format is actually *pretty* easy to implement without lots of its neat
> features like the stash and whatnot.