smart server should update remote working trees

How would this handle conflicts better than is possible from a normal push from a remote location?

Here is the behavior I would expect, and is probably what most users would expect if they knew how "bzr pull" worked but didn't know how "bzr push" currently worked:

The semantics ought to be EXACTLY the same as if you just did:
$ ssh remote bzr pull

or with the current push semantics:
$ bzr push
$ ssh remote bzr up

If there are conflicts, okay, no problem, it creates conflict files, etc, EXACTLY as if a bzr up or bzr pull was run remotely. Then it's just up to the user to resolve them on the remote system. If they wanted to nuke everything, they'd do "bzr push --overwrite", which would work just like "bzr pull --overwrite" on the remote system would do currently.

There could optionally be a flags to suppress doing the update if that was desired for some reason, e.g. "--no-update".

On Tue, 2009-02-10 at 19:19 +0000, Marius Kruger wrote:
> How would this handle conflicts better than is possible from a normal
> push from a remote location?
It wouldn't handle conflicts any better or worse, but it can actually
update the remote working tree without a lot of roundtrips, as you would
need on e.g. sftp.
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>

As the smart server runs in a chroot, this is blocked by bug 606249.