[MERGE] Add two new help topics

Aaron Bentley aaron.bentley at utoronto.ca
Mon Apr 16 20:28:25 BST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.)

>> +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.

>> +Related commands:
>> +
>> +  init-repository   Create a shared repository. Use --no-trees to create one
>> +                    in which new branches wont get a working tree.
>> +"""

Needs an apostrophe in "won't".

>> +_working_trees = \
>> +"""Working Trees
>> +
>> +A working tree is the contents of a branch checked out on disk so that you can
>> +see the files and edit them. The working tree is where you make changes to a
>> +branch, and when you commit the current state of the working tree is the
>> +snapshot that is recorded in the commit.

Since "checkout" is more specific that "working tree", I think it is a
shame to describe "working tree" in terms of "checked out".

> When you push a branch to a remote system, a working tree will not be
> created. If one is already present the files will not be updated. The

Comma needed: "If one is already present, ..."

> branch information will be updated and the working tree will be marked
> as out-of-date. Updating a working tree remotely is difficult, as there
> may be uncommitted changes or content conflicts that are difficult to
> deal with remotely.

I think the original is more accurate.  The issue is that updating the
working tree would *cause* content conflicts, not that they may already
be present.

>> +If you have a branch with a working tree that you do not want the 'remove-tree'
>> +command will remove the tree if it is safe.

Needs a comma after "do not want, ..."

>> +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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGI85Z0F+nu1YWqI0RAuPhAJwMzVztuOfrnj5oUNEd5xWI2sXcRgCeJCQc
l+wfbC9fimAjgC2eoFENDNo=
=+KHE
-----END PGP SIGNATURE-----



More information about the bazaar mailing list