jam> Vincent Ladeuil wrote:
>> I'm not sure what upload should do there...(apart from not blowing up like this, that is).
>> If bzr is available on the remote site, there is no point in using upload,
>> https://edge.launchpad.net/bzr-push-and-update is far more appropriate (and works today),
>> and 'bzr push' itself should populate the working tree (but I'm not sure the smart server does that today).
>>
>> upload is mostly targeted at remote sites where bzr can't be installed and will never be as smart
>> as the two solutions above.
jam> Well, there are people who would have bzr on the remote server, but want
jam> to not upload the history to their http site. (So they don't have to
jam> worry as much about disabling download of the history.)
jam> That's about the only situation I can think of.
Right. So they want to use bzr but without the bzr data (.bzr directory).
Given that bzr-upload do all the heavy work on the *client* and
the smart server is about taking advantage of the remote
knowledge of the branch, either you use bzr-upload and 'sftp://'
(i.e. not 'bzr+ssh://') OR you use bzr with its data (but if you
don't want the '.bzr' in your published directory, you're back to
square one).
So, I say this bug is about pointing people in the right
direction if they try to use bzr+xxx protocol.
>>>>> "jam" == John A Meinel writes:
jam> Vincent Ladeuil wrote: /edge.launchpad .net/bzr- push-and- update is far more appropriate (and works today),
>> I'm not sure what upload should do there...(apart from not blowing up like this, that is).
>> If bzr is available on the remote site, there is no point in using upload,
>> https:/
>> and 'bzr push' itself should populate the working tree (but I'm not sure the smart server does that today).
>>
>> upload is mostly targeted at remote sites where bzr can't be installed and will never be as smart
>> as the two solutions above.
jam> Well, there are people who would have bzr on the remote server, but want
jam> to not upload the history to their http site. (So they don't have to
jam> worry as much about disabling download of the history.)
jam> That's about the only situation I can think of.
Right. So they want to use bzr but without the bzr data (.bzr directory).
Given that bzr-upload do all the heavy work on the *client* and '
the smart server is about taking advantage of the remote
knowledge of the branch, either you use bzr-upload and 'sftp://
(i.e. not 'bzr+ssh://') OR you use bzr with its data (but if you
don't want the '.bzr' in your published directory, you're back to
square one).
So, I say this bug is about pointing people in the right
direction if they try to use bzr+xxx protocol.