The push|pull vs update distinction

[John Arbash Meinel]

Andrew Cowie wrote:
> On Tue, 2008-01-15 at 01:55 -0500, Aaron Bentley wrote:
>>> protocol, pull always updates the working tree and push never does.
>> Push does update the working tree if the
>> working tree is using the filesystem.
> 
> Yeah, that's the discrepancy I was alluding to.
> 
> ++
> 
> I understand why merge doesn't commit (and accept* that one).
> 
> ++
> 
> I'm still hoping that we can change the fact that `bzr push bzr
> +ssh://example.com/...` doesn't internally have the remote bzr server
> process do `bzr update` on the remote filesystem as `bzr push` locally
> does.
> 
> If we can deal with the "what happens if there are problems updating
> after a local push" case (ie, you cd to the other branch and deal with
> it), then surely we can deal with "what happens if there are problems
> updating in a remote push" when we clearly have shell** access to the
> target (ie, you ssh to the other branch and deal with it).
> 
> Yes, the push-and-update plugin is the workaround, but it incurs a
> second ssh connection which takes a lot of time, and seems unnecessary
> given `bzr serve` is already instantiated and running.
> 
> AfC
> Sydney
> 
> 
> * except for a caveat about dotted revnos and commit messages that I've
> been drafting and will send along as soon as I can. Short version: I
> think that we could emphasize the original contribution revisions rather
> than the merge revisions.
> 
> ** I do get that there are scenarios where the remote account|shell have
> been set to prevent interactive login etc. Perhaps the way to deal with
> this is to have push "fail" if the update step fails (would fail?). This
> is, after all, the converse of what happens if you try to commit to a
> bound branch and the remote branch commit fails... and the fact that the
> revisions have meanwhile been shipped to the other side is all good.

Right, LP works that way (it uses a custom SSH implementation that 
doesn't even *have* a shell). And there is contrib/bzr_access which 
allows you to restrict connections to only allow "bzr serve" to be run.

My concern is about how we would be told when a user has access to a 
shell, and when they don't. I suppose we could plug it in as "bzr serve 
--no-update-trees" which can be put into the bzr_access script.

Martin and I discussed the idea last night in a phone call. It probably 
wouldn't take a lot to implement a RemoteWorkingTree class which just 
proxied requests to the remote side and had them run there. It would 
certainly work for things like "bzr push". (At the moment 
RemoteBzrDir.open_workingtree() always raises NotLocalUrl if there is a 
remote working tree, rather than returning something the caller could 
use for .push.

So it could be implemented in a new smart verb or two, and a helper 
class. We would have to be careful about how it would effect other 
commands, though. A class that only implements 'push' is ok, but most 
code expects it wouldn't be able to grab a WorkingTree if it can't 
perform operations. (So RemoteWorkingTree should actually implement 
*most* of the WT interface.)

John
=:->