user guide help (definitions of terms)

[Martin Pool]

2009/8/5 Ben Finney <ben+bazaar at benfinney.id.au>:
> Inky 788 <inky788 at gmail.com> writes:
>
>> Is there a distinction between the actual state of the physical files
>> after a commit and some object in my project's .bzr dir representing
>> that state?

I'm not sure precisely what the question is.  There is a distinction
in that there is both the working copy of the file and some metadata
about it.  It is possible for the committed tree and the working tree
to be different if eg you did a selected-files commit, or you are
using content filtering (eg for eol conversion), or (before commit) if
you have files deleted with plain rm so bzr sees them as missing.  But
this is not, one could say, a very large distinction: after a commit
the wt is broadly speaking the same as the committed tree and in sync
with the wt metadata.

> In the same vein: I normally would refer to “the actual set of
> version-controlled files as they currently exist on the filesystem” as
> “working tree”. I'm beginning to suspect that Bazaar uses that term for
> something different.
>
> What is a “working tree” in Bazaar-speke? What does Bazaar call “the
> actual set of version-controlled files as they currently exist on the
> filesystem”?

The working tree is these files plus the metadata about them which
lives in .bzr/checkout, and remembers their file ids, pending merges,
conflicts, etc.  This is represented, oddly enough, by the WorkingTree
class hierarchy.

-- 
Martin <http://launchpad.net/~mbp/>