So, here's my attempt: http://github.com/paulbaumgart/fabric/blob/0b1599e457076bcba31d5a400e1227a4cf93522e/fabric.py#L670
My reasoning behind dividing it up into two functions, rsync() and rsync_project() was threefold: -Having a default value for the localpath parameter would mean it would either have to come after the remotepath (unintuitive), or force users to use only kwargs when not specifying a localpath (klunky). -It maintains the nice symmetry with upload_project(). -It's backwards compatible. Thoughts? :-) Paul On Fri, Apr 17, 2009 at 1:18 PM, Jeff Forcier <[email protected]> wrote: > For what it's worth, I've just added a 'local_dir' option to my port > of rsync_project in the magic-removal branch, so when that goes out > the door it will have that option in place :) > > -Jeff > > On Thu, Apr 16, 2009 at 11:56 AM, Jeff Forcier <[email protected]> wrote: >> On Thu, Apr 16, 2009 at 11:31 AM, Wes Winham <[email protected]> wrote: >>> For my particular case, I started out using a bzr lightweight check >>> and bzr up to do those updates, just as you would expect. There were a >>> few issues that eventually convinced me that was not the best for my >>> case: >>> >>> <snippity-snip> >>> >>> I hope that makes sense. >>> -Wes >> >> Yea, that made sense, and it sounds like you're definitely hitting a >> bunch of the scenarios I alluded to :) >> >> -Jeff >> >>> On Thu, Apr 16, 2009 at 11:00 AM, Jeff Forcier <[email protected]> wrote: >>>> On Thu, Apr 16, 2009 at 10:52 AM, Wes Winham <[email protected]> wrote: >>>>> I'm super excited about how much rsync is going to speed up my >>>>> deployment process when I'm just applying small changes. Thanks for >>>>> the awesome work. >>>> >>>> Call me silly, but isn't this what version control is for? Maintain a >>>> checkout of your release branch (or a release tag) and then just do >>>> e.g. "svn up" (or "svn switch") during your deploy process. >>>> >>>> I'm sure there are plenty of scenarios where that doesn't work, but >>>> for the common case it seems to be widespread enough to be considered >>>> best practices *shrug* >>>> >>>> At any rate, I'm definitely all for adding flexibility to the builtin >>>> tools like rsync_project -- so don't think I'm poo-pooing that! -- >>>> just curious what it may offer over what I'm personally used to. >>>> >>>> Best, >>>> Jeff >>>> >>>> P.S. Still cranking away on magic-removal, been relatively busy lately >>>> but hoping to get back on it full-steam soon! >>>> >>> >> > > > _______________________________________________ > Fab-user mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/fab-user > _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
