Re: bzr repository ready?

["Óscar Fuentes" <ofv@wanadoo.es>]

Richard Stallman <rms@gnu.org> writes:

[snip]

> I'm asking about how to use lightweight checkouts.  Someone
> recommended them for people not writing lots of changes.

Other than disk space savings, there is no reason for using lightweight
checkouts as a means to write an occassional change. Either you
misunderstood the context of the recommendation (because lightweight
checkouts are widely used on some advanced setups, maybe he was talking
about that) or the recommendation is not good, IMO.

> When you make a lightweight checkout, do you have to first make a
> local repository and get the branch into it?

Not required.

> Or can you make a lightweight checkout straight from the remote
> repository?

Yes.

> I got the impression that the lightweight checkout was recommended
> because it avoids the need to make a local repository.  The questions
> I've asked are based on that understanding.  The answers I get seem to
> suggest the contrary, that the lightweight checkout is made from a
> local repository.

You can make the lightweight from any *branch* (in bazaar, repositories
are just collections of not-necessarily-related branches, used for
optimizing access and storage. A branch is an independent entity: you
don't need a repository for having a branch.)

> But if that's true, I don't see what good the
> lightweight checkout does.  Why not edit the local repository's source
> files directly?
>
> In other words, after doing 
>
>    bzr branch URL_TO_UPSTREAM_EMACS_TRUNK
>
> why not just go ahead and edit the files in the directory
> for that branch?

You can certainly do that. Why most people don't? Because as it is so
easy to clone branches and move revisions from one branch to another
branch in a dVCS, what is recommended is:

1. Create a repository for taking advantage of the space savings and
fast operations it provides.

2. Clone the upstream branch into your repository.

3. Keep that branch as a pristine local mirror of upstream.

4. Clone your upstream local mirror branch for creating another branch
you use for hacking.

From here, there are lots of variations, with a varied degree of
complexity.

> The text in the wiki seems to say that you pull over a branch with
> `bzr branch', and doesn't say anything else is necessary before you
> use it.
>
> Is that true?

Yes.

> Once you do that command above, what is the state?

You have a copy of the branch you cloned. The only thing that
differentiates your new branch from the cloned one is that your new
branch refers to the cloned one as its "parent". For the rest they are
identical.

> What can you actually DO with the branch at that point?

Whatever you please. Really.

> Do you have to make a checkout from the branch in order to get
> source files you can use?

Only if you explicitly requested from the `bzr branch' command that it
shouldn't create the source files:

bzr branch --no-tree URL_TO_UPSTREAM_EMACS_TRUNK
___________^^^^^^^^^

or if you created your repository (in case you are using one, which is
recommended) with

bzr init-repo --no-trees my-repository
______________^^^^^^^^^^

Otherwise, your newly cloned branch will have all the source files ready
to be edited.

Please note that the previous responde to you on this subthread was from
Karl Fogel. I have a different opinion about how those who have no
previous experience with a dVCS should transition to Bazaar. I think it
is unnecessarily confusing for them to go straight for the full
distributed setup. An intermediate step, where you familiarize yourself
with bazaar's interface but use a workflow that is reminiscent of CVS
would simplify the transition. My recommendation is:

bzr init-repo my-repository
cd my-repository
bzr checkout URL_TO_UPSTREAM_EMACS_TRUNK emacs

Now you have the files ready to work. Why I used `bzr checkout' instead
of `bzr branch'? Because the `checkout' creates a "heavyweight
checkout", aka "bound branch", which means that your commits go directly
to upstream, as CVS does, instead of being stored on the branch waiting
for your explicit orders for sending them upstream.

Your daily work would consist on:

<hack, hack, hack>
bzr update
bzr commit
<repeat cycle>

The only additional commands you need to know for now:

bzr status  # says what you edited, what's in conflict state, etc.
bzr resolve [file ...] # For telling bazaar that you solved a conflict.
bzr diff [file ...]
bzr log [file ...]
bzr annotate [file ...]

All those commands are accesible through VC/VC-Dired and work off-line,
except 'update' and 'commit'.

Once you are confident with this and you feel at home with bazaar
interface (a few hours is usually enough), you can migrate to a workflow
that is fully distributed and that allows you having your own branch in
your machine, for committing off-line to that branch and sending the
changes upstream in batches when you are connected.

The key here is that the basic setup I described can be effortless
morphed into whatever workflow you choose to use in the future
(converting a bound branch into an unbound branch or vice-versa requires
just one command) without having to repeat long and painful operations
like re-downloading all the history from upstream, etc.

-- 
Óscar