Re: [Monotone-devel] bugfest analysis

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> On Mon, May 10, 2010 at 3:47 PM, Stephen Leake <
> address@hidden> wrote:
>
>> I think restrictions in general are poorly defined, which is one reason
>> I never use them.
>>
>
> If you say 'undrop file'  you're using them! ;)

Well, yes, that's how the code works. But in this case, I meant I would
not use a restriction on 'undrop' that is different than the restriction
on 'drop'. That's what leads to problems.

> The situation with revert might be better if it did do its work through the
> editable tree interface but getting this to work is difficult at best and it
> leaves open the possibility that revert will fail with mixed
> files/directories in the workspace blocking things from being reverted. One
> up-side of using the editable tree interface would be that revert wouldn't
> leave all kinds of junk laying around after its done.
>
> - Do you have any specific ideas of things that could be defined or
> described better?

The only thing I would change in revert is support for 'revert
--move-conflicting files'. 

Other than that, I haven't had any actual problems with revert. 

I worked on 'undo' because it was bugfest, and it seemed like I might
want that capability sometime. 'undo' and 'revert
--move-conflicting-files' address the same problem in different ways.

> - Is it that the existing documentation doesn't describe what is possible
> well enough?

I guess I've never wanted to revert a rename, or revert something that
depended on a rename. So I've never had to wonder what happens if I try
that.

> - Is it that various commands deal with things in different ways (revert in
> particular, but also add etc.) which makes it feel like they are not well
> defined?

I do as much as possible via Emacs DVC, so I have a different set of
command semantics to worry about. I only worry about mtn command line
semantics when I'm trying to map them to Emacs DVC semantics.

> - Is it that add a/b/c will add a, a/b and a/b/c and then commit a/b/c will
> fail because it has excluded a and a/b?

When confronted with a list of unknown files, I always either add,
ignore, or delete them, individually. They each get a mark in the Emacs
DVC status buffer, so I can see what will happen to each.

> - Is it that filenames are generally resolved against both the old and new
> roster to select nodes to be included or excluded?

This matters only for renames, so I have no experience with this.

> - Is it that the --depth option applies to all specified paths rather than
> to a specific path, allowing different levels of recursion for different
> directories?

I've always wondered whether --depth=0 means no recursion. But I just
avoid using it.

> - Is it that you're not sure what will happen when you're about to say
> commit or revert with a set of paths? The intention is that the changes that
> get selected are *identical* for status, diff, commit, revert and the
> various list commands that apply to paths and there are tests to this
> effect.

That's a good intent.

But in general, commands that operate on a subset of the "natural" set
of files are problematic. 

committing anything other than the full workspace means you've got an
inconsistent state.

I do often exclude specific files from a commit; for example a Makefile
whose only change is specifying which test I want to run today. But such
exclusions are carefully monitored.

I use revert only to recover a known good file. Even then, I normally do
a diff against the earlier version first, and often pick parts to
revert, not the whole file.

status and diff I do for the whole workspace.

So most of this discussion is moot for me.

> I believe that the set of nodes that get included based on a given list of
> paths and --exclude options is completely well defined. 

Yes, that's true.

> Whether this set is well defined for the operation it is used for
> might be another matter though as not all commands can or do use it.

Right; revert renames is a case where it is not.

Each command has different semantics, which interact with the selection.

> I do agree that committing part of a workspace can be considered bad
> practice in that you're essentially committing something that hasn't been
> tested but it happens often enough in reality that it seems like a necessary
> feature. Most other systems out there do allow this so we're not too far out
> in left field.

And most programs are written in Visual Basic (or is it Excel macros?
hard to keep up :). It is a trade-off between acceptance because of
familiarity, and rigor.

-- 
-- Stephe