Some clarifications and proposals
Alan Franzoni
I've just discovered the existence of amp.
It has happened because I realized I had baked a set of "workflow
scripts" for my normal mercurial workflow - something like "new
feature" "feature done" "new bugfix", etc, and I thought about
refactoring them into a better organized software, and I had a small
POC ready (it's unpublished yet, I'll put it on bitbucket in the next
few days)
Then I stumbled across nvie's git workflow:
http://nvie.com/posts/a-successful-git-branching-model/
And across amp, which seems more similar to what I had in mind, except
for the fact that its scope seems rather large from my point of view.
My "workflow idea" would be something like:
- every project/company does use a different VCS *and* a different
workflow on top of that VCS (how are branches)
- many times, developers don't care about which vcs they're using -
they just want to code a feature, a bugfix, a refactor, etc, then they
need to merge/rebase/push whatever their changes to another central or
shared repo.
Many times this is an hassle, and should be configurable on the repo
itself on the top of the existing VCS.
What I think is too large in scope with amp is:
- reimplementing every and any vcs seems really boring, hard to do and
hard to keep in sync. After all if you want to work with a certain VCS
you'd have it installed on your machine; why not just launching an
external executable?
- I'd just like an ideal, customizable "abstract" workflow and map it
to all & any supported VCS. I don't think mimicking a specific vcs
workflow to other VCSes to be that important.
- I don't want to incorporate all & any features from a VCS into my
workflows, just the main ones. If anybody wants to do dig deeper, he's
free to do so by using the *real vcs tool*. I think it's impossible to
accomodate all & any vcs systems out there - and they're evolving
quickly!
I really think that a *breadth first* approach would be great - let's
first support some basic workflows for any VCS, by just spawning
processes, then go on by adding features and (if needed) using a
native VCS library where available.
Any thoughts? Am I going in the opposite direction from what was the
idea behind amp?
--
Alan Franzoni
--
contact me at public@[mysurname].eu
Ari Brown
On Feb 28, 2011, at 4:53 PM, Alan Franzoni wrote:
> And across amp, which seems more similar to what I had in mind, except
> for the fact that its scope seems rather large from my point of view.
>
> My "workflow idea" would be something like:
Gonna have to agree with you on this one, even as one of the main developers. However, I'm gonna say that I really enjoy the fact that amp provides a pure ruby way to interact with the various VCSs. Grit's fatal flaw is that it has to shell out, which costs a lot of precious time. A complete, pure-ruby implementation would be much faster and IMHO much better.
> Any thoughts? Am I going in the opposite direction from what was the
> idea behind amp?
Not in the slightest! This is what amp is all about: a single interface to multiple repositories. There are a few issues to this (like identifying different foreign repositories' types) that need solving. This is much easier on a smaller scale, and it is my opinion that it would be worth doing a rewrite to build it up with this in mind. I know, I know, rewrites are never good, but I think it would be worth a try. Mike and I have already gone over some basic mistakes we have made in this process and would like to remedy them; the biggest mistake was conflating interface with implementation.
In summary:
o Let's work together to write a much simpler, core version of amp
o DO NOT conflate implementation with interface
o Provide solutions to basic problems (like identifying foreign repositories' types) in a modular manner, so that a better solution may easily be provided
o Suck less
o Rock more
- Ari
Alan Franzoni
> Gonna have to agree with you on this one, even as one of the main developers. However, I'm gonna say that > I really enjoy the fact that amp provides a pure ruby way to interact with the various VCSs. Grit's fatal flaw is > that it has to shell out, which costs a lot of precious time. A complete, pure-ruby implementation would be
> much faster and IMHO much better.
Sure, but it's an implementation detail, as you correctly point out
later. VCSes can be supported via external processes at the begining,
and then they can be optimized by creating a native lib for them.
> In summary:
> o Let's work together to write a much simpler, core version of amp
> o DO NOT conflate implementation with interface
> o Provide solutions to basic problems (like identifying foreign repositories' types) in a modular manner, so that a better solution may easily be provided
> o Suck less
> o Rock more
Yup. Let's agree on some typical usages BTW: mine are:
1) As a developer for a project or a team, I should not be forced to
read complex documents on internal workflow or to learn by heart how a
VCS works, unless I need to do something which is really complex; I
should focus on development via an high-level workflow, something like
"start bugfix for ticket #NNN", "bugfix done", "start feature ABCD",
"share changes with central repo", etc.
2) As a developer, I should not be forced to learn each-and-every
possible vcs or any-possible-workflow just for doing some basic
patch-this-bug-and-send-upstream for some third party project I'm
using. So I could just use a generic interface, so that a) I don't
need to learn the vcs and b) the owner of the project can dictate the
workflow.
I've just forked amp from bitbucket, the website seems down again BTW
(it has been down for a long time, or so it seems, in the past weeks);
I'll code a proposal soon.
Alan Franzoni
> much faster and IMHO much better.
Sure, but it's an implementation detail, as you correctly point out
later. VCSes can be supported via external processes at the begining,
and then they can be optimized by creating a native lib for them.
> In summary:
> o Let's work together to write a much simpler, core version of amp
> o DO NOT conflate implementation with interface
> o Provide solutions to basic problems (like identifying foreign repositories' types) in a modular manner, so that a better solution may easily be provided
> o Suck less
> o Rock more
Yup. Let's agree on some typical usages BTW: mine are:
1) As a developer for a project or a team, I should not be forced to
read complex documents on internal workflow or to learn by heart how a
VCS works, unless I need to do something which is really complex; I
should focus on development via an high-level workflow, something like
"start bugfix for ticket #NNN", "bugfix done", "start feature ABCD",
"share changes with central repo", etc.
2) As a developer, I should not be forced to learn each-and-every
possible vcs or any-possible-workflow just for doing some basic
patch-this-bug-and-send-upstream for some third party project I'm
using. So I could just use a generic interface, so that a) I don't
need to learn the vcs and b) the owner of the project can dictate the
workflow.
I've just forked amp from bitbucket, the website seems down again BTW
(it has been down for a long time, or so it seems, in the past weeks);
I'll code a proposal soon.
--
Justin Love
> I've just forked amp from bitbucket, the website seems down again BTW
Most of the recent development has been on github.
https://github.com/michaeledgar/amp_complete
is the official repo (and still in a little disorder from the reorg)
I've got more recent edits, but I'm pushing on a repo spec, which I'm
still building up and haven't integrated.
--
Justin Love -- http://JustinLove.name/