[Monotone-devel] Re: Serving * does not work
Matthew Gregan [EMAIL PROTECTED] writes: At 2005-10-12T01:17:27+0200, Wim Oudshoorn wrote: When I server all branches with monotone serve 0.0.0.0 * I can not sync from other computers, I get an error something like: access denied due to branch xxx.yyy Using monotone version 0.23. Is this known? You need to escape the asterisk, otherwise the shell will perform glob expansion on it and replace the '*' with a list of files from the current directory. If you run monotone with '--debug' specified, you'll see what's going on because monotone will log the list of command-line arguments that it saw. Try the following, instead: $ monotone serve 0.0.0.0 '*' Cheers, -mjg -- Matthew Gregan |/ /|[EMAIL PROTECTED] As a sidenote, this will happen more often as monotone becomes more widespread, since ppl tend to be confused by tools which implement their own globbing syntax (cf. 'find'). Especially so when it's differing from shell semantics or limited to a subset of it. We had a discussion about this some months ago, and I still think the current approach puts an unnecessary burden on users. Cheers, Bruno. ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Nathaniel Smith [EMAIL PROTECTED] writes: On Tue, May 17, 2005 at 08:00:45PM +0200, Bruno Hertz wrote: Yes, but just because there's a subtle technical difference doesn't mean that people don't expect them to work the same, and won't make mistakes, experience confusion, etc. if they don't... I think it's safe to assume your users have a basic knowledge of shell expansion. E.g. the same applies to find . -name * vs. find . -name *, which people still have to somehow understand. Also, the difference here is in the other direction -- * would potentially include lots of things that _aren't_ included by .. Which really is a bit surprising, no? No. That's the feature you were talking about. Just document it. Maybe we're getting our wires crossed here, because I have no idea what you mean here :-). I can say that making add . and add * different for directories that don't have any dotfiles in them would confuse _me_, and I consider myself a rather savvy user... Where's the confusion? '.' is a directory, so add . means feed a directory to monotone and have it processed according to monotone directory processing semantics. '*' on the other hand is subject to shell expansion, and results into a list of files and directories. So add * means feed a list of files and dirs to monotone and process those objects according to respective semantics. Now, if directory processing semantics means 'recurse and obey ignore rules' whereas file processing semantics means 'do what requested on the file and don't obey ignore rules', as long as this is documented I see little room for confusion. My find example btw was meant to illustrate exactly that point, i.e. in find . -name * the * is processed by find according to it's semantics, whatever that may be. On the other hand, in find . -name * the * is processed by the shell first, giving a presumably totally different result. As I see it, all of the above are standard situations pretty much every user has to deal with on a regular basis. And regarding the 'feature you meant', that was what you were targeting at, right? Override ignore rules by direct file specification. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Nathaniel Smith [EMAIL PROTECTED] writes: On Sat, May 14, 2005 at 12:04:57AM -0700, David Brown wrote: On Fri, 13 May 2005 20:39:31 -0700, Nuno Lucas [EMAIL PROTECTED] wrote: I understand your point. On the other hand there is no way to be fully sure they will always be the same, as * is a shell thing and it's up to the shell to return us the same as . would do (for example, I could have a shell that has an option somewhere to never include a *.my_extension file in the * expansion). Most shells already distinguish these. * in the shell doesn't include filenames that start with a '.'. Yes, but just because there's a subtle technical difference doesn't mean that people don't expect them to work the same, and won't make mistakes, experience confusion, etc. if they don't... I think it's safe to assume your users have a basic knowledge of shell expansion. E.g. the same applies to find . -name * vs. find . -name *, which people still have to somehow understand. Also, the difference here is in the other direction -- * would potentially include lots of things that _aren't_ included by .. Which really is a bit surprising, no? No. That's the feature you were talking about. Just document it. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Nathaniel Smith [EMAIL PROTECTED] writes: On Fri, May 13, 2005 at 02:36:38AM +0200, Bruno Hertz wrote: Nathaniel Smith [EMAIL PROTECTED] writes: On Fri, May 13, 2005 at 12:47:09AM +0200, Bruno Hertz wrote: Nathaniel Smith [EMAIL PROTECTED] writes: How could list unknown behave that would be useful in this situation? If it was possbile to constrain it to a specific directory, it could very well make sense. For example together with an analogue of Emacs PCL-CVS mode for monotone. Hmm: ~/src/monotone/src$ monotone ls unknown | wc -l 101 ~/src/monotone/src$ monotone ls unknown tests | wc -l 4 :-) Ah. I tried monotone ls unknown tests . in the working copy root dir and it still walked the entire tree. 18.1 speaking. Hmm, what did you expect that to do? Recalling our discussion, I originally pointed out revision control could be useful in various situations, like for home dir config files. Monotone doesn't support this well though, even if it technically could, because of unneccesary UI limitations which assume certain use cases. As an example, I said list anything is of no use in such cases. You answered, list unknown would be of no use in such situations anyway. Which, I responded, I doubt, because if the list commands could be constrained to a directory they could still be useful. In our context, what I possibly could have had in mind is of course limiting the command e.g. to the home dir, i.e. not recurse. I thought this was obvious. To you it apparantly wasn't, as your example of 'limiting' a list command to a directory while still including all subdirs was of no relevance at all to our discussion. Had it been, it'd have had invalidated your own statement about the uselessness of list unknown. Still, you got me confused because I didn't expect you to jump out of context that way, and thought I had missed something. As it turned out I hadn't. So finally answering your question, while feeling that I'm becoming quite repetitive at the same time, when I talk about limiting list anything to a directory in such a use case I of course mean a directory without the subdirectories. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Nathaniel Smith [EMAIL PROTECTED] writes: On Thu, May 12, 2005 at 12:28:37AM +0200, Bruno Hertz wrote: Apropos a recent discussion, would this patch prevent monotone from scanning a whole directory tree if the top level dir itself matches an ignore pattern? It's orthogonal. On that point, though -- would it make sense to people that, if ignore_file returned 'true' when given a directory, that everything inside that directory should therefore be ignored? I.e., a file would be ignored iff it itself was not ignored, and furthermore none of the directories containing it were ignored? This should be possible to do, and would presumably help in this case... As I see it, yes and yes. If you think this is counter intuitive, especially with regard to recursiveness and consistent behavior, another approach would be an option to limit recursiveness, although presumably leading to more clutter in this particular case. What we are talking about here is situations where files under revision control are sparse in a directory tree. As an example, consider putting your home directory under revision control for files like ~/.profile or ~/.emacs. In such a scenario, commands like list unknown are pretty much useless right now (18.1 in my case) since they walk the entire home directory tree. To tackle this, obviously there are two strategies: (i) include per default, and exclude on demand (ii) exclude per default, and include on demand. Your suggestion would fall into approach (i), and limiting recursiveness per option either. Approach (ii) was discussed by us in another thread. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Emile Snyder [EMAIL PROTECTED] writes: On Thu, 2005-05-12 at 06:39, Bruno Hertz wrote: What we are talking about here is situations where files under revision control are sparse in a directory tree. As an example, consider putting your home directory under revision control for files like ~/.profile or ~/.emacs. In such a scenario, commands like list Given that monotone is about versioning trees of files, this seems kinda like twisting it out of it's groove to me. Is there a problem with just having a myconfigs project, and symlinking; eg. ~/.emacs to ~/myconfigs-workingdir/.emacs ? Seems cleaner. Well, putting /etc under revision control was a recent svk usage example in a Debian news letter, and it makes sense. The same applies for scenarios like various configuration files in home directories and dot subdirs, like .monotone/ or whatever. And no, I think it's not a good option to 'set up' your home dir for revision control, symlinking all kinds of stuff from various locations. That's the neatness of monotone after all, that it's actually not concerned with directory trees. It's concerned with files, sitting somewhere in a tree. What makes it look like being concerned with trees is the UI only, e.g. the recursiveness we've been talking about, but this is actually just an interpretation, and limitation, of it's capabilities. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Nathaniel Smith [EMAIL PROTECTED] writes: How could list unknown behave that would be useful in this situation? If it was possbile to constrain it to a specific directory, it could very well make sense. For example together with an analogue of Emacs PCL-CVS mode for monotone. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: .mt-ignore and .cvsignore files
Emile Snyder [EMAIL PROTECTED] writes: Well, the fact that a revision refers to the state of a tree of files makes it, in my mind at least, about versioning trees of files. I'm not saying that you can't use it for what you wish, just that it's not a perfect impedance match. Well, what I gather from the manifest is that it's not a tree of files, it's just a set of revisioned content with (pretty arbitrary) pathnames attached to it. The only point where the 'tree' paradigm really enters the picture is with MT, which is supposed to sit on the 'root' of the working copy. But that seems to be all of it. Also, the monotone model is afaik not the least concerned with directories. 90% of the time when I'm using it for version control in a software project I want it to operate recursively, and I have non-sparse tree of files to control. When I imagine sparse tree use cases, I immediately think of lots of cases where I'll want nested MT directories... ie. /home/esnyder under control for config files, /home/esnyder/writing under control for some top level files, /home/esnyder/writing/project-foo under control as project-foo, etc.. In my normal case, the file ignore stuff is used to keep a version control tool from bugging me about useless files; things that I don't care if I lose. But in the sparse tree case, it's getting used to say for *this project* please ignore these files, not that they're inherently unimportant. I'm not trying to argue that, if possible, monotone shouldn't support this sort of sparse tree use. But I would argue that it shouldn't make the current dominant usages less convenient or safe in order to support it. Sure. From where I stand the recursiveness looks like a strength, not a limitation ;) But would be even stronger if the ignores applied (efficiently) to subdirectories as well as files. I never said recursiveness should be prohibited. But as of now, the opposite applies, i.e. one can't prevent recursiveness, which is a serious and unnecessary limitation. Another issue discussed in a different thread was which should be the default, and what the option. But in that regard I've made my points and hence regard the matter as settled. Regards, Bruno. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Newbie questions
Robert Leftwich [EMAIL PROTECTED] writes: I have just started using Monotone and I have a question or two. Firstly, it is not as easy as I would hope to detect when new files are created and are not yet under version control, i.e. monotone status does not list them, I need to use list unknown - requiring at least two operations to get the full picture. A VCS that does not list new or deleted files in its main status command seems somewhat counter intuitive to me or is this a fundamental mind shift I need to make? I for one don't understand where the fundamental mind shift would be, maybe you want to explain from where you're coming. But being myself new to monotone either, I wouldn't expect the status command do anything else than report on the files which are under revision control. Especially when commands for extra info are available and customized summaries can be scripted. As to deleted files, afaik files under revision control which are deleted are reported by the status command. So if you're implying you want monotone to automatically keep track of any file added or deleted in the working copy directory tree, I think you're heavily extending the responsibilities most people would like to impose on an scm system. Secondly, maybe I'm abusing Monotone a little, but in one project I have a very large number of generated graphs that I don't need to include under version control, so I've added that directory name regex to the ignore_file() function in .monotonerc. While this works as expected, in normal operation it slows things down dramatically, especially when checking for newly created files, but it impacts almost every operation. Is there an alternative set-up or some command switch or function I can use to get Monotone to truly ignore the graph directories rather than traversing them each time? Note that I've tried symbolic links but Monotone appears to follow those as well. Didn't test that myself, but from what you describe it seems that monotone traverses the entire tree in any case and hence only runs full file paths through the ignore hook. If so, I'd agree that could and should be done better. The problem would be though, with this rule based, hooked ignore mechanism, how to detect resp. communicate exact matches on directories. That's presumably a design flaw, and the rule based approach maybe should be complemented by a .cvsignore file analogue in MT or something. 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: 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
[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
