[00:47] poolie: if you're doing reviews, a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081027005419.GA20736%40steerpike.home.puzzling.org%3E would be good. [00:47] spiv, ok [00:47] am doing mail atm but will try to get to it [01:58] * spiv fires some branches to the mailing list and goes to lunch [02:10] extmerge doesn't like me. :( [02:10] Unable to load plugin u'extmerge' from u'C:/Program Files/Bazaar/plugins' [02:12] pdf23ds: try "bzr -Derror ...", or look in your bzr.log (see "bzr --version" for its location) to get a traceback that may explain why. [02:12] pdf23ds: if nothing else, the traceback will be useful in a bug report against extmerge :) [02:13] OK, I think it might have something to do with abently's commit yesterday. [02:13] * spiv really goes to lunch now [02:13] AttributeError: 'dict' object has no attribute 'register_lazy' [02:14] But thanks for the tip. [02:14] How to change the tree to an old rev? [02:14] Just my luck to have a commit yesterday break me on a project that hadn't seen any commits since March. [02:15] bzr up -r x? [02:18] bzr revert -r x [02:19] crazy australians. going to lunch at 9 PM. [02:59] Anybuddy know how to resume when you get conflicts with the replay command? [02:59] rebase-continue? [03:07] pdf23ds: does the help tell you? [03:07] bzr replay help is empty. [03:07] and bzr rebase help doesn't say explicitly. [03:07] I filed a documentation bug. :) [03:08] In the meantime I guess I'll try and see what happens. [03:13] It sort of acts like continue might do the right thing, tho -abort and -todo complain that you're not rebasing. [03:14] Hmm. I didn't mess as much with Mercurial, but Bazaar seems much rougher-around-the-edges than Mercurial. But I still like it more. [03:14] And OTOH, I just ran into a Subversion bug today with the latest version. [03:15] (Couldn't merge a path with spaces over https protocol, works over svn protocol. Weird.) [03:17] meep [03:18] please file a bug [03:18] About replay you mean? Where should I file that? [03:19] https://bugs.launchpad.net/bzr-rebase/ ? [03:20] (The merge thing was a SVN bug I just got hit by today.) [03:20] about the https file with spaces thing === spm_ is now known as spm [03:21] yeah, that's svn. [03:21] I had the same reaction. [03:22] a bug on bzr-svn would be good for that; it may be something jelmer has msised [03:23] It wasn't related to bzr, I mean. [03:23] I work with SVN during the day, I'm converting my home projects to bzr. [03:24] I won't be able to get my job using bzr until TortoiseBZR is mature, and until I convince my coworkers of the joys of branching. [03:24] Hi party ppl, I seem to be having some problems with interop between bzr v1.3.1 and v1.6.1 but only on some branches. [03:25] Most of our dev machines (and the repo) are on Hardy, with bzr 1.3.1. But on a certain big repo when I try a checkout with v1.6.1 (on Intrepid) it first complains about the server not understanding net protocol 3, then falls back to an earlier protocol, then sits for a minute or two, then bombs with a traceback like this: [03:25] File "/usr/bin/bzr", line 119, in [03:25] sys.stdout.flush() [03:25] ValueError: I/O operation on closed file [03:25] ...which looks like a permissions problem, but I don't think it is [03:25] because checkouts work fine from Hardy machines [03:26] Any suggestions where to look? I tried with -Dhpss and it didn't provide any more detail [03:28] Hmm. Maybe I don't need replay after all. Rebase might do the job. [03:29] jonoxer: I don't think its interop [03:30] jonoxer: 1.6 has some memory issues; try 1.8 [03:30] lifeless: so maybe it's a problem with this particular client [03:30] lifeless: OK, I'll give it a shot [03:32] Nope, rebase requires a common ancestor too. [03:32] Revision 0 isn't considered a common ancestor, right? [03:32] bzr branch A B -r 0 is the same as bzr init B? [03:46] pdf23ds: nearly the same; branch will preserve the specific format whereas init will use the current default [03:47] this only matters if either the source branch uses a very new feature, or you're interoperating with clients much older than yours [03:53] lifeless: Well, it matters if you want to merge those branches later and find out it can't be done. [04:01] Wow, bzr doesn't like it when my local commits are identical to upstream commits, and I do a "bzr up". [04:01] Almost everything showed up as a conflict. [04:02] mkanat: it shouldn't conflict there; unless you added files [04:02] mkanat: when you say "identical", do you mean the files actually are identical? As in the same checksums? [04:02] jonoxer: No, I have local uncommitted changes in addition to the local commits. [04:03] jonoxer: Also, the upstream files may have different permissions than my local files. [04:03] permissions shouldn't be an issue there; its likely the local changes [04:03] mkanat: but there are some things update does that make conflicts worse than they should be [04:03] Yeah, that's probably what I'm running into. [04:03] I was just surprised, didn't know if you guys knew it behaved that way. [04:04] It's not that bad, I have my local changes as a patch elsewhere and I can just revert and re-apply them. [04:13] lifeless: I've just upgraded the problematic machine to bzr 1.8.1 (package from ppa) and it still bombs out on a checkout from the same repo [04:13] The error message is identical to with 1.6.1 [04:15] The repo is shown as "Shared repository with trees (format: pack-0.92)" fwiw [04:16] The branch I'm checking out takes about 7.8G on disk, in case that's relevant [04:19] jonoxer: hmm, perhaps we haven't landed the patch yet [04:19] lifeless: think it's worth trying 1.3.1 on that machine? That's what we're running on every other box, and it works fine [04:20] jonoxer: I suspect it will work, yes [04:21] I'm surprised bzr-loom isn't listed in http://bazaar-vcs.org/BzrPlugins [04:22] lifeless: it seems to be working (1.3.1 on Intrepid) [04:25] jonoxer: the memory patch may not have landed; or it may be something else [04:25] jonoxer: please file a bug [04:39] No problem, done (Bug #290558) [04:39] Launchpad bug 290558 in bzr "bzr v1.6.1+ crashes when checking out large branch from v1.3.1 repo" [Undecided,New] https://launchpad.net/bugs/290558 === ozzloy is now known as lbc === lbc is now known as ozzloy === jfroy|work is now known as jfroy [05:42] spiv, i agree with your comments on the hooks doc patch, so i'll apply them and merge it [05:48] poolie: great [05:49] i still find your nickname kind of bizarre :) [05:50] I should trawl a dictionary for more flattering four letter words that are unlikely to already be registered on popular services... [05:50] http://newmatilda.com/2008/01/17/attack-spivs [05:50] excuse the distraction [05:50] "They no longer sport pencil-line moustaches and porkpie hats, but their tell-tale signs give them away - their faux Italian pointy-toe shoes and the hairstyles sculpted into those absurd little tufts. " [05:50] indeed :) [05:50] Oh, I don't mind being distracted. [05:51] That's the problem ;) [05:51] (: [05:53] night all [05:55] cheerio [06:07] spiv, can you look at my reply there quickly? [06:07] by quickly i mean 'it should not take long' not 'urgently' [06:13] poolie: the reply to the hook docs patch? Looks good to me. [06:13] thanks [06:13] i'll send it in [06:25] * spiv -> yoga [06:25] (and hacking on the train) [06:27] i'm going to stop in a bit [07:07] hi all [08:15] Hi ! Is there bzr-gtk release 0.96 ? I see in maillist: Status: Fix Committed => Fix Released Target: None => 0.96.0 but nothing about 0.96 on http://bazaar-vcs.org/bzr-gtk .. [08:38] matkor: 0.96.0 is where the commits are made to *prepare* 0.96 :) === jfroy is now known as jfroy|work [08:39] matkor: i.e. the trunk, a specific branch will be made once 0.96 is out I think [08:43] vila: Ok.. so status (Fix Committed => Fix Released) change is misleading ? shoudl be left on Fix Committed ? [08:44] matkor: committed means the fix is available somewhere, released means it's merged on trunk [08:46] ah ... thanks a lot for explanation, vila [08:47] you're welcome and not the first one needing the explanation which indicates something should be changed though... [09:28] vila: Perhaps: Fix Commited -> Fix merged mainline (or Accepted to next release) -> Fix Released (in official version) could be more self-explenatory ... [09:32] The last step means that releasing a version requires an additional step whereas the actual usage doesn't... Most of the users will update only when a new release is announced and are unaware of the subtle difference. I know there is work in progress to somehow automate that step but I forgot the details [09:57] Presumably launchpadlib will allow it to be done (if it doesn't already). [10:11] Odd_Bloke: what was that? [10:13] thumper: Marking bugs as Fix Released when an actual release happens. [10:13] Odd_Bloke: ah [10:13] thumper: A better fix might be to fix the bug statuses though. ;) [10:13] heh [10:14] I'd say that a fix is "in progress" until it is landed on trunk [10:14] but hey, that's just me [10:15] I did manage to get an hg->bzr convert last night [10:15] just with "versioned directories" and "bzr shelve" [10:15] Well, 'we' (i.e. bzr) do (In Progress) --submitted for review--> (Fix Committed) --merged--> (Fix Released). [10:16] * thumper nods [10:18] congratulations jelmer [10:22] lifeless: ping [10:24] james_w, thanks, but with what ? :-) [10:24] heh :-) [10:33] jelmer: I'm guessing for your AM report... [10:33] ah, I wasn't aware that was announced someplace [10:37] jelmer: debian-newmaint list. [10:37] jelmer: you know https://nm.debian.org/nmstatus.php I guess [10:37] Odd_Bloke, ah, thanks [10:38] LarstiQ, I don't expect (hope?) James to check that on a daily basis :-) [10:38] jelmer: James has resigned from DAM work afaik [10:38] oh, james_W [10:38] sorry :) [10:38] jelmer: yeah, debian-newmaint [10:39] * LarstiQ takes this as a clear sign he should do something about breakfast [10:48] LarstiQ, :-) [10:49] jelmer: Also on a Debian related note, is there any documentation about how to use the pkg-bazaar repository? I haven't been able to work it out, and I have an ITP for bzr-xmloutput sitting around. [11:01] Odd_Bloke, basically, we have one repository on bzr.debian.org per package [11:01] and then one branch per debian distribution (unstable, experimental) [11:02] the branches are bzr builddeb branches, and should ideally contain the upstream source plus debian/ directory and any necessary changes [11:34] jelmer: Bug 290664 is the one I promised to file a couple of days ago. [11:34] Launchpad bug 290664 in bzr-svn ""Can't get entries of a non-directory"" [Undecided,New] https://launchpad.net/bugs/290664 [11:41] Odd_Bloke, thanks, I hope I can have a look at it during the weekend [11:42] jelmer: I have commit access, so if there's a way I can fix the repository using that I'd be happy to do so. [11:46] Odd_Bloke, it should be possible to add a fix for this to bzr-svn, I just need some time to analyse what's going wrong [11:47] jelmer: Cool, I really meant if a repository fix would be possible sooner, then I'd like to do that. :) === doko_ is now known as doko [13:03] beuno, loggerhead made it into experimental btw [13:03] jelmer, I saw! [13:03] I've been spying [13:03] thanks :) [13:03] :-) [13:04] you're welcome [13:04] I hope we can now help get it running on bzr.debian.org [13:05] oh, I didn't know they needed help [13:05] let me know if I can do anything at all [13:07] will do [13:07] thanks === Verterok|out is now known as Verterok [13:24] what is the easiest way to search for a revision that removed a couple of lines? [13:34] hey can i revert a single file to a specify version using bzr revert -r 46 foo.py ? [13:35] jelmer: abently's latest commit to extmerge breaks it on 1.8. I had to figure that out myself after branching. [13:51] pdf23ds, ? [14:53] vila: ping [14:53] jam: pong [14:53] hey, want to chat about the inventory stuff? [14:53] sure [14:53] I haven't heard any background to know if robert's idea is corerct [15:28] hi asmodehn [15:29] hey hey jam ;- [15:29] ;) [15:31] I'm a bit surprised you sent the .bzr.log to the list, but I suppose filenames aren't particularly private [15:32] it does give me a little bit of insight into your game, though :) [15:32] oh did I ^^ [15:32] you certainly have a very *wide* tree (lots of files) [15:33] approx 30k [15:33] nah I only sent it to you I think ;-) [15:33] dont scare me like that :-p hehe [15:34] anyway as you can see I dont use bazaar to store the source code, but rather distributing different version of it in differnt locations [15:34] which explains the size and the latency I am dealing with.. [15:34] asmodehn: you're right, I wasn't looking at the folder I was in [15:35] but yes lots of big files [15:35] the repository with working trees is now 24GB [15:35] so whenever I doa branch it takes some time :-p [15:36] especially when it s remotely [15:36] I also have scripted the beginning of an automated framework on top of it, to keep different location in sync, with web interface, etc. [15:36] just a beginning :-p [15:38] also because of the size of it my disk is pretty full now, not sure I can do a lot of tests ... I am lacking backup space... [15:39] well, if you want to try my "convert_to_dev2" script, you can actually just use a hardlink of the old repository [15:39] and the only new data will be the indices [15:39] which is small meg [15:39] rather than 24GB [15:40] mmm ok.. no need to upgrade before at all right ? === dobey_ is now known as dobey [15:41] ha yeah ok this is doing the upgrade... ok I ll do that then and let you know... [15:42] so I should say maybe 10MB or so, but that is pretty trivial next to the 24GB. But I would only do it on a copy [15:42] for now [15:43] then again [15:43] I could just write you the reverse script [15:43] to convert them back [15:43] not to mention my convert_to_dev2 script leaves them lying around, IIRC [15:43] thats good enough then, if I can put tehm back somehow ;-) [15:43] I have remote backups if needed [15:44] yeah [15:44] the script creates new indices [15:44] and just moves the old one out of the way [15:44] without deleting it [15:44] I just verified that [15:47] "python convert_to_dev2.py" and thats it correct ? [15:47] * asmodehn just a bit scared :-p hehe [15:49] jam : ok running... [15:49] you have to have "bzrlib" in your python install, but it sounds like you do [15:49] I'm looking at it now [15:49] just for your comfort [15:49] thanks ;-) [15:50] jam : ok done ^^ pretty fast [15:51] yeah, that is all you needed to do [15:51] asmodehn: again, rewriting 20MB isn't bad versus rewriting 24GB [15:52] ok but I changed only the repository I am branching towards, not the repository I am branching from.. [15:52] do I need to do that too ? [15:52] yep :-) [15:52] the one you are branching *from* is the important one [15:52] yeah I would have guessed so.... [15:52] mmm hang on... [15:52] I'm also not 100% sure if you need my prefetch code [15:53] Are you comfortable running bzr from source instead of from an install? [15:53] (it isn't very hard) [15:53] mmm it should be ok, but I really want to avoid to mess up my repositories too much [15:53] so I guess I ll try one thing at a time ;-) [15:54] but yeah I could do that... [15:54] it doesn't change the disk formats at all [15:54] *just* how we access it [15:54] but start with this [15:54] see what happens [15:54] k [15:54] and then we'll try that as the next step [15:55] also, can you run a quick command for me [15:55] sure [15:55] find .bzr -name "*.?ix" -print0 | xargs -0 du -kshc [15:55] I think that is right [15:55] let me run it here [15:56] yeah, that works [15:56] ok on which repo ? [15:57] the source one right ? [15:57] the one you just upgraded [15:57] ah ok [15:57] you could do the source as well [15:57] I mostly just want to see how big your indexes were [15:57] versus how big they are in btree format [15:57] oh ok [15:58] I l send hte result in email ot you ;-) [16:01] done [16:02] ah I have enough space on the disk of the source repo to back everything up :-) good news ;-) [16:04] backup everything ^^ sorry me english bad :-p [16:04] I m doing that now then I convert to dev2 as well so I can try the branch again... [16:08] how do i revert a commit? is it the same way that you do it in subversion? merge the changes between new and old back into the working copy? [16:08] bzr uncommit is your friend ;-) [16:09] if you really want to lose your commit [16:09] asmodehn: so from what I can see, your 31MB text index becomes 9.1MB in btree form [16:09] and your 14MB => 4Mb [16:09] MB [16:09] which is good [16:10] yep wouldnt hurt ;-) [16:11] if we want to add log to the data transfer, I would need to run bzr from source and modify it right ? [16:11] asmodehn: great thanks, i'll take a look [16:11] cause at the moment the log doesnt display nothing while the process seems to be stuck... [16:11] dstanek : no worries ;-) [16:12] dstanek: you could also do "bzr merge -r 10..9" if you want to revert something old [16:12] but yeah, 'bzr uncommit' is probably what you want [16:12] if it was recent [16:12] (as in the last commit) [16:13] asmodehn: so the index seems to go from almost 70MB to down to 30MB, which is about what I would expect. [16:13] Also, it does look like this repository could stand to have "bzr pack" run [16:14] Though I'll mention that running it after the conversion means we don't have a simple way of bringing the indexes back [16:14] it look like uncommit can also take a -r argument - will it work if you specify a revision that is not the last? [16:14] dstanek: it will uncommit everything back to that revision [16:14] not just the changes for that rev [16:14] for something old [16:14] ah i see [16:14] you want "bzr merge -r REV..REV-1" [16:14] sorry [16:14] you want "bzr merge . -r REV..REV-1" [16:14] yeah I was thinking about that too... but I wonder if that might make one big pack, and therefore we might lose some details in debugging what is wrong in the data transfer [16:14] the '.' is important [16:15] asmodehn: it will create 1 big pack [16:15] so we can look at that more later if you prefer [16:15] jam: uncommit works for my immediate need [16:16] jam : also having one huge pack might not be good for me if there is no way to track the progress of the download... [16:16] I prefer downloading slowly but know that it s working ;-) [16:17] btw, same thing, is there an incremental pull / push ? [16:17] revision by revision ? [16:17] asmodehn: 'bzr push -r X", "bzr push -r X+1" [16:18] yes but when I have 123 revision to push one by one because they are big and they might fail, I dont want to type that 123 times ;) [16:18] was thinking of a "bzr ipush -r REV..REV " that will push revision one by one [16:19] and if it breaks in the middle, the last push that worked is still there... [16:19] but maybe that belongs more in a script around bzr than bzr itself [16:19] jam : ... my backup copy on the source repository is still going... [16:20] asmodehn: for i in `seq REV..REV`; do bzr push -r $i; done [16:20] sorry [16:20] for in `seq REV REV`; do echo $i; bzr push -r $i; done [16:20] yeah thats what I meant ;-) [16:21] but you want to check for error and stuff, so I ll gues I ll write a script for that... [16:21] eventually [16:21] at the moment I am pulling revision 10 by 10 to know a bit where I am at... [16:25] well, I'll mention that some of the data transferred is forgotted by the next copy [16:25] so it will be slower [16:27] yep I start doing that when using 1.5, because for long transfer it used to error out [16:28] where few by few it was working [16:28] and since I upgraded to 1.8 it doesnt error as much which is good ;-) [16:28] but it seems to get stuck longer for smoem reason :-s [16:32] 1.8 will switch to grabbing whole indexes from time to time, which might be what you are seeing [16:32] 1.5 would only grab incrementally [16:32] but could end up grabbing 2x the inventory under certain circumstances [16:33] the dev2 format solves both of those issues [16:33] cool ;) good to know [16:33] backup copy almost finished... [16:55] asmodehn: how's it going? [16:55] jam : branching now... [16:55] conversion went without problems [16:55] you're using -Dhpss for me, right? [16:56] yep [16:57] but looking at the log... the copy of the index is fine... [16:58] looks like the copy of the pack doesnt generate a lot of transfer on teh network though.. I am a bit confused... [16:59] copying the pack should be saturating your network [16:59] my pick is 1.2Kbps now ... [16:59] are you sure about that? [16:59] looking at iftop onthe source network now.. [17:00] source server I mean [17:00] it was high up during indexes [17:00] my only other guess is that you are running into swap issues on the source [17:00] oh^ [17:00] mmm I ll check my RAM.. [17:00] as we are trying to copy 20GB across [17:01] nope everything looks fine [17:01] source : [17:01] Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st [17:01] Mem: 3366488k total, 3221756k used, 144732k free, 1672k buffers [17:01] Swap: 2650684k total, 702536k used, 1948148k free, 558160k cached [17:01] dest : [17:01] Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st [17:01] Mem: 6110456k total, 5198228k used, 912228k free, 78484k buffers [17:01] Swap: 1951888k total, 72k used, 1951816k free, 4550312k cached [17:02] and I am still branching -r1 from a repo on source_dev2 [17:02] \ [============================= ] Copying content texts 3/5 [17:03] 700MB in swap seems like a lot to me [17:03] but I don't know what load you run on that server [17:03] well these server are running a bunch of other things ^^ [17:04] so you are still seeing very little data being copied, right? [17:04] but that swap used is not increasing right now anyway [17:04] no transfer ont eh network [17:04] well very little [17:04] and with -Dhpss [17:04] you might try top of the running process as well [17:04] it is also possible that your disks are being heavily loaded ATM [17:04] log stuck at 85.410 result: ('readv',) [17:04] 105.947 1099613 body bytes read [17:04] 108.023 hpss call w/readv: 'readv', '/home/autobzr/deployBZR_dev2/.bzr/repository/packs/f65de233ce31cbdace7370611f49937c.pack' [17:04] 108.024 11675 bytes in readv request [17:05] asmodehn: can you send the 'ls' results for the remote repository? [17:06] I would assume that is a big file, but it isn't in the listing you sent [17:06] (since that is the local repo) [17:08] this pack is 1.1GB [17:10] source : [17:10] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [17:10] 12072 autobzr 20 0 1925m 1.9g 2404 S 0 58.4 0:03.46 bzr [17:10] dest: [17:10] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [17:10] 25889 autobzr 21 0 228m 159m 3956 S 0 2.7 0:06.94 bzr [17:11] so it is consuming 1.9GB, which may not be terrible, but isn't a great sign [17:11] yep [17:11] mostly for when you hit the 20GB files [17:11] It is possible that is taken up by other info [17:11] but I'm expecting it is the actual data that will be transmitted [17:12] asmodehn: I think it is going to have serious problems soon. I'm seeing: [17:12] backing_bytes = ''.join(bytes for offset, bytes in [17:12] self._backing_transport.readv(self._relpath, offsets)) [17:13] which means... "read the requested bytes, and buffer it into a single string" [17:13] and return that [17:13] ah... [17:13] aka, buffer 20GB in RAM before sending it over the wire [17:13] that will not work :-p [17:15] so... the specific issue is that since 1.6 we are able to request the streams for multiple files simultaneously [17:15] in 1.5 we could only request one file at a time [17:15] which makes things way faster in most cases [17:15] but in your case [17:15] it means we end up requesting 90% of the pack file in one go [17:15] and you end up dying [17:15] argh [17:16] yep... [17:16] we could probably work around this a little bit in the client [17:16] by capping the size of a readv request [17:16] but that also means there no easy perfect solution right ? [17:16] ie, how much oyu are capping will depend on the RAM size, the badwith, etc. [17:17] yeah [17:17] but something like 500MB is generally a safe bet [17:17] also, could you try this over sftp [17:17] ? [17:17] I realize some bits will be slower [17:17] yep [17:17] but I think it the SFTP spec requires that we transfer in 32kB chunks [17:17] so it won't actually hit this [17:17] oh ^^ [17:17]