darcs monotone bazaar-ng codeville svk git || logs: http://www.loglibrary.com/126 So I think vestabot will now log #revctrl. Of course I've done more with it today than ever before, and it won't write out the log file until midnight Eastern US time, but it seems to be all set. oh, so you added your bot Yes, just now. you dont like the colabti logger ? It's got some other handy features too, like: vestabot: seen feb feb was last seen 70 seconds ago, saying 'you dont like the colabti logger ?' in #revctrl. funny. feb: I don't have any problem with colabti, but it didn't seem to be logging anything for #revctrl yet. you can get the same info with whois without annoy everybody with it the colabti bot wasn't up because we didn't tell feb to do it with a channel this large it'll be hard to get consensus i was just gonna run it by zooko when he reappears, but it probably doesn't even matter Anyway, redundancy is good. I can turn it off at any point. indeed, i didnt start the bot before being sure it was ok. i can add it or not. As you wish vestabot: seen jemfinch jemfinch was last seen 10 weeks, 2 days, 2 hours, 22 minutes and 57 seconds ago, saying 'no problem :)' in #vesta. You can send the bot a private message for that too. :) vestabot: help feb: help info /msg'ed xorian: help. I ran some command on vestabot and it doesnt stop talking for anybody who would like a detailed explanation of the criss-cross merge problem - http://www.gelato.unsw.edu.au/archives/git/0504/2279.html I wonder if that post will generate discussion, or just get ignored actually, i believe for a naive diff + patch approach to 3-way merge, picking A as the ancestor silently drops changes or maybe not I think that currently git will pick B or C at random feb: I aksed the real bot admin, and he says: you can tell it to "shutup" and that will make it dump all of it's queued output, which is a standard mozbot feature. xorian: thanks. i'm guessing you won't get a response and i wouldn't bother posting again, since linus obviously doesn't want any help yeah, well, I wanted to make it clear to anyone who was willing to spend a few minutes going over the example that I do, in fact, have a point is linus doesn't respond it will probably be just less stress for me. It wouldn't surprise me if he doesn't even read that post if linus I mean let him rediscover all the problems which everyone else has already solved that's the way he wants it with the current shitty ancestor picking it's gonna lose a whole buttload of work in the process unless pasky does per-file ancestor picking under the hood without permission or something :-) actually, I'm guessing won't read that post, because he already outright declared that I don't know what I'm talking about, and reading that post might make him realize that I do in fact have a point, and he doesn't want to hear that yes, now go spend time on something useful :) like fixing up the fancy new lcs code yeah, that's what I was thinking lcs = Least Common S??? longest common subsequence new diffing code Ah. The similarity with "lca" had me confused. you have your own diff code in cdv? doing anything special? for one, it's a portability issue, since there's no diff on windows but it's got some customization to make the conflicts and diffs more readable parsing the diff output also sucks if you have to do anything with the patches ;) hmm? cdv diff produces output which can be used by patch our internal deltas look different, though, they use the same internal matching code do you use the myers algo? bram mentioned something about only 3 times slower than gnu diff (with pure python code) i meant that you have to parse the gnu diff output if your internal storage differs from diffs output. i don't know all the details of the new code we're using a reasonably nontrivial algorithm for lcs, but it's n*log(n), not n*log(log(n)) which is technically the fastest but not in practice that's why darcs has lcs code too (and arch probably not) we're pulling out the lines which only occur once on each side first before doing the lcs, then doing the lcs. This allows for some substantial speedups, as well as more reliable behavior we have dependency on external tools like diff have no dependency you mean no dependency yeah, we're doing that too (removing lines that only occur in one of the files) beschmi, it's also good to remove ones which occur multiply on either side, then extend matches over the unique lines to cover them imagines what happens when FSF relocates from 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ;) pasky, I'm missing the joke, I don't recognize that address myriads of GPL'd software have this standard n-lines long copyright crap at the top ending with this address there was a new minor version of the GPL changing the address recently ;-) where did they move to? xorian: I caught the tail end of a conversation involving mozbot, what was it about? jemfinch: I've had our mozbot instance (nick=vestabot) join this channel, since loglibrary doesn't seem to be logging. Logs will appear in the same place as the #vesta logs. ah, ok. is mozbot still under active development? jemfinch: I don't really know. Someone else runs vestabot, he just gave me admin privs and I told it to join here. ah, ok. i wonder about which "false paths -- imaginary (unrealizable) ideals about how things like merging can work and be good." is talking ;) that should be: Tom Lord is talking on the git list i have to admit i find it weird to be agreeing with tom lord beschmi: url for that ? http://article.gmane.org/gmane.comp.version-control.git/1976 what's especially funny about that previous post is that before linus started using bitkeeper he had all kinds of opinions about what his needs were ... and then changed his workflow to behave exactly the way bitkeeper does lifeless, bit faster for us is: http://www.gelato.unsw.edu.au/archives/git/0504/2357.html I don't see why tl is trying to kiss lt's ass though Bram, i don't think that's quite right. he made lm change bk quite a bit i believe mlh, I'm going by what he said he wanted when bk first started being used, and what I know for a fact bk actually supports which happens to be almost identical to what codeville supports or what monotone supports for that matter (darcs has better cherry-picking, so for the time being it's ahead on features) but basically his claim that he knows what a tool should do better than everybody is, uh, wrong not sure he's saying that. he's saying: 1. he wants speed. 2. he wants to understand what the tool does quoting here: The _only_ reason I started git in the > first place is that I knew better than pretty much anybody else what my > needs were, and I was forced to act on them because nothing out there > really solved the problem for me. I dunno, that seems pretty clear to me, unless he thinks that 'fast' was far too deep a concept for anybody else to understand that's the story of free scms though isn't it? often speed is forsaken in favour of features/maintainability. afaics thats the case for mt,tla,darcs. (i don't have any experience with cdv) Bram: I think he believes he's made something faster than the alternatives at the operations he cares about. And he might be right, for the initial git implementaiton, but I'm sure making it do something more useful will slow it down. :) xorian, it already sucks for networking operations, which are the ones which take all the time anyway it's only marginally passable at those because they threw out the history mlh, in some cases that's true, but monotone and cdv work just fine Bram: Yeah, but he clearly wasn't thinking about optimizing networking at the outset. He was thinking about local operations and comparing trees. At least that's my impression from reading the early messages about git. I mean, didn't he describe it as a filesystem? That's certainly suggests a local access viewpoint. the first thing he tested was applying a mbox with 200 patches and recording each patch or something like that xorian, very much so, but he missed that whole point about how you usually have to pull changes over the network right before you apply them locally I should probably just unsubscribe from the git list, it's just making me pissed off 'doing stuff over the network' is not inherently part of a rcs though. neither is a lot of things. vesta and aegis seemed to be the most megalomaniac the patches might already be (relatively) local: mirrored on some worldwide collection of servers, aoften lready received by mail anyway Vesta is only megalomaniac in that it's trying to solve the problem of build reproducibility. To do that, you need a system that controls the filesystem and environment used during builds. That's all layered on top of the VCS portions of Vesta. xorian, sure, i'm not saying it's not a good thing; but enough people don't want it and you cannot (i presume) separate the pure revctrl part from the scm part The VCS portion of Vesta is fairly simple. If anything, it's probably *too* simple. just like git eh ;-) mlh: Sure you can. There's nothing that forces you to use the building/configuration part of Vesta. You could use it purely for versioning directories of files if that's what you wanted. mlh: And yes, it is similar to git in several ways, including its simplicity, as I said in my post to the git list. it seems that people have this false view that vesta forces you into a workflow or to use its build system rcohen: Yes, I've been trying to think of what to do about that. xorian, i think you need a quick start tute aimed at the very low end single user. Of course the build system is where the real power is, the high levergae part of Vesta. don't mention the file system at all xorian, ok, but unless you contain your enthusiasm for that, people (such as me) will think it's an integral part of it <mlh> just don't mention vesta at all shrugs mlh: rcohen has a point. Vesta really *is* a virtual filesystem, much more so than git. after attempting to decipher linus' contradictory claims, it seems that vesta may very well be what he wants and they could write their 3 way merge scripts over it instead or, at least, what he thinks he wants rcohen: Yes, I'm really wishing I had e-mailed him as soon as the BK story broke. I really didn't expect his desires to be so close to Vesta. doesn't matter what it is. what does it do it might not satisfy the 'written by linus' criterion though does vesta really need all that setup stuff? create users, setup repos? if so there is absolutely no way linus would touch it with a ten foot pole he hates heavyweight mlh: It does need a couple special users (to run the servers), but the .rpm/.deb install does all that for you. and yet he wants a non-history/syntax/semantics-aware merge which can move data between files which i suppose isn't heavyweight, it's just broken rcohen: Yeah, those posts make me think "I'll have what Linus is smoking" :) I could see history hiding being important for a UI perspective. Bram: And yes, I suspect you're right about the "written by linus" issue. I suspect he doesn't necessarily know what he wants. He knows what he doesn't want though umm, what? writing git is his way of finding out. setting the bar. the history-away merges use available information, they don't change the interface ... wasting a lot of time working on a version control system instead of the linux kernel whe's already using it apparently so not completely wasted rcohen, I think when I suggested that his other option was to accept that git doesn't do three-way merge, that I suggested that because I knew nothing about what git does, rather than that, uh, I was going based on the semantic distinction he'd just made that git does no such thing, and that the tools on top of it do? opportunity cost too: time taken to write git << time taken to evaluate cdv/mt/darcs/tla/baz/baz-ng rcohen: The text-move-between-files stuff he seems to think is easy, and which seems difficult and problematic. mlh, if he'd taken any time to do evaluation I'd buy that, but apparently all he really did was try monotone and bitch that it was too slow ... then jumped into writing his own, and didn't feel like wasting that work. xorian, url? "hey, this content hashing of files is easy!" mlh: I think I was thinking of: http://article.gmane.org/gmane.comp.version-control.git/1781 xorian, yeah found it. as i suspected it does NOT say he thinks it's easy. I read that as: person A changes function, person B moves function either within the file or to another file, a merge should apple person A's changes to the function wherever it was moved to. That sounds like a lot of magic to me. mlh: OK, you're right, he doesn't say that. I didn't have it in front of me, but re-reading it, the *tone* still sounds like he *thinks* a merge algorithm should be able to do that. xorian, the vital point in that message is para4. "In other words ...." fwiw i think he's wrong if not only for the fact that you can make your files smaller in order to help rcs's s/if not only/if only/ there are some big "if"s in linus' comments it's kind of misleading to call codeville's diff algorithm "LCS", since LCS has a technical meaning, that does not apply :-) It's a CS algorithm, that intentionally chooses not to use the LCS, but something that is hopefully more appropriate for VCS usage... njs: i read somewhere that monotone uses a diff algorithm by Wu, Manber and Myers (1989). Do you know if it's significantly better than the one used in GNU diff? beschmi: it doesn't, actually; it uses one that performs rather better than that (algorithmically speaking), by Aubrey Jaffer. beschmi, it's hard to say what the criteria for a good merge algorithm are, a reasonable case can be made that the best diff algorithm for version control to date is the one which will be in the upcoming release of codeville beschmi: Journal of Computational Biology (submitted) or something njs, it does feature LCS in there prominently, sort of njs: ah, the one in slib (saw a link on the cdv list) Bram: yeah, but it is just incorrect to say it is "an LCS algorithm". sorta a pedantic point, but, anyway... beschmi: yeah, that one. njs, once in a while I try to transcend my aspergers nature and say something which is not literally true but is less misleading than the thing which is :-) i wish #revctrl existed before i implemented the myers (1986) algorithm for darcs ;) Bram: I've just been calling it a CS algorithm, I guess that probably isn't much clearer :-) than i would have just started with that one, but the present diff seems to be good enough ATM beschmi, most of the time most merges give the exact same result er, most match algorithms I should say all LCS algorithms give the same result, by definition :-)