[00:04] morning all [00:04] hi jelmer [00:09] am I right in thinking that bzr selftest -E foo is supposed to put 'foo' in bzrlib.debug.debug_flags ? === cprov is now known as cprov-afk [00:24] lifeless: i see we have an Inventory and an InventoryCommon class [00:24] which i think is the antipattern we were talking about a while ago wrt RepositoryBase [00:24] no quite [00:25] InventoryCommon is the base; Inventory is really MutableInventory, or InMemoryInventory [00:25] but there were enough uses of it that renaming would have been traumatic [00:25] why is that different? [00:25] we've moved a lot of stuff to Common [00:25] CHKInventory is immutable [00:25] i could equally say that Repository is really VFSBasedRepository [00:26] hooray for immutability [00:26] poolie: do you have some other kind? [00:26] poolie: Repository long ago lost concrete code [00:26] RemoteRepository [00:26] its not a leaf [00:26] RemoteRepository is a leaf, as is Inventory, and CHKInventory [00:26] argh [00:27] poolie: I could be wrong; but thats why I think the cases are different [00:27] * SamB wishes for a black board [00:27] i should be more precise [00:27] the issue is: things that sound like they should be base classes, actually are not [00:28] poolie: oh right. Inventory is a really misleading name [00:28] I would love to renamed it to (say) InMemoryInventory [00:28] s/renamed/rename/ [00:28] how about rename but leave an alias behind? [00:28] we could get there from here by either - inserting a new class called *Base or *Common [00:28] with a comment that it's there to avoid pain [00:28] or, changing the existing one [00:28] SamB: it's too hard wrt our api compatibility [00:29] i'm hoping that introducing different api break windows may make it easier [00:29] SamB: do, or do not :). [00:29] it may still be traumatic even just within bzrlib though [00:29] well, at least that way people would see the right name if they repr'd it [00:30] btw re https://code.launchpad.net/~mbp/bzr/403523-status-crash/+merge/9739 [00:30] do you object to me putting has_filename in the base class? [00:30] so, to rename it, we could do it, use a factory as Inventory, which can issue deprecationwarning [00:31] anyhow, concretely [00:31] the thing to do is change RemoteRepository to inherit from Repository and see if anything breaks [00:31] or if anything should go into a LocalRepository [00:31] or some better name [00:31] yes [00:31] I'd just change RR to inherit from R and see what the fallout is [00:32] +1 on that change [00:32] has_filename is a little ugly though [00:39] lifeless: that usertest run on OOo with your pending patches got done last night ... [00:39] lifeless: 73.9 -> 1.8 seconds for selective commit [00:39] ! :) [00:39] well, thats better than it was [00:39] hows full commit? [00:39] lifeless: and also interesting is ... [00:40] [drum roll please] [00:40] send -o dropping from 332 seconds to 69.6 seconds [00:40] in my branch? [00:40] lifeless: where 70 seconds still sucks, fwiw [00:41] that would be the path2id improvement showing up [00:41] igc: whats full tree commit in OOo? [00:41] 1.8 seconds [00:42] ok, so we're still dominated by something not addressed [00:42] I'd love an lsprof of both incremental and full commits of a single file [00:42] I suspect dirstate load/save [00:42] shall do [00:43] lifeless: if it is, I have a patch for that - still in review maybe [00:43] igc, i assume that send thing is with jam's ptach? [00:43] poolie: I improved a code path send uses as well [00:45] poolie: the 332 seconds is with bzr.dev rev 4593 - pretty recent [00:45] poolie: but looking deeper, I'm not sure whether my 'pending' branch with robert's patches has it or not [00:48] spiv, does my last comment on bug 405251 make any sense to you? :) [00:48] Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251 [00:54] does anyone use bzr with windows and launchpad here? [00:54] https://answers.edge.launchpad.net/launchpad/+question/79261 [00:54] the question here is trying to work out why it isn't working [00:54] thumper: occasionally [00:54] AFAICT it should work [00:55] so I'm guessing it has to do with getting bzr on windows to use his putty key [00:55] and I have no idea how to check that [00:55] poolie: "I wonder if this is related to binary modules not being built?" ? [00:56] Oh, there's a newer one now. [00:56] mm, maybe, or actually to something being stuck or inefficient in hpss protocols [00:56] It wasn't there when I first loaded the page. email lag I suppose. [00:56] bit of a wild-ass-guess [00:57] thumper: the steps he outlined seem correct generally. unless he messed up on step 5. [00:57] sidnei: is there any way for him to check? [00:57] step 5 from the launchpad wiki, that is, the one that has a explicit warning about where it can get messed up [00:57] igc: there are a few commits from trunk missing [00:59] thumper: when you upload the ssh key to launchpad does it get used right away, or there's a time needed for it to sync somewhere? [01:00] igc: its missing 4588 [01:00] which changes bundles as well [01:00] igc: I'll merge trunk now [01:01] lifeless: thanks. My 'pending' trunk is usually trunk + merges of stuff I want to benchmark but ... [01:01] lifeless: I'd prefer to just benchmark you branch if it's up to date with trunk [01:01] s/you/your/ [01:01] sidnei: I don't know [01:03] sidnei: its usable immediately, modulo db lag [01:03] thumper: that's the only thing that comes to mind: he uploaded the key and expected it to work right away, but the key isn't immediately put in place on the server side. but i don't know if that is the case or not. [01:03] hmm.. [01:03] sidnei: the ssh daemon isn't openssh, so it just asks the db for the key, rather than waiting for it to be put on disk [01:03] igc: pushed [01:12] lifeless: is iter-changes-partial-parents enough yet? Or do I still need to follow that up with a merge from selective-file-commit? [01:13] you need both [01:24] igc, any comments on kiko's vm mail? [01:32] poolie: if we want continuous testing following a commit, we need it up most of the time I suspect [01:32] yeah [01:33] poolie: perhaps a time out of a few hours would work though and ... [01:33] that's about $100/month, it shouldn't break the bank [01:33] might result in it being down over weekend periods in particular [01:34] poolie: if we go the mega-vs-simple installer route, ... [01:34] poolie: then the testing only needs the standard simple installer or easy-install [01:34] poolie: building the mega-installer will happen rarely [01:42] hey igc, poolie [01:42] not sure if vila let you guys know, but we have builds being run by kerguelen now [01:43] excellent [01:43] sidnei: have you seen hudson? [01:43] matter of fact, i did [01:43] ... [01:43] :P [01:43] mwhudson: change your highlight rules ;) [01:44] lifeless: this one is in my brain, sadly [01:44] mwhudson: I hear electroshock is much more refined these days [01:44] heh heh [01:45] poolie, igc: I'm outta that circuit now -- I have done what I can :-) [01:45] poolie, igc: again, for me bzr2 is the priority -- this is just something nice to have happen [01:57] kiko, thanks for connecting the circuit [01:57] a good 2.0 is the priority but getting good windows builds for it will help make it a good release [02:08] Hmm, test_pack_repository really ought to be renamed to per_pack_repository or per_repository_pack I think. [02:12] poolie: actually, that's something you might want to look at while looking at running tests with 2a as the default, test_pack_repository doesn't include 2a in its scenario list! [02:13] (also, the way the scenario definition duplicates a bunch of format strings etc rather than just grabbing them off the format objects is weird, I think.) [02:15] :/ [02:15] could you file a bug assigned to me? [02:16] Sure. [02:24] jelmer: is there some guide on using dpush? [02:30] poolie: review sent [02:31] bah [02:31] spiv: review sent [02:32] for the delta branch? [02:32] yes [02:32] about 6 hours of reading and thinking [02:36] Anyone know how I can get `bzr log` to output time and date? [02:36] it does by default? [02:37] It outputs date, but no timestamp [02:37] timestamp: Fri 2009-08-07 01:03:20 +0100 [02:37] is what I see [02:37] what are you seeing? [02:37] Wait, nevermind [02:37] I am using `bzr log --short` [02:37] Hmm, I want the short but with the timestamp [02:38] I suppose I can parse [02:42] lifeless: thanks! [02:42] I know this isn't SQL [02:42] Anyone know a good way to swap 2 primary keys? [02:43] lunch [02:43] if you need me, ring me, I'll be offline [02:44] cheers lifeless === lamont` is now known as lamont [03:59] * igc lunch [04:14] igc, noooo. no lunch! [04:14] :) === abentley1 is now known as abentley [06:36] Oof, reviews replied to. [06:38] lifeless: are you back? [06:40] epic review there [06:40] Yes, "epic" was exactly the word I was just thinking of :) [06:41] More epic than expected, really. [06:41] There are a few points still not 100% resolved, but I think it's probably good enough to land, and the last few nits can happen in a followup landing, I think. [06:42] * spiv makes a coffee [06:53] Yeah, with the aid of this coffee, I'm pretty comfy with the state of this branch, so I'll pqm-submit it now and send the last few fixes later. [07:25] hi all [07:27] poolie: I'd like to answer that mail about the win32 build machines but I miss the meaning of some TLAs: AWS, AMI ? [07:29] amazon webservices, amazon machine something (disk image)? [07:30] ha right [07:47] hello vila [07:49] poolie: hey ! [07:49] hi [07:49] shall we talk about that? [07:50] i was just going to send mail [07:50] or maybe i should send mail and then we should talk [07:50] poolie: same here, mail nearly godd to be sent from here [07:57] vila what do you mean by "as long as we can be freed from the nightly ones" [07:58] grr, freed "from the risk of regressions" [07:59] wow, this sentence makes no sense at all, sorry :-/ [07:59] I meant to say: If the nightly builds gave us the benefit of catching the regressions sooner, the release builds should be hassle free and as such can be done by humans [08:00] ok, right [08:00] at least kicked off by a human [08:03] poolie: 'kicked off' as in 'in a freshly started VM' ? Yes [08:03] or any other valid host [08:05] Heh, "make check" fails on my branch due to "make docs" not liking the markup for the -DIDS:always debug flag. [08:06] spiv maybe eventually debug_flags should be a dict [08:07] i'd kind of agree for now it should be IDS_always but whatever [08:12] spiv: 'IDS:' made it kind of obvious that the flags were exclusive... too bad :) [08:14] vila: bob2: amazon web services, amazon machine image [08:16] I could take lifeless' suggestion and just not document them... [08:17] spiv: >-/ [08:20] no, they're fine [08:52] lifeless: in the context of https://code.edge.launchpad.net/~mbp/bzr/403523-status-crash/+merge/9739 [08:53] what's the difference between test_inv and per_inventory? [08:53] it looks like they want to be the same thing? [08:53] I think they do [08:53] except [08:53] perhaps [08:53] per_inventory wants to be per_mutable_inventory [08:54] and the tests at the top of test_inv - the parameterised ones, a small part of the file [08:54] want to be per_immutable_inventory [08:54] or something along those lines of separation [08:56] ok [08:56] then i might: [08:56] file a bug for this [08:56] rearrangement; [08:56] stick a test for has_filename into test_inv [08:56] and merge my change [08:56] yup [08:57] per_inventory only tests Inventory today [09:46] * igc dinner [10:14] lifeless: btw, if I just delete that if block from the per_interrepo fetch test the tests still pass. [10:14] lifeless: so whatever bug I had that prompted me to add it in is gone. [10:15] \o/ [10:15] Another problem solved by deleting some code! [10:27] huzzah [10:27] spiv: uhm [10:27] spiv: you should delete the if statement and undent the block, I think. [10:27] lifeless: right, that's what I meant. [10:28] phew [10:28] run the assertions unconditionally. [10:28] I thought that on first read [10:28] Sorry about the false alarm(s) :) [10:28] then I read what you wrote. [10:28] Yeah, my bad. [10:28] :) [12:04] Hey, do symlinks work in bzr? [12:07] In what sense? bzr sill store and version symlinks, sure. [12:33] sidnei: ping === cprov-afk is now known as cprov [13:15] jfroy: not really, it's basically just like push [14:10] igc: hi [14:32] hi jelmer [14:38] igc: I've proposed a merge for some foreign branch tests, I was wondering if you could comment on the general approach I've taken, so I know if I'm on the right track before doing a lot more of these tests. [14:39] igc: (the merge proposal is at https://code.edge.launchpad.net/~jelmer/bzr/foreign-tests/+merge/9642) [14:40] jelmer: I won't have time in coming days sorry, Maybe vila or jam could offer an opinion? If not, I'll take a look mid-to-late next week [14:40] jelmer: sorry about that but I just have too much other stuff on my plate currently :-( [14:41] igc: No worries [14:43] night all [14:43] g'night igc [14:57] hey people!, with bzrlib, is it better to use bzrlib.commit or bzrlib.builtins.cmd_commit() for a working tree? [15:00] anybody? [15:03] dgoulet: cmd_commit is very close to the command line but may be harder to use than the command line itself [15:04] bzrlib.commit may be harder to understand if you're not familiar with the bzr internals [15:04] dgoulet: any reason for not using WorkingTree.commit()? That invokes bzrlib.commit [15:04] moin vila [15:04] jelmer: hi [15:05] no not at all, actually i'm getting deeper into bzrlib day after day and I'm wondering the best way to commit a working tree [15:05] i'm using cmd_commit right now but i was thinking that there might be a better way [15:07] dgoulet: you should have a look at the commit tests and decide from there what suit your needs [15:08] dgoulet: try 'bzr selftest commit --list' to get a taste [15:08] but presumably jelemer is right, you awnt to use wt.commit() [15:09] hmm ok I look into that, very nice [15:11] another question while i'm here [15:11] i have a branch with NO tree (only .bzr) [15:12] what's the best way of getting that into a working tree to work on whitout a cmd_branch() ? [15:15] dgoulet: BzrDir.open(path).create_workingtree() [15:15] After upgrading bzr to 1.17, my integration with Redmine suddenly stopped working. Did a little diving into Redmine to see what command is causing the issue, and bzr is indeed crashing on the command which redmine uses: http://pastebin.com/d58052ae2 [15:16] any fixes or workarounds available? [15:18] meuserj: please file a bug report, this looks like a regression in bzr [15:28] jelmer: a little more experimentation shows that it is the revno:-1 option which is causing the crash === BasicPRO is now known as BasicOSX [15:35] ah, and it only happens when I use bzr://.. other remote protocols, including bzr+ssh seem to work. [15:57] meuserj: ah, odd [15:57] meuserj: definitely seems like a bug then [15:57] meuserj: the fact that it only occurs with bzr:// probably explains why nobody has noticed it before [15:59] jelmer: yeah I assumed that bzr:// isn't used often.. the only reason I use it is that the machine hosting Redmine is different than the machine hosting the central repository, and it's easier to use the bzr server than try to set up ssh keys for the web server user. [16:06] from a working tree, if I want to revert a specific file to a lower revision, how can I make that happen because i'm having no result from wt.revert()... ? [16:13] jelmer: wow.. yet another variable.. it only happens with repositories served via bzr-server, not individual branches [16:21] hi everyone, brand new user here... silly question: if i do bzr ignore dirname, is everything under that directory ignored recursively? [16:21] dgoulet: I'm using RevisionTree.revert() [16:21] manuee: yes [16:21] ow awesome [16:21] i was wondering because olive lists the files under those dirs as unknown instead of ignored [16:21] so i was geting confused [16:22] ah :) [16:22] thanks vxnick =) [16:22] yess that's what I though but when I try to get the RevisionTree from my WorkingTree, it always tell me that NoSuchRevision... [16:22] i'm doing something bad but I can,t figure it out [16:22] im planing on geting my drupal development under bazaar (soloing) [16:22] wait, my bad [16:22] from a RevisionSpec, how can I get the revision id ? [16:23] dgoulet: the as_revision_id() method IIRC [16:23] I'm getting the rev from the revision tree, then using WorkingTree.revert() with that rev [16:23] :| how? [16:23] one sec, let me pastebin some code [16:23] ive got my repository setup here onmy local development machine, the next step would be to set it up on the production server,... any guides/howtos/tips on how to go about it so ican push changes to my server from my local machine? [16:24] i know its a broad question... perhaps i should study the manual a bit more [16:24] :X [16:24] manuee: depends if you wanna use commit/update or push/pull [16:24] I think the manual has a few examples which you might find helpful [16:25] yeh i should probably re-read that see if i figure things out [16:25] ow [16:25] server doesnt have bzr installed :X [16:25] if you want to use push/pull you don't need bzr installed on the server [16:26] ooow nice [16:26] you can do bzr push sftp://you@server.com/path/to/repo [16:26] push only uploads stuf ? [16:26] Tak: thanks! [16:26] i rtfm vxnick [16:26] http://paste2.org/p/366912 [16:26] heheh bbiab [16:26] that's what I'm doing, which may not be The Right Way [16:27] err, remove that [0] from the first line [16:27] i figure ;) i'm trying it real quick [16:27] reading http://bazaar-vcs.org/BazaarForWebDevs atm--- it mentions to use the bzr-push-and-update plugin [16:27] manuee: only if you have a remote working tree, which you prob don't need [16:28] ah right [16:28] ye only my local box will be having vc [16:28] thanks vxnick [16:28] no probs [16:29] im tryin to just have a simple setup, im very new to vcs :X [16:29] =) [16:29] back to reading (getin excited) [16:30] manuee: have you made the repo on your local machine already? [16:30] humm yes [16:30] i ran bzr innit [16:30] ignored everything but the custom code i want on vc [16:30] and added what i wanted [16:30] committed? [16:30] i committed the first yes [16:30] i havent created a branch though [16:30] not sure how that goes :X [16:30] do this: [16:31] check the manual for bzr push - this will upload your repo to your server. If you want to get a copy of it on other machines, you use bzr branch on the URL [16:32] bzr info returns Standalone tree (format: pack-0.92) [16:32] so when you make changes in future, commit then push again (you don't need to specify the server details each time), then others can use bzr pull to grab your changes [16:32] ok bzr help push --- reading... [16:34] Tak: it's working very well! [16:34] thanks a lot! I appreciate it!! [16:35] np [16:35] ow ok, bzr remove actualy deletes the files [16:35] lol good go know [16:36] you can use --keep to keep them [16:36] ah awesome [16:36] im thinkin im only going to vc the theme for now === abentley1 is now known as abentley [16:36] you may as well do the whole thing, makes life easier :) [16:37] and bzr revert should bring back those deleted files, if you want them [16:38] ah heheh [16:40] very handy [16:46] ok moment of truth [16:47] im using bzr push --creat-prefix sftp:/blabla --use-existing-dir [16:47] i hope it puts things into its place :X [16:48] --use-existing-dir seems redundant as --create-prefix implies that you're pushing to a path that might not already exist [16:48] but don't worry about it [16:49] i didnt use it the first time and it got me an error saying it doesnt have a valid .bzr directory [16:50] ah, ok [16:51] "Created new branch." [16:51] looks like it worked no? [16:51] you can test by branching it to another directory and making sure it pulls all the files [16:52] humm k i dont understand the whole branching deal it looks like [16:53] branching means to copy the repository to another location === deryck is now known as deryck[lunch] [17:09] getting a wierd problem. I can use putty to connect to my host but when I do bzr+ssh, I get bzr: ERROR: socket.error: Socket is closed [17:09] the host that I am trying to bzr+ssh to is a mac [17:09] hmmm k it isnt working [17:10] i made a small change to a file to test, commited the change, ran bzr push, which looked ok, but the file didnt get updated on the server [17:10] hmm, sftp works [17:10] oh well [17:11] manuee: the files don't actually end up on the server, just the contents of .bzr [17:11] ow [17:11] humm so im missing a step then? [17:11] if you branch it though you'll see them :) [17:11] nope you've done it correctly [17:12] if you actually want the files to be uploaded to the server, look at the bzr-upload plugin [17:15] ow ok [17:15] thanks vxnick === kiko is now known as kiko-fud [17:15] no prob :) [17:17] http://bazaar-vcs.org/BazaarUploadForWebDev =)) [17:18] "No uploaded revision id found, switching to full upload" [17:18] that's fine [17:19] ah its cause its the first time right [17:19] yeah [17:19] oki [17:24] w00t its working [17:24] i dont htink i actualy need to push anything right [17:25] since im not versioning files over there [17:27] you don't need to push it if your'e the only one using the repo [17:29] ah k, i think im starting to understand things [17:30] so to remove what i did using push, i just delete the .bzr directory on the server, and all is like before there [17:30] yep [17:30] its nice it only adds it at one location, cvs is crazy like that (which is what the drupal proyect is under sigh) [17:30] hehe [17:30] i can barely get my head around cvs to maintain a couple of proyects i have on there [17:31] everytime i have to look up the docs lol [17:31] luckily bzr is a lot simpler :) [17:31] no doubt [17:31] thanks a ton for your help & patience vxnick [17:31] you helped a lot [17:32] a pleasure === beuno is now known as beuno-lunch === vxnick is now known as vxnick-AFK === deryck[lunch] is now known as deryck [18:28] jelmer: so ... I pushed up some code to log SVN editor activity on lp:~naesten/bzr-svn/355143-replay/ ... I added it to PathStrippingDirectoryEditor and PathStrippingEditor. Not sure if that was the best place, thogh... what do you think? [18:31] * SamB wonders how to set a PDB breakpoint in code he can't/shouldn't edit without using the PDB shell ... [18:35] SamB: edit code; import ipdb; ipdb.set_trace() ? [18:38] LarstiQ: I hesitate to do that to a module in the globally-installed standard library ;-) [18:39] SamB: be fearless! ;) [18:39] SamB: how about starting it with the pdb command then? [18:39] you can set a break, and then continue [18:40] I guess I could do that [18:40] somehow I'd gotten it into my head that that would not work ;-) [18:40] say, where is debugging of bzr documented? [18:42] SamB: HACKING I'd think [18:42] SamB: you're aware of BZR_PDB and C-\ ? [18:43] LarstiQ: yeah === beuno-lunch is now known as beuno [18:43] but it might be a good idea to remind folks that they can still use plain-old pdb? [18:43] sure [18:44] and the import pdb; pdb.set_trace() routine [18:44] LarstiQ: though the C-\ trick I picked up only by seeing sigquit listed somewhere related to BZR_PDB, and I think I found out that C-\ is the usual way to send one from wikipedia ... [18:45] SamB: doh [18:45]