Re: [Monotone-devel] Re: CLI / path restrictions.
On Fri, May 06, 2005 at 10:27:49PM +0200, Bruno Hertz wrote: Hmm. Looking at common tools (like ls, chmod or whatever), restriction to pwd is the default, and recursiveness must explicitly be requested, like per '-R' option (OK, not possible with ls, of course). 'find' is one of the notable exceptions, where recursiveness is the default, and limitation to pwd or level of recursiveness is requested per 'maxdepth'. I've seen the term 'depth' already being used somewhere, I think it was the revision history depth of the log command, so there might be some risk of confusing people. (chmod acts on a whole directory as a unit too, though in a different sense...) Yeah, --depth is taken. Could use --prune or something, like find, I guess? But to meet user intuition somehow, I guess either of the above approaches might serve as a model. It actually had never occurred to me that one might expect giving a directory to mean only the first level of stuff in that directory; maybe we need a straw poll on what people's intuitions here are? Part of the problem is that commit dir/ just can't mean commit changes in the top level of dir/, but nothing below that. I mean... I dunno, I can't imagine that being reasonable. So, there's a theory which says that everything else should be consistent with commit -- for diff and status, I think, this argument is very powerful; diff foo should show exactly the same changes as commit foo will commit. Works for revert too, really; diff should show exactly what revert will throw away. For the ls family of commands, I guess one could make an argument either way; consistency with ls(1) vs. consistency with the rest of monotone. [snip] Generally, I'm wondering whether it's possible to get rid off the requirement the user entering MT relative paths at all, e.g. by taking pwd into account. Yeah, that we haven't already is just a bug. Do you know of any commands besides log that do this? Not right now, but if you are interested in reports I might give them as I go through the features resp. give summaries at specific points. I don't think there are any others, but if you do find some, please let us know! First though I hope to maybe ask some other questions in the near future which have been kind of puzzling me these recent days ... Please feel free... -- Nathaniel -- ...these, like all words, have single, decontextualized meanings: everyone knows what each of these words means, everyone knows what constitutes an instance of each of their referents. Language is fixed. Meaning is certain. Santa Claus comes down the chimney at midnight on December 24. -- The Language War, Robin Lakoff ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: CLI / path restrictions.
Nathaniel Smith [EMAIL PROTECTED] writes: It actually had never occurred to me that one might expect giving a directory to mean only the first level of stuff in that directory; maybe we need a straw poll on what people's intuitions here are? Who ever called 'ls' with a directory name as param might think different. Shell expansion is non recursive either. Actually, most commands work non recursive without explicit request. Take rm -rf as another example. Part of the problem is that commit dir/ just can't mean commit changes in the top level of dir/, but nothing below that. I mean... I dunno, I can't imagine that being reasonable. So, there's a theory which says that everything else should be consistent with commit -- for diff and status, I think, this argument is very powerful; diff foo should show exactly the same changes as commit foo will commit. Works for revert too, really; diff should show exactly what revert will throw away. For the ls family of commands, I guess one could make an argument either way; consistency with ls(1) vs. consistency with the rest of monotone. If you want directory restrictions to act recursively per default, please do so, I for one don't really care. But providing the means to limit the level of recursiveness would still make an awful lot of sense. Apart from that, if 'commit .' committed the files in pwd only I really can't say I'd be that surprised. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: CLI / path restrictions.
Bruno Hertz wrote: Who ever called 'ls' with a directory name as param might think different. Shell expansion is non recursive either. Actually, most commands work non recursive without explicit request. Take rm -rf as another example. conversely, cvs diff dir etc. do act recursively, iirc, and can be told to not recurse with -l, which is where I pulled the idea for --local from. If you want directory restrictions to act recursively per default, please do so, I for one don't really care. But providing the means to limit the level of recursiveness would still make an awful lot of sense. Apart from that, if 'commit .' committed the files in pwd only I really can't say I'd be that surprised. certainly, given the same args and possibly --local option, commit, status, diff, revert should all act on the same things! Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: CLI / path restrictions.
Derek Scherger [EMAIL PROTECTED] writes: certainly, given the same args and possibly --local option, commit, status, diff, revert should all act on the same things! Sure. Without path spec on the entire working copy, else on the path(s) specified. And, as said, after taking the pain of abstracting the internal model of monotone from the filesystem paradigm at all, thus making them pretty much orthogonal, I think it's an appealing idea to let the UI just behave like any other *nix tool. Among the automatic benefits, a smoother learning curve, predictable behavior and letting users take advantage of shell globbing are just some examples. I think others could easily be found, especially in scripted environments, where committing or diffing might be just one of the tasks to be performed on a given file or path list. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: CLI / path restrictions.
Nathaniel Smith [EMAIL PROTECTED] writes: On Fri, May 06, 2005 at 07:37:36PM +0200, Bruno Hertz wrote: while the user interface might currently not be top priority, are there still any plans to allow for non-recursive path restrictions, e.g. for list various ? Hardest part is coming up with a sensible way for the user to express this desire -- any suggestions? Hmm. Looking at common tools (like ls, chmod or whatever), restriction to pwd is the default, and recursiveness must explicitly be requested, like per '-R' option (OK, not possible with ls, of course). 'find' is one of the notable exceptions, where recursiveness is the default, and limitation to pwd or level of recursiveness is requested per 'maxdepth'. I've seen the term 'depth' already being used somewhere, I think it was the revision history depth of the log command, so there might be some risk of confusing people. But to meet user intuition somehow, I guess either of the above approaches might serve as a model. Also, remotely related and fyi, while diff takes a base name as an argument, log requires a path relative to MT, which some people might consider an inconsistency. Yeah, that's a stupid bug in log. It never got updated to use Derek's no-longer-so-new restrictions stuff. It'd be really nice if it could interpret the pathname correctly (using the same code that, umm, all the other commands that take pathnames use), and if it could take multiple filenames/directories, like all the other commands that restrict to part of the tree... This especially since monotone does up-dir traversal anyway, to find MT. I.e. the relative path to MT is always known, and having to specify it always redundant. Though I guess the semantics of listing a directory are not totally clear; if I say 'log foo/', and there's a file foo/bar that used to be in some other dir, should the log include edits to foo/bar before it was in this dir? if there used to be a file called foo/bar but is no longer, should the log include edits to foo/bar when it was in this dir? I guess my feeling is that log should do something like: for each rev in history: update list of explicitly mentioned files and directories according to any renames that happened on the edge just traversed if this revision has any changes that touch any file that matches anything in the updated list, output this revision The idea being that anything the user explicitly mentioned on the command line, we track its logical lifetime, over renames and all that. And for those which are directories, we reinterpret this restriction again for each historical revision. So the answers to the questions above are that we don't include edits to baz/bar even though it will later become foo/bar; and we do include edits to foo/bar even though it will later become baz/bar. You take the discussion one step further than originally intended, as the above 'dilemma' of course applies independent of how I have to specify a path for log. It's rather a consequence of monotone supporting renames by making trees the primary object of revisions, which is a good thing, btw, and very neatly solved (although, as a sidenote, from what I understand from the docs there's a one to one relationship between revisions and manifests, making me wonder whether there's a redundancy either ...). Anyway, regarding your concern, I guess the log of a dir resp. the content of a dir should contain the actions which happened on that content at each particular revision step (I'm skipping merges for now, since I'm actually no scm geek and have no clear picture on how to proceed in those cases - an issue I've been thinking about these days when wondering about how to present a diff history of a single file). Anyway, as much as a file 'enters a directory' by adding, it basically does the same by renaming. Regarding the directory, the file did not exist there before, and that I think should be the general and imho pretty intuitive semantics of log. Of course, log should report the rename action as such, and in particular what the previous name was. If this was agreed upon, the other direction would follow. I.e. if a file was renamed some time ago and thus left the dir, the log would include the file history up to that point, in analogy to a file removal (you might add here that renaming actually is a re-mv-al on *nix like systems). This way, the complete history of a file is covered, admittedly at then maybe different places but in a clean, logical and consistent fashion users I believe will have no problem with. Even more, users accustomed to thinking in categories of files, directories and paths will presumably perceive any other approach as confusing. Generally, I'm wondering whether it's possible to get rid off the requirement the user entering MT relative paths at all, e.g. by taking pwd into account. Yeah, that we haven't already is just a bug. Do you know of any
