On Mon, May 10, 2010 at 3:47 PM, Stephen Leake
<address@hidden> wrote:
I don't know; "--no-content" to me sounds like "don't revert content,
just renmaes and other stuff". That's not the same as 'undrop', which
does revert content if the file actually got deleted from the workspace.
Fair enough, I now see where you're coming from. I don't think I've ever used the --bookkeep-only option so I've never ended up with a file in such a state.
> One thing I noticed in trying to fix the diff bug was this:
>
> $ mtn mv dir dir2
> $ edit dir2/file
> $ mth revert dir2/file # only reverts content, leaves directory rename in
> place
> $ edit dir2/file
> $ mtn revert dir2 --depth=0 # should revert the rename and leave the content
> change but fails
>
> it would be good to get this sorted out too.
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! ;)
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?
- Is it that the existing documentation doesn't describe what is possible well enough?
- 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?
- 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?
- Is it that filenames are generally resolved against both the old and new roster to select nodes to be included or excluded?
- 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?
- 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.
I believe that the set of nodes that get included based on a given list of paths and --exclude options is completely well defined. 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. For example add doesn't have a set of nodes to select from so it has to do something slightly different.
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.
Cheers,
Derek