Re: [Monotone-devel] rfc on h: selector behavior
On Fri, Oct 14, 2005 at 07:32:08AM +1000, Daniel Carosone wrote: I'm also not sure that all of these requirements and usages are satisfied by simply 'magic selectors'. I've been thinking for a while that we might be needing some form of selector algebra on the command line. What if we could use the erase_ancestors() syntax, and other set and tree operations, directly? The 'fantasy syntax' lca: examples given recently are a really good illustration of what i've been thinking, too. It might start with an OR operation in selector strings, to complement the / for AND. Many of the magic selectors are then just some syntactic sugar around frequently used longer forms. Well, it'd certainly be interesting to look at ideas for how to make this syntax work. I'm not sure the goal is to make the _perfect_ general purpose revision selecting machinery, though -- it seems like at some point you want to just switch over to your existing general purpose tools (like sh, or a scripting language, or the like), and the existing automate commands are IME quite composable for expressing complex rules like that. So the real question might be not what's useful, but where should the switchover point be... I guess the comparative rarity of decent scripting on win32 might be an argument for more power before having to switch over; dunno. -- Nathaniel -- On arrival in my ward I was immediately served with lunch. `This is what you ordered yesterday.' I pointed out that I had just arrived, only to be told: `This is what your bed ordered.' -- Letter to the Editor, The Times, September 2000 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
Nathaniel Smith wrote: I guess the comparative rarity of decent scripting on win32 might be an argument for more power before having to switch over; dunno. Whatchoo talkin' about, Willis? There are freely-available Windows ports for all the popular scripting languages (and even a few decent ones). Anyone interested in building complex selectors--or using other people's scripts to do so--can download any language they need. Sure, they don't come pre-installed with the OS, but then neither does monotone. So I don't think that's a serious impediment. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
In message [EMAIL PROTECTED] on Fri, 14 Oct 2005 07:32:08 +1000, Daniel Carosone [EMAIL PROTECTED] said: dan It might start with an OR operation in selector strings, to dan complement the / for AND. Just a small point: it's a little odd to me to express selectors in terms of OR and AND. I do understand that your idea is drawn from binary arithmetics, but it might be confusing to some considering there's also a conditional meaning to AND and OR, see for example the C operators and ||. It might be better to express these combined selectors in terms of UNION and INTERSECTION. I find those words much more precise in this matter. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] rfc on h: selector behavior
Hi all, Do people think that an h:branch selector to find the heads of a branch should accept globbing wildcard characters like the b: selector? So if you said a:bozo/h:com.circus.* it would select any head of a branch in the com.circus.* set authored by bozo. There has been concern expressed on IRC that globbing needlessly complicates things. Also, that it's not clear whether h:* should mean erase_ancestors(b:*) or union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) Any opinions? thanks, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
In message [EMAIL PROTECTED] on Thu, 13 Oct 2005 00:15:41 -0700, Emile Snyder [EMAIL PROTECTED] said: emile [...] Also, that it's not clear whether h:* should mean emile emile erase_ancestors(b:*) emile or emile union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) emile emile Any opinions? Actually, this transends to any globbing pattern. After all, does h:com.circus.* mean `erase_ancestors(b:com.circus.*' or `union(erase_ancestors(b:com.circus.b1), erase_ancestors(b:com.circus.b2), ...)'? Tough question, and I'm not sure I've the answer... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
On Thu, Oct 13, 2005 at 09:44:03AM +0200, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 13 Oct 2005 00:15:41 -0700, Emile Snyder [EMAIL PROTECTED] said: emile [...] Also, that it's not clear whether h:* should mean emile emile erase_ancestors(b:*) emile or emile union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) emile emile Any opinions? Actually, this transends to any globbing pattern. After all, does h:com.circus.* mean `erase_ancestors(b:com.circus.*' or `union(erase_ancestors(b:com.circus.b1), erase_ancestors(b:com.circus.b2), ...)'? Yeah, sure, 'twas just an example. Tough question, and I'm not sure I've the answer... We couldn't decide on IRC either, so we figured we would be lazy and poll the list :-). The overall question was should we allow globs at all, too. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
On Thu, 2005-10-13 at 00:15 -0700, Emile Snyder wrote: Hi all, Do people think that an h:branch selector to find the heads of a branch should accept globbing wildcard characters like the b: selector? So if you said Ok, no one argued against it, there were a couple of lukewarm might be useful, and it preserves consistency. I'm gonna go ahead and check it in; if anyone feels it's the wrong choice it's easy to turn off. erase_ancestors(b:*) or union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) This seems like a thornier question. I still feel like the union() one follows the least surprise principle better. If anyone feels like the ambiguity of which it will do makes either answer surprising, we can turn it (globbing the h: value) off. Thanks all, -emile signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
[Be warned, idle late-night musings, finished in the morning pre-coffee..] On Thu, Oct 13, 2005 at 01:34:21AM -0700, Emile Snyder wrote: emile erase_ancestors(b:*) emile or emile union (erase_ancestors(b:b1), erase_ancestors(b:b2), ...) For what it's worth, my expectation as a user would be the union(heads(b1), heads(b2), ...), ie., interpret h:branchglob to mean heads of the specified branches agreed. put it another way, if h:com.foo.* doesn't mean the heads of all those branches, what does? because that's something i'm likely to want. A good way to think about these kinds of choices is if i had both, what would I call them to tell them apart? What result does the other interpretation give you -- and can you think of a better selector name for that operation? The erase_ancestors(b:*) case gives you all the heads that aren't also branch points for other branches within the glob.. Put another way, the dead-ends of code development for a namespace. If I'm looking for meta-heads across the combined span of multiple branches, it's probably because I'm looking for changes to propagate between branches - these heads represent all the points i'd need to propagate in order to reconnect the branches, probably to the name-space parent. In monotone terminology, 'heads' are microbranches, divergence within a branch resolved with 'merge'. I really do think the union form, representing the heads of all the branches matching the name glob, is most consistent with that terminology. The cross-branch form might be called propagation points or something similar, and the selector would return a propagation set of revisions, and be named accordingly. (What about the inverse? Is there a selector for the divergence point of a branch from its parent? it's common CVS practice to put a branch tag on that point, for later reference - such a selector in monotone would make that unnecessary.) I'm also not sure that all of these requirements and usages are satisfied by simply 'magic selectors'. I've been thinking for a while that we might be needing some form of selector algebra on the command line. What if we could use the erase_ancestors() syntax, and other set and tree operations, directly? The 'fantasy syntax' lca: examples given recently are a really good illustration of what i've been thinking, too. It might start with an OR operation in selector strings, to complement the / for AND. Many of the magic selectors are then just some syntactic sugar around frequently used longer forms. Note also that the cross-branch usage assumes something about the namespace construction - or at least relies on namespace conventions for greatest utility. Lets say I wanted to find all the loose ends of foo.experimental.* branches. A different syntax would let me or together several specific branch names and then take some operation (such as either of these) on that. -- Dan. pgp5FANDIpNpH.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
