[00:02] mwhudson: Doesn't help for redirects. [00:03] Peng: but proxypassreverse does [00:05] Should it really take over 6 minutes to branch the Launchpad repository from one local disk to another? [00:05] 'maybe' [00:06] It's throwing a lot of CPU at it when I think it would be relatively quick to just... copy the folder. [00:06] Now, that's just lazy. But still. [00:07] branch validates data [00:07] we don't know if its e.g. removable or network or trusted or not [00:07] if you just want to copy the folder, I suggest you copy the folder. [00:07] It just seems a lot of CPU time for a repo of ~ 300MB [00:08] do you have the C extensions? [00:08] Should do, it's from the PPA [00:09] mwhudson: links from the landing page with the list of repos all have https, but links from within a served repo dont any more [00:09] thrope: links in directory listings are *really* relative [00:09] foo [00:09] ...But they still invoke HTTP redirects cuz they leave off the trailing/. :D [00:10] Peng: you can fix that if you like [00:11] Hmm. [00:13] Oh. It's totally trivial to fix. Doing so now. :D [00:17] thrope: try bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/relative-links [00:21] mwhudson: great - it works! thanks a lot! [00:21] thrope: awesome [00:21] thrope: you'll need to use proxypassrequest to handle the redirects [00:24] you mean proxypassreverse? or something else (dont know what proxypassrequest is) [00:25] Darn, it's a little bit trickier to add trailing slashes to breadcrumbs, cuz you have to avoid making the root link to //. [00:26] thrope: i mean that yes, sorry [00:26] * mwhudson needs lunch [00:26] there are a few problems poking around [00:26] ah ok [00:26] view branch changes goes to nn_review/changes/14start_revid=14 [00:27] * mwhudson can believe it [00:27] gives internal server error [00:27] but https stuff is ok [00:27] thrope: where is that? [00:27] and "view changes to this file" button leads to nn_review/changesfilter_file_id=nnreview.py-20091126142852-yobx026pq984w1a0-1 which gives not found [00:28] thrope: ah stupid mistake [00:28] sorry nn_review is my branch, from nn_review/files/13 i click the view branch changes button [00:28] it works with the ? in by hand [00:28] thrope: pull again? you want r397 [00:28] i forgot to put the ? in [00:31] ah breadcrumbs (I think thats what their) called at the top are still non https (root)/nn_review at top of changes page [00:32] funny thing mouse over is https but actual link is http [00:33] anyway thanks a lot - I have to head off now [00:33] happy thanksgiving to any us folks (normal day here!) [00:37] Peng: can you review/test https://code.edge.launchpad.net/~mwhudson/loggerhead/relative-links/+merge/15298 ? [00:37] * mwhudson lunches [00:42] mwhudson: I'll test it, at least. [00:42] mwhudson: I have been fortunate enough to avoid learning anything about URL handling. :) [01:41] lifeless: Check finished. 945 inconsistent parents, but nothing worse. [01:41] Only took 26.5 hours. Nice. [01:41] Peng: cool. check with vila - he has history there - but I suspect 'reconcile' is in order. [01:42] bzr's pretty impressive; *I* was never able to reconcile my parents' inconsistencies... [01:42] lifeless: How do you reconcile something on LP, though? [01:43] Peng: pull, reconcile, sftp/hitchiker and nuke the repo; push [01:44] Peng: this is for the candidate converted maria, right? [01:44] or 'spmdo reconcile url' [01:44] spm: ^ :) [01:44] Heh. [01:44] lifeless: Yeah, it's for Maria. [01:45] lifeless: How do you reconcile a stacked branch? [01:45] Peng: same same [01:45] It'll automatically reconcile the stacked-on repos just fine? [01:45] no [01:46] it reconciles the stacking branch and repo only [01:46] Oh. [01:46] Well, that's still OK. [01:46] I don't know which repo the inconsistent parents are in, though. :\ [01:47] you did 'bzr check' locally though,right ? [01:47] Yeah. [01:47] so they are local [01:47] :) [01:48] But I have copies of everything locally. [01:48] check checks only the local repo/branch [01:49] gotta eat [01:50] And, actually, I don't think I've added any revisions to my MySQL repo since I last checked it, and there weren't any inconsistent parents then... [01:52] lifeless: If it only checked the...1400 revisions in the stacked branch, why the heck did it take 26 hours? [01:57] I'm reconciling LP over ssh, just to see how awful it is. [02:05] Peng: not branch, repo [02:06] s/stacked branch/stacked branch's repo/, then. [02:06] ...One reconcile died with a KeyError. [02:07] Peng: check has issues ;P [02:10] When reconcile says it's repacking, does that mean it's done reconciling? [02:10] Or is that part of reconcilnig? [02:12] Now another reconcile has crashed with the same KeyError. [02:15] And there goes the last one. [02:15] Yeah, _that_ makes me confident about the integrity of my repo. :P [02:18] 'spmdo reconcile url' rofl [02:18] Oh hi. :D [02:20] hey Peng, so what's up - am trying to put 2+2 together from the backscroll? [02:21] spm: I'm just reconciling a branch or two (lp:~mnordhoff/maria/5.1-2a and lp:~mnordhoff/maria/5.2-2a), including the copies on LP. [02:23] But reconcile crashes now. :\ [02:24] Ah. It's bug #441125. [02:24] Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125 [02:24] ew [02:27] where does this "20 characters message" come from? [02:28] Maybe I'll stop using stacking, locally and maybe even on LP. [02:28] poolie: ? [02:28] lifeless: It's in one of the recent mailing list messages about emacs. [02:28] hrm. oki, digested that bug report. So I'm guessing this is going to need me to fiddle with backups or some such? [02:28] Peng: if you're pushing up a fresh mainline thats been converted, you won't want it stacked. [02:29] lifeless: I pushed up lp:~mnordhoff/mysql-server/mysql-5.1-2a non-stacked, and then have all of my other branches (including Maria) stacked on it. [02:30] spm: Well, originally the "spmdo" was just to run "reconcile" on the two branches on LP. Then it turns out reconciling them fails, so it's moot. [02:30] Peng: ahhh. bummer. ok. [02:31] I hate stacking. :( === arjenAU2 is now known as arjenAU [04:15] * igc lunch [04:56] spiv, around? [04:56] i have some python weirdness for you: [04:57] http://pastebin.ubuntu.com/329072/ [04:57] * spiv looks [04:57] i think in 2.5 and up 'exitfunc' is not a real method anymore, and [04:57] probably logging is causing the compatability method aluded to in http://bugs.python.org/issue2356 [04:57] to activate [04:58] and if i remove that, it breaks [04:59] poolie: hmm, the stdlib docs do say it might not be set [04:59] oh? [04:59] poolie: file:///usr/share/doc/python2.6/html/library/sys.html#sys.exitfunc [05:00] (And that it's been deprecated since 2.4, but we knew that already I think) [05:00] mm [05:00] ok, this is it [05:00] poolie: so I suppose the correct thing to do is actually "exitfunc = getattr(sys, 'exitfunc', None); if exitfunc is not None: exitfunc()" [05:00] or to run atexit._run_exitfuncs() [05:01] or we can just say that there is nothing like that [05:01] but the getattr is probably a safer change [05:02] Yeah, we're stuck with either a deprecated interface (sys.exitfunc), or an undocumented one (atexit._run_exitfuncs). [05:03] yay [05:03] when in doubt, prefer the smaller diff [05:03] the good thing about this is that this patch is avoiding loading at least one file (atexit) [05:03] Although the *implementation* of atexit is actually to install _run_exitfuncs as sys.exitfunc. [05:03] So in practice it's the same thing. [05:03] probably not enough to matter, buta small chance you'd have to wait until the disk head got to it [05:03] But getattr avoids an import ;) [05:03] exactly [05:05] thanks [05:17] poolie: didn't you put the explorer website into the list of automatically refreshed ones? [05:17] i thought i did [05:17] poolie: I pushed a change there an hour ago [05:17] and it's not appearing yet [05:17] * poolie checks [05:18] at the moment it only runs once per day [05:18] it can be more [05:18] but now that it does the sphinx generation it actually takes a fair amount of work to do all of them [05:19] so i turned it down [05:25] poolie: once a day ought to be fine for the core docs. Maybe bzr-migration-docs and bzr-explorer-website could be hourly. They ought to be far more lightweight [05:25] poolie: I maybe I just need a way to do it on demand [05:26] s/I/or [05:30] i'll just make it hourly for now [05:30] it'll kick off soon [05:31] we should probably move it all into a role account that you can get at but i don't really want to do that right now [05:38] can bazaar handle having a branch of one repository nested inside a branch of another repo [05:38] I'm thinking that I'd like my dependencies handled that way [05:39] i.e. one repo per solution. if the main project in solution A depends on the main project in solution B, I create a branch of solution B's repo inside a folder in the branche of solution A's repo [05:40] that way the version of B that A depends on can be updated whenever, and easily [05:41] Rotaerk_: I don't know precisely what you mean by "solution", and I suspect what you mean by "repository" isn't quite what bzr means, but I think the answer may still be yes. [05:43] Rotaerk_: if you have branch of one project at foo/, and a branch of another project at e.g. foo/libs/bar, then that's fine by bzr. [05:43] hmm okay sounds good, thanks [05:43] "solution" and "project" are part of the visual studio code organization model [05:43] Rotaerk_: bzr won't keep track of which version of libs/bar you happen to have in foo/, but it won't get confused or anything like that. [05:44] hmm [05:44] Rotaerk_: so you can do "bzr pull" or "bzr commit" etc inside foo/libs/bar, and the fact that it's inside foo/ will be irrelevant [05:45] And similarly you can pull, commit etc in foo/ without disturbing the branch in libs/bar [05:46] okay time to try it [05:46] Yeah, that's the best way to figure this out I think :) [05:46] just didn't want to screw up my current repo if bazaar would be confused by it [05:48] igc: how now? [05:48] poolie: excellent. thanks! [05:48] poolie: http://doc.bazaar-vcs.org/explorer/en/tutorials/open-source-dev-gnome.html [05:54] very nice! [05:55] igc, i wonder if not specifically mentioning emacs would be sound better? [05:55] after all we'd be willing to provide site policy for any hosting site [05:55] it would make it look more like you're using emacs & savannah just as an example [05:56] poolie: I'm not sure I understand what you're saying [05:56] if i created a branch and want to get rid of it, can I just delete the folder it's in, or is there a command I need to use [05:57] the doc is explicitly aimed at the Emacs developers [05:57] but generalised to be useful to others [05:57] i'm saying the document seems to have some tension about whether it's specifically for emacs, or just using emacs as an example [05:58] hmm nm, I guess I can just delete it... since bzr has to scan to find branches, it must not actually track them [05:58] it's just an observation, not a big problem [06:00] poolie: it's meant to be general with Emacs as an example ... [06:00] but good enough to show Emacs developers the "right" way to get started [06:01] poolie: should I take out the note re savannah push policy perhaps? [06:01] given what you just said i'd probably write it as something like this [06:02] "explorer knows about the right way to publish to different hosting sites, but at the moment not how to publish to Savannah where emacs branches are hosted. (Patches or information on how it should work gratefully accepted.) Therefore we have to manually tell it where to push this branch...." [06:04] poolie: ok [06:04] hmm darn [06:06] given branch of repo A at aaa, and branch of repo B at bbb, if I create a branch of bbb at aaa/bbb, I can't do "bzr add bbb" from aaa === timchen1` is now known as nasloc__ [06:07] it remains unknown [06:08] was hoping that revisions of A could contain snapshots of branches of B [06:18] Rotaerk_: no, unfortunately. We'd like to support something like that, but it hasn't gotten past the experimental stage yet. [06:19] hmm I wonder if git or mercurial can do that [06:19] Rotaerk_: that's what I was trying to say when I said "bzr won't keep track of which version of libs/bar you happen to have in foo/" [06:19] ah I see [06:19] is there any other way to go about what I'm wanting to do? [06:20] i.e. have particular revisions of A dependent on particular revisions of B [06:21] i think SVN can handle this using "externals" [06:21] though I've only heard about it [06:22] Rotaerk_: there are some plugins and add ons that might help [06:22] ah this is actually listed as a limitation on the bazaar site [06:22] Rotaerk_: http://bazaar-vcs.org/ScmProj is one, there was also a mailing list thread touching on this recently [06:23] Rotaerk_: it starts at https://lists.ubuntu.com/archives/bazaar/2009q4/064637.html [06:25] hmm thanks [06:35] poolie: how does one get permission to upload to our +downloads page. Is it joining ~bzr? [06:36] i think so [06:37] showing the current transfer rate is geeky provicialism (according to sjt)? [06:37] poolie: can we add the guys making mac packages into there then? [06:37] of course [06:38] um [06:38] if you just add them to that team they'll get a lot of mail [06:38] it may be better to work out what lp role controls access, and then make that a different group [06:38] it may not be possibly [06:38] possible* [06:38] it's probably better also to add them to bzr-core === Rotaerk_ is now known as Rotaerk [06:40] poolie: the PPA packaging guys are in bzr, not bzr-core. hmm [06:41] downloads sounds similar to PPAs conceptually wrt permissions? [06:45] so [06:45] the ppa is an example of one thing that sends a fair amount of mail to its owners [06:45] i trust the guys doing packaging of course [06:46] i don't mind adding them to any group [06:46] perhaps the easiest thing is to just add them to ~bzr and then if that's not working, try something else [06:57] meh, I only wanted to nest revisions of B within a revision of A so that I could setup a reference from project A to project B, but instead I'll just build B and copy B.dll into A [07:38] hi all [07:39] Hi. :) [07:42] hey vila! [08:16] ‘bzr branch lp:foo’ is agonizingly slow. what protocol is being used when I specify the scheme ‘lp:’? [08:16] bignose: If you've run "bzr launchpad-login", bzr+ssh. Otherwise, http. [08:17] I don't have a Launchpad account. can I easily make ‘lp:foo’ use ‘bzr+http’? [08:17] LP doesn't support bzr+http. [08:17] argl [08:18] why on earth not? [08:18] Probably cuz all of the LP developers use bzr+ssh, so it's not important to them. :P [08:18] bignose: time [08:18] Peng: no [08:19] Peng: we want to. Needs TUITS [08:19] it's not simply a matter of upgrading the Bazaar instance on Launchpad? [08:19] lifeless: TUITS? [08:19] bignose: It's a matter of...setting it up. [08:19] Peng: specifically, round tuits. [08:19] http://www.myrtlewoodgallery.com/get_a_round_tuit.htm [08:19] Peng: ^ [08:20] as in, “We haven't got a round tuit”. [08:20] bignose: its a deployment/testing issue [08:20] Ohhhhhhh. [08:21] hmm, perhaps there is something in Stephen J Turnbull's somplaints about the degree of difficulty in setting up a Bazaar server. [08:21] Peng: a better one - http://www.stosyth.gov.uk/default.asp?calltype=sep03roundtuti [08:22] bignose: its about 5 lines of apache config [08:22] bignose: but we have loggerhead, which is fragile at scale, and we really don't want to destabilise that [08:22] and they have to coexist on the same space. [08:23] okay. well, I can only agree with Stephen that it's a black eye for Bazaar when one's first likely interaction — branching an existing project— is dreadfully slow by default. [08:24] * igc dinner [08:24] bignose: setting up is in fact documented - 'running an http smart server' [08:25] I can't agree. Setting up a bzr:// server was easy.s [08:26] right, but that doesn't affect that Launchpad doesn't have it enabled, which immediately raises the question of why it's difficult for the experts to do. (and most people asking that question are likely to come to the “because it's too difficult” conclusion) [08:26] bzr+http is a little more fiddly, but not much. [08:26] um. what protocol does ‘bzr://’ run over? is it different from ‘bzr+http://’, ‘bzr+ssh://’? [08:27] it seems to me the read-only one is the important one for PR. [08:27] bignose: it runs over the bzr protocol [08:27] omg the doc search is slow [08:28] bignose: bzr:// servers listen directly on TCP port 4155; they aren't tunnelled over SSH or HTTP or anything. [08:28] oh okay. well, that raises the question: if *that*'s the easy one to set up, why doesn't read-only ‘lp:foo’ use that protocol by default instead of slow ‘http://’? [08:28] bignose: because lp isn't a typical deployment. [08:29] theres a db with virtual filesystem and 'stuff' [08:29] as well as private branches to consider [08:29] lifeless: (which is a shame, because otherwise it would promote bzr:// quite well) [08:29] but it's the most public one. “let's see how Bazaar performs over the network” is highly likely to lead to branching a project from Launchpad without an account there. [08:29] http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/http_smart_server.html documents how to run a bzr+http setup [08:30] running bzr:// from inetd is ridiculously simple for straight forward environments (and savannah is AFAIK - its no where near as complicated a setup as LP's production environment) [08:30] and hence branching from ‘lp:foo’, which leads to HTTP without specifically asking for it, which leads one to think that Launchpad and/or Bazaar are very slow over the network. [08:31] * fullermd still vaguely wishes he could setup bzr+http on a non-trivial setup... [08:32] bignose: as I said, we want to do it. the team that is responsible also has a bunch of other things to do. [08:32] so I think this ties directly into Stephen's observations about PR and what Bazaar (and Launchpad, and Canonical, etc.) can do to improve image: get the most obvious Bazaar site working very fast by default. [08:32] is it hard? not any harder than the other bugs they are working on. But they haven't gotten to it. [08:34] naturally. so perhaps, since Ian has published a guide, in response to Emacs developers needing to learn more about Bazaar, and specifically using Launchpad as a demonstration ... now is a good time to raise the priority of setting up a fast protocol by default for ‘lp:foo’ branch URLs. [08:34] to forestall a whole lot of Emacs developers, who might have otherwise been on the fence, having an abysmal first experience with Launchpad. [08:35] I think that you should make this observation on the list. [08:35] okay, shall do. [08:35] THe folk that need to see it are out drinking beer at the moment. ;) === jamesh_ is now known as jamesh === weigon_ is now known as weigon [08:53] lifeless: done, thanks. [09:01] hello [09:02] * fullermd waves at bialix. [09:02] * bialix waves back [09:02] hi fullermd :-) [09:10] hello [09:10] Hi. [09:17] hi, not a bzr question, but i guessed i'll drop it anyway... Anyone using Krusader for filetransfers? [09:20] i have a question: it is possible to include the current Rev.number into my source files? [09:21] i.e. in sourcefile "###bzr-rev###" and bzr replace this with the current Rev. number? [09:21] i know in CVS/SVN it its possible [09:22] i think this replacement should be done by commit command [09:23] because only the currently commited files should be became the new rev.number [09:23] any idea? [09:24] Torty: Generally you make your build system do "bzr revision-info >version.txt" or somesuch. [09:24] Torty: But there is the bzr-keyword plugin if you want it. [09:24] Or is it "bzr-keywords"? I don't remember. [09:28] i think i dont know what you mean (advice: write simple english *g*) [09:28] Torty: The usual practice is to make your build system do it, using a command such as "bzr revision-info". [09:29] Torty: But there is a plugin that does what you want. See http://bazaar-vcs.org/KeywordExpansion [09:29] ok i read [09:30] ok it seems to be what i searching :-D thx [09:30] Torty: That page looks a little out-of-date. It might be better to start at https://launchpad.net/bzr-keywords [09:30] k [09:36] The plugin functions more like PoC than usable code, for various reasons. Some of the changes needed to really use it are only in 2.1, and I'm pretty sure some aren't anywhere yet. [09:41] Ah. [09:42] * vila cries, testtools doesn't support python2.4 (it requires functools) :-( <- lifeless [09:43] vila: https://code.edge.launchpad.net/~lifeless/testtools/2.4 [09:43] has bzr's auto-resolve behaviour changed recently? [09:43] jml: I don't think so [09:43] vila, lifeless: actually: lp:testtools [09:43] vila: but you probably want that branch + my 0.9.1 branch. [09:44] ungh [09:44] Using '=' to underline things confuses the auto-resolver. [09:45] jml: oh yeah, sorry. [09:45] use ---- perhaos [09:45] problem for another day, I think. [09:45] or ++++ actually, that shouldn't be used there and should be unique [09:45] * vila sends love to lifeless, jml and checks [09:48] vila: By the by, 8.0 final release was finally cut. [09:48] fullermd: Great, thanks for telling me, I'll upgrade asap [09:50] jml, lifeless: lp:testtools still has the problem, trying 2.4 + 0.9.1 branches now [09:51] vila, oops. pushed to wrong location [09:51] * vila jumps on the brake pedal [09:52] vila, lp:testtools should have 2.4 now [09:52] * vila laughs at the commit message and wishes all commit messages were like that :) [09:53] * vila confirms --parallel=fork works again with 2.4 \o/ [09:54] 11 mins between tears and joy, who said bzr was slow ? [09:55] yes, I know, that's a totally unfair reasoning :-D [09:55] Man, that's pathetic. CVS can go from joy to tears in SECONDS. [09:57] jml: push 0.9. to trunk ? :) [09:57] no, not now [09:57] no? [09:58] lifeless, I was writing the release announcement and uploading the tarball. Now I can do the branch bit :) [09:59] jml: I would just push 0.9 to trunk again, is aall I meant [09:59] lifeless, rather than merge? [10:01] yes [10:01] we haven't landed anything on trunk that we haven't also landed in 0.9 [10:02] if we had it would be different. Just a thought. [10:02] I don't intrinsically care. [10:04] done. [10:04] that's a release, I think. [10:05] crap. PyPI [10:06] :) [10:06] and setup.py [10:06] dammit, I can't believe I need a release checklist for such a small project. [10:07] you always need a checklist. [10:07] write a tool. [10:08] Sometimes I hate the day I internalized 'write a tool'... [10:08] -> fud [10:10] vila? [10:10] lifeless: what;s tool? [10:10] bialix: ? [10:11] vila: hello [10:11] what I should write in authentication.conf if I want to specify details for bzr+ssh [10:11] bialix: hello :) [10:11] scheme = bzr+shh [10:11] ? [10:11] or just ssh? [10:11] no, scheme = ssh, that's valid for both bzr+ssh and sftp since that's really the same scheme [10:12] oops [10:12] nice [10:12] vila: thanks very much [10:12] * vila thinks the problem has been raised already and a warning is emitted ? [10:12] Peng: i've installed new bzr and the plugin but i have problems to understand what i have now to do [10:12] Or am I just dreaming that I wrote the fix ? [10:12] i mean the keywords-plugin [10:13] on Launchpad the documentation is missing [10:13] vila: works perfectly! [10:14] cool [10:14] Torty: Did you see above what fullermd said about the bzr-keywords plugin? [10:14] on launchpad? [10:14] lifeless, I'll write a tool after I have a checklist, probably. [10:15] lifeless, anyway, release done. [10:16] ah - fullermd here on irc - no - i have to reboot my system [10:16] no chat-log active [10:16] can you paste me what he said [10:16] Torty: 09:36:46 < fullermd> The plugin functions more like PoC than usable code, for various reasons. Some of the changes needed to really use it are only in 2.1, and I'm pretty sure some aren't anywhere yet. [10:17] thx - mom i try to translate ... [10:18] Torty: Short version: it's still experimental and doesn't work completely. [10:18] this means the plugin ist useable up from 2.1 version of bzr? [10:19] aha - but in future this replace-feature (bzr-keywords) will be working [10:19] With versions before pretty recent dev head, the keywords won't update all the time when you perform bzr operations. [10:19] aha [10:19] And with any version I know of actually existing, filtering in general can only be configured globally, so you can't turn them on in a single branch. [10:19] but the feature will be finialize in newer versions [10:19] good to know [10:21] what means also: if i want rev.# in my sources i have to do it by hand [10:21] or (bedder) dont include it in source files [10:22] ok thx - i wish you a nice weekend [10:22] bb [10:56] fullermd: And people still don't believe that computers have feelings.... The freeBSD8 VM just crashed...And it runs from a different host than the one I use to do IRC.... [11:07] vila: 's what you get for running emacs on it :p [11:12] fullermd: pfff, not even, it was running unattended :) [11:14] fullermd: more seriously, since it crashed, I may as well upgrade now, http://wiki.freebsd.org/8.0TODO is out of date ? [11:15] Dunno. The last edit date is, what, a week and a half back, or something? [11:15] Not sure how actively it was maintained during the RC cycle. [11:16] fullermd: it's ok, just found http://www.freebsd.org/releases/8.0R/announce.html [11:16] * fullermd glances at how recently the version control page was updated as long as he's bouncing around the wiki... [11:16] hey ! vbox guest support ! [11:17] of course, just when I wanted to start migrating to kvm... [11:17] * fullermd . o O ( Last real update: 2008-01-19 ) [11:17] Well. That's almost certainly not much changed since the last few RC's :p [11:18] .. may be, but it may also mean I need some tweaks I'm not aware of... [11:19] I guess the topic fizzled out of major notice after src moved CVS -> SVN. Owell. [11:40] Hello! Anyone an idea how stacked branches differ from others (regular ones)? [11:43] drmabuse_: Stacked branches don't store all of the revisions locally. [11:43] drmabuse_: They should function exactly the same as a normal branch, more or less. [11:43] drmabuse_: A stacked branch does not have all the revsions in it's repository. It has a url to the branch that it is stacked on, and if bzr needs any revisions that are not in it's repository, it gets them from the stacked on branch. [11:44] GaryvdM++ [11:44] You put it very well. :) [11:44] Ah, thank you! [11:44] Peng: thanks [11:44] Great! [11:44] * fullermd blinks. [11:45] The heck... how did I get a modified file in my bzr.dev tree... [11:47] OK, what the hell? log $FILE is showing 1 rev touching the file, log -n0 $FILE is showing 2, and there's no overlap between them. [11:48] And none are actually direct edits, they're all merges. [11:49] ... OK, that's even weirder. I revert it, and it STILL shows modified. [11:50] Kill dirstate? [11:50] (well, mv) [11:50] what file is that ? [11:50] Oh, I found it. [11:50] Just snows to go you the sad state of content filtering. [11:50]