Re: [Fab-user] Any interest in extension to support getting things from source control?

[Jeff Forcier]

On Fri, Oct 9, 2009 at 11:21 AM, Jeremy Katz <address@hidden> wrote:

> For one thing, if you want to be able to reliably handle errors, run()
> isn't going to be feature-ful enough unless you're wrapping some sort
> of shell scripting.

Have you used the version of run() in the 0.9 beta (as opposed to the
0.1.x version)? Just curious, I added a bunch of small things that
make it much easier to interrogate a run() or sudo() about its return
status and such. If that's not enough, I'm all ears for ways it can be
further improved.

> With the right level of abstraction,
> that could be mostly a no-op from the side of our deployment scripts.

I'm torn on the "abstract SCM operations" point, partly due to the
work I've done on experimental Trac/Redmine type software. It's a
great idea at the very highest level ("obtain X tree from Y source
server") but as soon as you enter the zone that differs between
centralized and decentralized SCMs (mostly anything to do with
branches), it gets very hairy and you have to start making a lot of
assumptions.

That's not to say I don't want to go that route -- just that I
hesitate a bit. I personally think it'd be best to have per-SCM
modules which share as much API as possible but diverge where
necessary.

> I'm not 100% decided that Fabric is the right tool for our needs, but
> I have a strong leaning towards trying to reuse and build on top of
> existing projects rather than starting from scratch

And the FOSS world needs more of that attitude vs knee-jerk wheel
reinvention, so kudos to you :) (Ruby/Capistrano folks might say I'm
on shaky ground with that statement, but that's another discussion.)

As mentioned, I'd like to try and get Fabric to a spot where it's
legitimately useful to a lot of people  without getting top-heavy with
too many features. We'll have to see if that's doable, but I'm
optimistic.

> * Reverts to ensure no one screwed with the code on the remote box and
> avoid needing a merge

Just curious -- how do you deal with the (awful but common, IME)
situation where the un checked in code needs to be preserved or merged
in?

> * Logging to get commit log messages.

What do you do with this information exactly?

> But if the fit's not good, then that's cool too -- it
> just seemed worth asking rather than assuming

As mentioned, I personally think it is a pretty good fit as long as
it's kept to a reasonable sized API, though if everyone else agrees
with Steve/Ask's POV I may reconsider that position.

-Jeff