Stefan Monnier wrote:

As far as I can tell it's fully functional.  W.r.t the performance, it
seems acceptable and I'd expect it to be comparable to the performance
of Arch in similar circumstances.

Arch is way too slow in general...


Agreed.  Hopefully bzr-over-sftp is only as slow as Arch w.r.t the
actual network access, and all the subsequent operations are a good
bit faster.

Disk space is pretty cheap: make sure you have a "revision library set
up".   If you are importing (or quickly creating) a lot of "history," be
sure to create cached revisions on the archive-side to speed-up
first-time check-outs.   Maybe people already know all that but it was
my experience that many times when people complain about arch being
slow, they haven't taken those steps.

Arch is "heavier" than other systems and, in some ways, is basically
"doing more" (than, e.g., git) so, yes, it won't win prizes for commit
times any soon.      In some ways that's a work-style issue.   Arch isn't
intended to be used in a mode where, for example, you commit every
time you save an editor file.    The "zen" of Arch is that each commit
should represent a kind of "complete thought" so that the record of
changesets is a kind of documentation of the logical steps that were
taken in the evolution of a branch.   If you find yourself doing commits
more than at most a few times per hour, and you're not doing something
special like plowing through a bunch of trivial merges, then you might
not be using it to its best effect.

(Yes, the above is about Arch but I assume it is still applicable to
bzr).

-t