tla changes vs. baz status

[Aaron Bentley]

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

Miles Bader wrote:
> On 6/21/05, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 
>>I guess the thing I like about the current output format for bzr is that
>>it's more accessible to new users, because they don't have to read a
>>legend to decipher it.
> 
> 
> Uh-oh...
> 
>    Hi!  The following is a new file in this changeset!!!!
>    Hope you like it :-)  :--O :-/.
> 
>        file1  <--- That's the file name, in case you didn't realize~!!
> 		   :-) lookup "filename" in your windows help file to
> 		   see what that is :-|


What are you trying to do here, make me look like the voice of
moderation? :-)

Seriously, we still get questions like "What's '?M' ?" and "What's '=M'
?" all the time.

And that's only likely to increase, considering how many kinds of
conflicts tla and baz totally ignore, like "Removing versioned directory
that still has contents" and "current permissions don't match ORIG in
changeset" and "wrong old contents patching binary file".

In any case, there seem to be many classes of file status:

File type
=========
file, directory, symlink


Versioning status
=================
In both bzr and Arch, there are 'versioned'/'source' and
'unversioned'/'non-source' files.  Bzr's 'ignored' files correspond
roughly with 'junk'/'backup'/'precious'.  Bzr's 'unknown' files aBzr has
no equivalent for 'unrecognized', or 'un-added source'.

There is also 'missing', which Bzr treats as 'deleted' in the UI.

Comparison status
=================
This is the status of source files wrt another revision, e.g. actual
changeset status.

New/deleted
These refer to the existence of the file or directory.  When files or
directories are created, their permissions are set to initial values.
File contents and symlink contents are also set.

Contents modified
This applies to files only

Target modified
This applies to symlinks only (it is possible to treat the text of a
symlink's target path as its contents).

Metadata modified
In Arch, this refers to Unix file modes, but bzr intends to support more
forms of metadata.

Move/rename
Both of these affect a file's path.  A rename modifies the file's name,
while a move modifies a file's parent directory.  These can be treated
as 'renames' for users, but the implementation needs to differentiate.

Tree-modification status
========================
For merges and inexact changeset application (which I'd say is a form of
merge), there is only one kind of success, but many kinds of failure:

    * Parent directory missing when attempting to add a file
    * Attempt to create directory that already exists
    * Some patch hunks failed to apply
    * While changing permissions, the "old" permissions in the changeset
do not match the file.
    * While replacing contents of a file, the old contents of a file do
not match the changeset
    * Attempt to remove non-empty directory.
    * Attempt to create a symlink when there is already a file/dir/etc
with that name
    * Attempt to apply a patch to a file that does not exist
    * Attempt to remove a file that does not exist
    * Attempt to rename a file that does not exist
    * Attempt to change permissions of a file that does not exist
    * Can't determine filename during three-way merging
    * Can't determine file parent directory during three-way merging
    * Can't determine file permissions during three-way merging

Arch implementations differentiate between binary patching and text
patching, which means that the output of replay doesn't necessarily
match the output of 'changes'.  e.g.

$ tla replay $REVISION
Mb foo.pdf
$ tla changes
M  foo.pdf

Or for some more examples:
$ tla replay $REVISION
?M foo.pdf
$ tla changes
(nothing)

$ baz merge $REVISION
=M foo.txt
$ baz status
(nothing)

Which just goes to show that changeset application and merging status
are different from comparing their results to the last-committed revision.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCuBwC0F+nu1YWqI0RAiMwAJ497mFSFFIXZqSwi3dshv9voeWtXgCeKDlv
RwXTwX4xdxNj/2H3quUu0TU=
=HJSK
-----END PGP SIGNATURE-----