[MERGE] Add two new help topics

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> I think we want to be more explicit about "shared repository" versus
>> just "repository". Also having the term "shared repository" might help
>> distinguish it from darcs/git/hg which just use the term "repository" to
>> mean *everything*.
> 
> Longer term, I'm reconsidering the decision to call them "Repositories".
>  At the time I suggested it, I don't think anyone realized it was
> becoming an ambiguous term.  Perhaps "Archive" would be better, at least
> for the user-visible "Shared Repository".  Because Archive doesn't mean
> anything to darcs/git/hg/svn/cvs users, it leaves us free to define it.
>  (And the term is a good match for Arch users, if any are left.)

yeah. ISTR having this discussion in Canada a long time ago (1.5 yr?).
We have a little bit of legacy at this point, but at least we can
migrate away from confusion.

> 
>>> +To create a shared repository use the init-repository command (or the alias
>>> +init-repo). This command takes as an argument the location of the repository
>>> +to create. This means that 'bzr init-repository repo' will create a directory
>>> +named 'repo', which contains a shared repository. Any new branches that are
>>> +created in this directory will then be 'in' the repository, and use it for
>>> +storage.
>> ^- do we need "will then be 'in' the repository"?
> 
> That's actually a mild contradiction of our model.  Branches use
> repositories, but repositories are essentially unaware of their branches.

I thought about that, too. But when you talk to people they will think
about it in those terms.


...

>>> +If you want to have a working tree on a remote machine that you push to you
>>> +can either run 'bzr update' in the remote branch after each push, or use some
>>> +other method to update the tree during the push. There is an 'rspush' plugin
>>> +that will update the working tree using rsync as well as doing a push. There
>>> +is also a 'push-and-update' plugin that automates running 'bzr update' via SSH
>>> +after each push.
>> ^- I'm not sure about having plugins mentioned in bzr core... If the
>> functionality is that important, maybe it should be core.
> 
> I would rather mention plugins in the core than put either one of these
> plugins into the core.
> 
> Aaron

I certainly agree with you there. But I'm wondering if it is presenting
a hole in our functionality. If this is something that is cropping up often.

While I can understand the aesthetics of not updating a remote working
tree, it would seem that most users want something even if it meant:

1) Occasionally overwriting uncommitted remote changes
2) Dealing with a conflict on a remote machine.

John
=:->