On Wed, Oct 15, 2008 at 02:52:34PM +1100, Daniel Carosone wrote:That is a good question! I had assumed it would resolve my name
> The confusion comes from the way names are specified for restrictions
> - in short, are you using the name of the file it has now, or the name
> it had in the revision you're asking for.
relative to my current workspace state, but clearly that is not the
It's trying to resolve the name to a roster node id (the stable thing that doesn't really care what it's called or where it's located at the moment) and to do this names are checked against one or two rosters (base and maybe current) to see what they might match.
Perhaps I should review the manual. Hrm.
Yeah I figured that was part of it.
> I think in your specific example, it's made worse because you're
> using relative paths within a subdirectory of the workspace, where
> the actual rename was on a parent of that dir.
How hard would it be to implement? That is just some surface syntax
> We talked about a way to be explicit about this (a syntax for
> address@hidden) but it hasn't been implemented AFAIK.
that boils down to a content hash (or revision id? I don't really know
how Monotone's internal structures work) and then goes into the normal
logic chain of the existing commands, right?
I don't think it should be all that hard. The various restriction constructors would probably have to take a db argument to fetch rosters for revisions specified with @revision on a pathname. There might be some path shenanigans though, in the various places that use args_to_paths, since a path would have to allow @revid. I'm not sure if this would be a big deal or not. Once the names have been resolved to node id's in the restriction I think everything else would probably work just fine. This probably only makes sense for commands dealing with historical revisions (diff,log) but not others dealing with the current workspace (status,commit).
For your diff ,you should be able use the current pathname, or the pathname in the revision you're attempting to compare with. I'm not sure why that's not working. Apparently we need some more tests.