On Mon, Oct 03, 2005 at 08:43:12AM -0700, Nathaniel Smith wrote: > If we do the "magic selectors" thing that another thread has been > throwing around, the above is spelled > $ monotone diff -rB: -rU:
exactly my point (modulo 'diff -q' to just get the filenames :) > > If we imagine these two queries renamed as something like: > > $ monotone list uncomitted (or local_changes?) > > $ monotone list updates (or branch_changes, head_changes, ..?) > > Hmm, not sure; "list" seems to be kind of over-used and confusing > already... Well, ponder on it a while, but at least "uncommitted" (or similar name) seems to me as exactly the right place for the list of filenames you had as "the bottom part of status --brief" in your earlier mail. The fact that there are lots of things you might want to list doesn't make it wrong, even if some of them turn out to be basically convenience shorthand aliases for something else, as above. Another list might be "unmerged"; the files with divergence between the current heads; again it might be convenience shorthand for cutting and pasting hexid's reported by "heads" to "diff", or magic selectors. Especially as a new user, having visibility of what's about to happen safely helps me gain confidence and understanding of the software. I can easily imagine using sdiff or some set-type operations with shell tools to find interesting intersections of these lists. union(updates, missing) might represent files I have edited offline, but someone has deleted from the fileserver, for example (see awkward use-case, below). Dunno, but this seems like a good way to discover useful common queries that could be added later, too. What does seem to be a little mixed up with list is that some lists relate purely to the repository, some more to the working dir. I'm not sure it's a problem, but something to keep in mind for future, or even just for clarity in doc work. > > Because branches are sticky, but revisions and tags and other checkout > > selectors are not, "out of date with respect to the branch" is also an > > important part of the status of a working directory. > > Interesting point. I'm a little dubious about scaring users by > sticking in a "working copy is out of date" line in, because it will > encourage people to think like that means they _should_ update, which > is the sort of thinking we'd like to train people out of... Yeah. I was just following a line of thought - factoring out the hypothetical list form, I was trying to find a sensible definition of "status" that wasn't redundant, but also wasn't horrendously detailed (like inventory). It already seems to combine key useful facts from several other queries, I guess it's a matter of picking which are most relevant. To wit: > > Ideally, "status" would consolidate and summarise (rather than > > concatenate) information I can get from more specific commands. A brief form might even list just file counts: 6 files changed locally, 3 deleted, ...". This highlights "status" as a quick summary query for "what other queries do I need to look at more carefully?". I take your point about training users' thinking by what you display (I made similar comments recently in another thread), but be careful of assuming too much about how people will use the software. Some checkouts exist purely for being updated (never intended to have local changes), but the update step must be done only under certain conditions: a copy of html content in the production web server's doc root is a common example. Other constraints can apply that break the intended usage practice; more examples below. Granted, the common reporting output should support the common/recommended usage practice, so long as the information needed for more advanced usage is available in more advanced queries. > > Sometimes I just want to know > > "will I lose anything if I blow away this old checkout?" (in which > > case I should also "list unknown", hmm..) > > Yeah, and even "list ignored", possibly... Maybe so, yah. I've included a more verbose discussion of some of my use cases below, to illustrate some of the motivation and perspective behind my comments. The ignored case isn't so important for dirs I'm likely to ever consider blowing away at all, at least for my usage. I use CVS (and now monotone) for keeping revision history and cross-machine replication of a lot of in-place files: my ~, /etc, stuff on file shares I need access to offline, and so on. This is different in that often I'm the only user of the VCS, but I must account for changes others make outside the VCS in the working dirs. CVS warts make this hard, but I've been doing it this way for many, many years and I've found ways to work with them; monotone is turning out much better. In at least one respect, monotone is exactly what I need for this, because there's no common point of connectivity from all machines for a CVS repository. I keep a .monodb on a flash widget, and netsync locally with that as I move around some sites (being selective about which sites see which branches). I was glad to see others with similar perspectives recently, and SNAIL is a great term :) I'd make much heavier use of it, but for the horrendous CPU usage with large files; I'd like to use it for replicated mp3 files, digicam pics, etc, too. These are collections that are added to, and sometimes rearranged, but rarely deleted (so the db size is manageable). I have high hopes for the string-handling fixes I see being discussed. Anyway, the point being that I often need to ignore a lot of files, because the directory structure isn't my choice and I'm only interested in partial subtrees. I don't want to blow the primaries away, but I might blow away working checkouts (which are unlikely to hold ignored files, and which are entirely mine). It's also why I'm often keenly interested in what damage I might do next time I update, and in the contents of the various lists more generally. I also use CVS with nested checkouts to deal with some of this in-place structure; for example my ~/Mail is in a different repository to ~, because it's large and private and I don't want it checked out or netsync'd on all machines. Thus ~/.cvsignore lists Mail. On update, CVS will happily recurse from ~ into Mail, find a new CVS/Repository, and work from that - but in this case I don't want it to, so I stop it with ignore. I haven't yet tried this with monotone, but expect it will need to work this way always if nesting; I'm about to try with the new .mt-ignore stuff. A quick test just now suggests that "cp .cvsignore .mt-ignore" DTRT. -- Dan.
pgp0l3X2ufnFl.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
