On Mon, May 10, 2010 at 6:24 AM, Stephen Leake < stephen_le...@stephe-leake.org> wrote:
> > It is a minor modification of revert; I factored out the common code. > > undrop just tells revert not to revert a file that is present in the > workspace, because it had changes when it was dropped. > Ahh I see. I've wondered of and on about a few different options to revert. Like --name, --attrs, --content so that it can be a little more fine-grained about what it does. So would something like revert --no-content file be synonymous with undrop at this point? I think there are still some problems lurking in revert as well, for one it leaves renamed things laying around after reverting the renames. I've tried a few times to make revert work based on the editable_tree interface rather than just looking for missing files and recreating them but this turns out to be quite tricky and I've never actually managed to make it work quite right. The last attempt I made did at least get revert upgraded to use roster style checks rather than csets but it still doesn't actually replay the pending changes in reverse. 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. What I really need to do is to go and add a bunch of tests for things like this problem and a few others that I noticed in my thrashing around on Saturday. Cheers, Derek
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
