creating checkouts, bound branches and standalone branches from an existing branch
Denys Duchier
duchier at ps.uni-sb.de
Tue Feb 14 20:24:26 GMT 2006
jblack at merconline.com (James Blackwell) writes:
> Heh. Do we both agree and disagree?
I don't know, but I get the impression that you believe that I am trying to dumb
down the UI. That is not at all the case. I would like the UI to offer:
1. a small set of friendly commands that are easy to explain in terms that
matter to casual users and address, in an intuitive fashion, the use cases
that they care about
2. a complete set of specific commands for more advanced use cases
> Remote and local should be changed if we follow the rule that you state.
> They're not use cases because they're not an example of use.
Perhaps you'll amend your opinion if I actually provide the descriptive help
that is supposed to go with them ;-) so, here goes:
When you get a copy of project, you may want to make your own private
changes, or you may want to contribute these changes to the original
project (see the "commit" command).
To make your own private changes, you will require your own "local" copy of
the project's revision data:
bzr get --access=local URL PATH
To contribute your changes directly to the original project, you need bzr to
put them in the "remote" project's revision data:
bzr get --access=remote URL PATH
It is sometimes convenient to contribute your changes both in a local copy
of the project's revision data and in a remote copy as well:
bzr get --access=local,remote URL PATH
For example this allows you to continue "committing" changes when the remote
project is not accessible. This also speeds up certain operations (e.g. the
"log" command) because they can take advantage of your local copy instead of
having to access the remote project. However, having a local copy of a
project's revision data incurs a cost in disk space. For certains projects,
this cost can be quite significant.
Cheers,
--Denys
More information about the bazaar
mailing list