Second run feedback (Re: First run feedback)

[Justin Love]

Getting decent feedback on presentation, but still people are
questioning the idea. I've got some thinking to do. They were doing
video; not sure what lead time is but it should show up here:
http://chicagoruby.org/

On the other hand, I may have one convert, at least in name:

@nicholaswyoung Nicholas Young
@wondible's talk on AMP was great. He's sold me on it, and I suggest
you take a look: http://amp.carboni.ca #chicagoruby

Not sure if it's related, but same person pulled up a comforting thought:

"If there's nobody who's hating on [your project], you're typically
not doing very interesting work." - @dhh

Other question was about more divergent systems like Subversion. I've
got a few ideas about how this might be handled, but wondered if you'd
done much thinking about it.

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

Awesome!

Here's my thoughts on "divergent" systems like svn from a broader
perspective:

I believe you should be able to use the same tool for both centralized
version control as well as decentralized version control. I think that each
built-in Amp command should have the same semantic behavior when used
for a .git, .hg, or .svn project.

Consider this: Using git, if you were to alias away "git commit" to something
like this: "git commit and git push or git rollback", meaning "commit and push,
but roll back the commit if the push fails", you've just created a centralized
workflow for yourself. Since Amp isn't about getting your entire team to use
the same tool, but instead just improving your personal experience, that's
good enough. With trivial work, Amp can provide both models for git projects.
Same for mercurial.

Now, svn doesn't offer in its repository model the capability of local commits, really.
This is where Amp would involve actual non-compatible changes. In my opinion,
whenever Amp functionality that invokes non-compatible changes is run, it should
print in big red letters that that will happen. Amp would then store local commits in
.svn using perhaps a .amp_local_xxx subdirectory using an Amp-custom format,
and when you do `amp push`, it gathers up the appropriate local commits and
commits them to svn. If desired, the user could even say "collapse the locals into
1 big svn commit" if they wanted, instead of individually pushing each to the svn
server.

This is a small but important change. If you used it in a .svn project, and you
mix-and-match `svn` and `amp`, you run the risk of losing those local commits.
I'm not sure how to address that yet, but I think that is the problem to address,
since I think the previous modification to svn to provide non-local commits is
satisfactory. Of course, my opinions are always up to be challenged; that's just
where I've arrived thus far.

Mike

[Justin Love]

On Wed, Nov 3, 2010 at 00:19, Michael Edgar <ad...@carboni.ca> wrote:
> print in big red letters that that will happen. Amp would then store local commits in
> .svn using perhaps a .amp_local_xxx subdirectory using an Amp-custom format,

I expected something like that. But why Amp-custom? Other than a
plugin dependency (and Amp-custom would just be another dependency)
why not use a git or hg repo?

[Justin Love]

On Tue, Nov 2, 2010 at 23:57, Justin Love <goo...@justinlove.name> wrote:
> video; not sure what lead time is but it should show up here:
> http://chicagoruby.org/

Didn't click through to vimeo last night; in any case, it's up now:

http://vimeo.com/channels/chicagoruby#16451778

[Ari Brown]

On Nov 3, 2010, at 11:15 AM, Justin Love wrote:

> On Wed, Nov 3, 2010 at 00:19, Michael Edgar <ad...@carboni.ca> wrote:
>> print in big red letters that that will happen. Amp would then store local commits in
>> .svn using perhaps a .amp_local_xxx subdirectory using an Amp-custom format,
>
> I expected something like that. But why Amp-custom? Other than a
> plugin dependency (and Amp-custom would just be another dependency)
> why not use a git or hg repo?

It would make sense to use a .svn directory. If Amp wants to take notes behind SVN's back (like for managing commits prior to pushing), then it has to do it in a way that doesn't affect SVN. We *might* be able to do this by just throwing a random-ass file in the .svn directory – we can do that in .git and .hg directories, for instance.

[Justin Love]

On Wed, Nov 3, 2010 at 14:53, Ari Brown <a...@aribrown.com> wrote:
> It would make sense to use a .svn directory. If Amp wants to take notes behind SVN's back (like for managing

I was thinking putting a repo in the .svn directory. e.g.
.svn/staging.git/ I'm assuming git & co can separate the repo and
working dir like this, but we can make Amp do it even if they don't.

[Michael Edgar]

So Christine (our web designer/my girlfriend) and I watched this last night with

a friend of ours. It's awesome! I liked the fact that you really clued in on everything

we consider important. I hope the feedback we've already given helps clear up

our current thoughts about the questions raised at the end.

A few thoughts:

1. I really liked how you designated what works and what doesn't. I've never given

a presentation like this, but that kind of honesty and clarity is something that I'd really

appreciate as a viewer, y'know?

2. Redux is pronounced "re-ducks" :-P This is what we meant, for reference: http://en.wikipedia.org/wiki/Redux_(literary_term)

3. I liked that you provided some intro, but I feel like it went on just a few minutes too

long, maybe. (Also, are you sure about mentioning the naming origin? It's true, but not

sure how positively it'll be received. Just a thought)

4. *Loved* the billing command! Exactly what Amp is useful for at the scripting level.

5. My goal for next week is to have amp_redux working enough that you can livecode a read-only

command, and have it work on HG, Git, and *maybe* SVN though a Q&D shell wrapper. Think

about what you could do with the following data that I can guarantee will be exposed for HG and Git:

a. Commit metadata: time, author, message, which files were changed

b. The list of files that exist at a given commit

c. The data in all files at any given commit

d. Built in diffing between files at different revisions.

6. Thank you again for doing this!!!!!!!!

I'll be at RubyConf, though I haven't figured out lodging yet. Gonna beg for a room at the

conference hotel, but not sure how that'll end up working out.

Keep the questions coming.. there's a lot of tacit knowledge in the project we haven't

exposed, and all the questions you're asking are drawing that knowledge out :-)

[Justin Love]

On Thu, Nov 4, 2010 at 15:32, Michael Edgar <ad...@carboni.ca> wrote:
> So Christine (our web designer/my girlfriend) and I watched this last night

By the way, tell Christine she rocks. I may use a brighter red for
the highlights next time, but otherwise everything held up very well
against my projector-suckage tests.

> 1. I really liked how you designated what works and what doesn't.

I try to stick with honesty. Of course, I'm also trying to head off criticism.

As Amp-redux comes on-line, parts of it aren't really imaginary any
more. I've been wondering if I'll need a third icon.

> 2. Redux is pronounced "re-ducks" :-P This is what we meant, for

Dang French. Just when I think I've got the silent letters figured
out, they go and pronounce them ;^) But thanks, this is just one
reason I like to test run things.

> 3. I liked that you provided some intro, but I feel like it went on just a
> few minutes too

It would be one of the first things to go if I needed to cut, but
currently it's not enough to trade out for the live-coding in this
time slot. For my first round including it got me the time I wanted.
Might have liked more time for the presentation to grow, but such is
life; I'm still not completely sure how to get it up to 45 (maybe 40
with Q&A)

Personal stories add a little humor, and also some narrative while I'm
explaining things like "There are a lot of VCSs" or "Amp recently
rebooted"

> long, maybe. (Also, are you sure about mentioning the naming origin? It's
> true, but not
> sure how positively it'll be received. Just a thought)

No one has commented on it yet. I found such history interesting, and
this one was amusing and good for a laugh. Though I guess I'm more
amused by the "Ruby on Rails" idea, which isn't directly related to
Amp. It's not really necessary if you don't like it.

> about what you could do with the following data that I can guarantee will be
> exposed for HG and Git:

I was planning on a simplified billing example, but I suppose
something more involved would fill up the time slot nicely.