b.w.WorkingTree(bzrlib.mutabletree.MutableTree, controldir.ControlComponent) : class documentation

This is true IF and ONLY IF the filename is part of the meta data that bzr controls in this tree. I.E. a random .bzr directory placed on disk will not be a control file for this tree.

Uses the ui factory to ask for confirmation if the lock may be from an active process.

This will probe the repository for its lock as well.

This probes for a working tree at path and searches upwards from there.

Basically we keep looking up until we find the control directory or run into /. If there isn't one, raises NotBranchError. TODO: give this a new exception. If there is one, it is returned, along with the unused portion of path.

Fail if the paths given are not all in a single tree.

This is used for the many command-line interfaces that take a list of any number of files and that require they all be in the same tree.

Only intended for advanced situations like upgrading part of a bzrdir.

If the left most parent is a ghost then the returned tree will be an empty tree - one obtained by calling repository.revision_tree(NULL_REVISION).

The path may be absolute or relative. If its a relative path it is interpreted relative to the python current working directory.

This implementation reads the pending merges list and last_revision value and uses that to decide what the parents list should be.

Duplicate this working tree into to_bzr, including all state.

Specifically modified files are kept as modified, but ignored and unknown files are discarded.

If you want to make a new line of development, see ControlDir.sprout()

revision

If not None, the cloned tree will have its last revision set to revision, and difference between the source trees last revision and this one merged in.

This is equivalent to retrieving the current list of parent ids and setting the list to its value plus revision_id.

This is equivalent to retrieving the current list of parent trees and setting the list to its value plus parent_tuple. See also add_parent_tree_id - if you only have a parent id available it will be simpler to use that api. If you have the parent already available, using this api is preferred.

This checks that the left hand-parent exists if there are any revisions present.

This will always return the first revision_id, and any merged revisions which are

See also set_parent_trees. This api will try to retrieve the tree data for each element of revision_ids from the trees repository. If you have tree data already available, it is more efficient to use set_parent_trees rather than set_parent_ids. set_parent_ids is however an easier API to use.

The default implementation assumes no stat cache is present.

The list is initialized by WorkingTree.set_merge_modified, which is typically called after we make some automatic updates to the tree because of a merge.

This returns a map of file_id->sha1, containing only files which are still in the working inventory and have that text hash.

A new branch will be created, relative to the path for this tree.

Lists, but does not descend into unversioned directories. This does not include files that have been deleted in this tree. Skips the control directory.

to_dir must be known to the working tree.

If to_dir exists and is a directory, the files are moved into it, keeping their old names.

Note that to_dir is only the last component of the new name; this doesn't change the directory.

For each entry in from_paths the move mode will be determined independently.

The first mode moves the file in the filesystem and updates the working tree metadata. The second mode only updates the working tree metadata without touching the file on the filesystem.

move uses the second mode if 'after == True' and the target is not versioned but present in the working tree.

move uses the second mode if 'after == False' and the source is versioned but no longer in the working tree, and the target is not versioned but present in the working tree.

move uses the first mode if 'after == False' and the source is versioned and present in the working tree, and the target is not versioned and not present in the working tree.

Everything else results in an error.

This returns a list of (from_path, to_path) pairs for each entry that is moved.

This can change the directory or the filename or both.

rename_one has several 'modes' to work. First, it can rename a physical file and change the file_id. That is the normal mode. Second, it can only change the file_id without touching any physical file.

rename_one uses the second mode if 'after == True' and 'to_rel' is either not versioned or newly added, and present in the working tree.

rename_one uses the second mode if 'after == False' and 'from_rel' is versioned but no longer in the working tree, and 'to_rel' is not versioned but present in the working tree.

rename_one uses the first mode if 'after == False' and 'from_rel' is versioned and present in the working tree, and 'to_rel' is not versioned and not present in the working tree.

Everything else results in an error.

These are files in the working directory that are not versioned or control files or ignored.

When a file_id is unversioned, all of its children are automatically unversioned.

If there are any unversioned directories then only the directory is returned, not all its children. But if there are unversioned files under a versioned subdirectory, they are returned.

Currently returned depth-first, sorted by name within directories. This is the same order used by 'osutils.walkdirs'.

Cached in the Tree object after the first call.

Patterns containing '/' or '' need to match the whole path; others match against only the last component. Patterns starting with '!' are ignore exceptions. Exceptions take precedence over regular patterns and cause the filename to not be ignored.

If the file is ignored, returns the pattern which caused it to be ignored, otherwise None. So this can simply be used as a boolean if desired.

This format tree does not support a separate marker for last-revision compared to the branch.

See MutableTree.last_revision

This also locks the branch, and can be unlocked via self.unlock().

This is used to allow WorkingTree3 instances to not affect branch when their last revision is set.

WorkingTree can supply revision_trees for the basis revision only because there is only one cached inventory in the bzr directory.

WorkingTree locking just uses the Branch locking facilities. This is current because all working trees have an embedded branch within them. IF in the future, we were to make branch data shareable between multiple working trees, i.e. via shared storage, then we would probably want to lock both the local tree, and the branch.

Update a working tree along its branch.

This will update the branch if its bound too, which means we have multiple trees involved:

• The new basis tree of the master.
• The old basis tree of the branch.
• The old basis tree of the working tree.
• The current working tree state.

Pathologically, all three may be different, and non-ancestors of each other. Conceptually we want to:

• Preserve the wt.basis->wt.state changes
• Transform the wt.basis to the new master basis.
• Apply a merge of the old branch basis to get any 'local' changes from it into the tree.
• Restore the wt.basis->wt.state changes.

There isn't a single operation at the moment to do that, so we:

• Merge current state -> basis tree of the master w.r.t. the old tree basis.
• Do a 'normal' merge of the old branch basis if it is relevant.

returns a generator which yields items in the form:

((curren_directory_path, fileid),

[(file1_path, file1_name, file1_kind, (lstat), file1_id,

file1_kind), ... ])

This API returns a generator, which is only valid during the current tree transaction - within a single lock_read or lock_write duration.

If the tree is not locked, it may cause an error to be raised, depending on the tree implementation.

Only text conflicts are auto_resolvable. Files with no conflict markers are considered 'resolved', because bzr always puts conflict markers into files that have text conflicts. The corresponding .THIS .BASE and .OTHER files are deleted, as per 'resolve'.

This is meant mostly for the test suite. To give it a chance to detect corruption after actions have occurred. The default implementation is a just a no-op.

This does a hard-reset to a last-known-good state. This is a way to fix if something got corrupted (like the .bzr/checkout/dirstate file)