© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
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".