Sorry for the delay again. Here's bzr info -v again with the problem happening.
B:\dev\gnostica>bzr info -v
Checkout (format: unnamed)
Location:
checkout root: .
checkout of branch: bzr+ssh://<email address hidden>:6475/home/developm/r
epository/gnosticawakenings/
Format:
control: Meta directory format 1
working tree: Working tree format 6
branch: Branch format 6
repository: Repository format 2a - rich roots, group compression and chk inv
entories
branch.conf attached (from local machine)
branch-server.conf attached (from server's branch.conf, but note that upload --auto is turned off...) - oh, I can only attach one file, will attach in new comment
Do you think putting the server's own public key in its authorized keys and forcing it to use a bzr+ssh path (instead of direct) to itself would be a workaround? I saw one gentleman up there said that that is probably the cause - that Windows didn't recognize the file:/// URL. And I can sort of confirm that because my own local Linux box made a similar complaint; it just wasn't fatal for whatever reason, but it actually does get in the way of server operations and being able to fix the branch by updating for Windows users.
Sorry for the delay again. Here's bzr info -v again with the problem happening.
B:\dev\gnostica>bzr info -v :6475/home/ developm/ r gnosticawakenin gs/
Checkout (format: unnamed)
Location:
checkout root: .
checkout of branch: bzr+ssh://<email address hidden>
epository/
Format:
control: Meta directory format 1
working tree: Working tree format 6
branch: Branch format 6
repository: Repository format 2a - rich roots, group compression and chk inv
entories
branch.conf attached (from local machine)
branch-server.conf attached (from server's branch.conf, but note that upload --auto is turned off...) - oh, I can only attach one file, will attach in new comment
Do you think putting the server's own public key in its authorized keys and forcing it to use a bzr+ssh path (instead of direct) to itself would be a workaround? I saw one gentleman up there said that that is probably the cause - that Windows didn't recognize the file:/// URL. And I can sort of confirm that because my own local Linux box made a similar complaint; it just wasn't fatal for whatever reason, but it actually does get in the way of server operations and being able to fix the branch by updating for Windows users.