[00:00] poolie, jam: how mysql team working with mainline? [00:00] show a pastebin of what? [00:00] bialix: they don't [00:00] jam said their branches are bushy [00:00] they don't worry about a separate mainline [00:00] sorry, a "specific mainline" [00:00] malibu: is this on windows or unix? [00:00] but it doesn't seem to be a problem [00:00] client on windows, server on ubuntu [00:01] jam, poolie: theoretical questions: if bzr will have command-line option to not generate dotted revnos but show merged revisions -- does it will help? [00:02] bialix: Here is my output: http://pastebin.com/m634fe87e [00:02] if dotted revnos is source of slowdown, then show only revid for merged revs might help? [00:02] bialix: it depends if you continue to preserve the merge info [00:02] if you want the "show merges just before the revision which merged them and after the one that did not" [00:02] it doesn't help [00:03] bialix, the main problem i know of with our approach is this, that numbering them is either slow or needs to be cached [00:03] though, i do think we need to do more to help people work well with undisciplined developers [00:04] poolie: so there are other options, like 'date sorted' [00:04] IIUC jam trying to say dotted revnos is part of problem? [00:04] jam: just a flat list, sorted by date? [00:04] it could be worthwhile [00:04] bialix: dotted revnos + merge sorting requires loading the whole graph [00:04] poolie: right [00:05] jam: and only merge sorting? [00:05] bialix: no merge sorting [00:05] sorry I should revise [00:05] if only merge sorting [00:05] bialix: as we're going through history, we want to see whether a revision should be shown as 'merged by r100' [00:05] merge sorting requires loading the whole graph [00:05] morning [00:05] while we do that, we compute dotted revnos [00:05] doing this requires checking whether it was merged by any previous revision [00:05] hey igc [00:05] hi igc [00:05] hi jam, bialix, poolie [00:05] good to see you [00:05] ok, thx for explanation [00:05] I've got a couple questions for cvs2bzr + fast-import [00:06] jam: fire away [00:06] igc: hi [00:06] igc: With just copying the cvs2bzr-example.options, I ended up getting a 'commit per branch' to "create the branch" [00:06] which is necessary in svn, but obviously not bzr [00:07] jam: so hg have natural sort order based on the order revisions come into repo? [00:07] bialix: it is 'topological sorted' [00:07] but yeah [00:07] when merging it fetches some revisions [00:07] that is the order [00:08] bialix: and in hg the sort can be different between different repos [00:08] jam: ok, understand [00:08] lifeless: I see [00:08] i wonder if it is strictly guaranteed to be topo sorted [00:08] so mainline concept in bzr is also about achieving consistency between different similar barcnhes? [00:08] if they ever get a ghost-like condition that may be broken [00:09] they have a single file - the 'revision revlog', which is indexed by integers - the 'insertion order' in the repo. [00:09] igc: is there a way to disable it? [00:09] bialix: yes, i think if you have two mirrors of the same conceptual branch, they should have consistent numbering [00:09] poolie: AFAIK hg does not support ghost [00:09] i don't think that is guaranteed true in hg [00:09] jam: I don't know whether that behaviour is controlled by options or just core cvs2fastimport behaviour. I suspect the latter [00:09] igc: so the problem with what I'm converting [00:09] their log and other operations that show ordering just start at revno=len(revisions.revlog), then count down. [00:09] is that they seem to create a lot of branches from the same rev [00:10] so the repo has 200+ branches, and like 100 are off of one rev [00:10] poolie: its not guaranteed true in hg; two branches with the same tip can have different revnos [00:10] both for the tip, and for antecedents [00:10] right [00:11] poolie: word "mainline" in the real life is about railroads? highways? [00:11] jam: the guy to ask is Michael Haggerty [00:11] igc: so we might just do trunk only conversions, but we'll see [00:12] all dictionaries I've looked so far is rather confusing about this term [00:12] jam: bzr-fastimport itself looks for unique heads and only creates branches for those [00:12] jam: well it's meant to at least [00:12] igc: well, cvs2bzr is creating fake commits for the branches... [00:12] though perhaps it only looks that way because I was just converting part of a module? [00:12] not sure [00:13] jam: ok, that that certainly sounds like something we want fixed in cvs2bzr [00:16] poolie: may I ask last question? do you read UQDS document from divmod.org? [00:16] bialix, yes, from railroads [00:16] or heroin ;-) [00:17] http://en.wiktionary.org/wiki/mainline [00:17] poolie: does it true to say their workflow is roughly equivalent to mainline paradigm? [00:17] bialix: i have a while ago, let me look [00:17] bialix: they are dealing with svn :P [00:18] i think that's broadly the type of flow that bzr encourages though [00:18] lifeless: yes, but they insist on having a lot of feature branches [00:18] * bialix will omit heroin meaning in the article [00:19] fullermd also said mainline comes to bzr from Arch, is it correct? [00:21] igc: how your experiments with windows installer? [00:22] bialix: it's my top priority this morning - just scanning email first [00:22] * bialix going to sleep, see ya later [00:23] poolie, jam: thanks for help [00:29] someone have experience with bzr on sf.net? is it possible to store several, unrelated branches there (sub-projects)? [00:31] poolie: yeah, sure [00:57] lifeless: any comments on bug 424797? [00:57] Launchpad bug 424797 in soyuz "lp.buildmaster.tests.test_manager.TestBuilddManagerScan.testScanRescuesJobFromBrokenBuilder failing silently" [Medium,Fix committed] https://launchpad.net/bugs/424797 [00:58] sorry bug 429747 [00:58] Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,Confirmed] https://launchpad.net/bugs/429747 [01:00] Good morning. [01:01] poolie: I have hpss userdir expansion working now [01:02] poolie: It's working nicely in manual testing, I have two small things left to do before submitting it, [01:04] poolie: a) change chroot.py to reuse the path filtering decorator, because it's very similiar; b) add some testing for the uglier bits of the ~ expansion logic (and for the way it is glued into serve_bzr) [01:04] hello spivvo [01:04] cool [02:20] lifeless: do you think you fixed bug 403322 implicitly with the delta fixes? [02:20] Launchpad bug 403322 in bzr "IndexError on moving added file" [High,Confirmed] https://launchpad.net/bugs/403322 [02:35] poolie: I doubt it === jamesh_ is now known as jamesh [02:58] jelmer: where is the new bzrtools package ? [03:06] I'm currently translating user guide to Japanese. [03:06] Some document assume default format is not rich-root. [03:07] filtered_views.txt: Bazaar's default format does not yet support filtered views. [03:08] svn_plugin.txt: Note that using the ``default-rich-root`` option to ``init-repo`` is important [03:27] jam: are you around ? [04:05] igc: The batching that fast import does [04:05] igc: does it hold more than 1 inventory in memory? [04:05] lifeless: yes [04:06] lifeless: up to 10 from memory [04:06] igc: are they Inventory or CHKInventory objects ? [04:06] it's a cache of configurable size [04:06] as in, are they what the repository creates, or a separate object? [04:07] igc: I'm [still] working on analysing the memory use from the fast import that hit the wall [04:07] igc: so far I've determing taht there are several hundred 90K long containers in the memory dump [04:07] lifeless: I'd need to check. What the repo creates I believe [04:08] igc: did you see the gzip stuff I cc'd you on? [04:08] lifeless: bzr_commit_handler builds deltas and gets the new inventory back from the layer below IIRC [04:08] lifeless: yes. looks interesting. [04:09] igc: ok [04:10] lifeless: I'm hoping to get back on to fastimport bug fixing next week [04:10] I'm fairly sure something is leaking, and 914662 is the ref list length, which is unlikely to be coincidental [04:10] (900K, not 90K :P) [04:10] lifeless: this week I'm still fighting windows installers [04:10] yup [04:16] mmm, I am again reminded of why I dislike ORM's. :( [04:48] whats the name of that branch option that makes it so that you can only append to a branch [04:49] ie. it prevents the scenario where you branch, commit, merge parent, and then push to parent overwriting it [04:53] cody-somerville: append_revisions_only [05:06] * igc lunch [05:48] jelmer: oh, and it looks like bzr 2.0 packages should conflict with bzr-doc ? [06:25] out for a medical appointment - bbl [06:37] poolie: did you get my draft yesterday? [06:49] hi [06:51] igc: ping [06:54] igc: the problem with win32event has no simple solution. you have to build full installer with tbzr on kerguelen to see the real result [06:54] * bialix bbl, I'll read irclogs [07:34] hi all [07:55] vila: hi [07:55] are you looking at all at the issue of conflicts caused by deleting directories containing ignored files? [07:56] all the issues I don't know, but all the conflicts including those of this type certainly [07:59] poolie: do you still plan to review shell-like tests ? I have some improvements already done on top of the pending patch... [08:03] poolie: including a better execution model, globbing, 'rm' command [08:03] poolie: and counting :) [08:06] vila, maybe i'll do it now [08:06] ok [08:08] Hi. [08:08] I'm new to version control, and I have a question. [08:09] vila, can you help me triage the New bugs? [08:09] not all right now, just a few a day [08:09] After going through some basic tutorials, it looked like with Bazaar, you need to run a command for every file you add. [08:09] Is there some option that looks for changed/new/removed/moved files automatically? [08:09] poolie: sure [08:11] WanderNauta: 'mv --auto' and then 'add' with no arguments will add the new files [08:17] poolie: is it possible to have simple fix for setup.py merged to 2.0.0? [08:19] poolie: this one: https://lists.launchpad.net/bzr-windows/msg00149.html [08:19] it's required only for bzr.exe [08:19] @poolie Thanks. [08:19] if you don't think it suitable before release, I don't bother to prepare merge request [08:20] and bonjour vila [08:21] hi bialix [08:21] hi Alexander [08:21] hi poolie, again [08:21] hi Vincent [08:22] bialix: it looks reasonable to me [08:22] so I'll do the merge request now [08:24] igc: around? [08:24] bialix: hi - just got back [08:24] hi [08:24] hi igc [08:25] have problem with your build recipe [08:25] bialix: feel free to change it [08:25] igc: http://pastebin.com/m63eea6fe [08:25] it blow up on bzr-explorer [08:26] Error: Abort uninstalling, because of pending local changes. [08:26] bzr st in explorer/trunk branch is clean [08:26] igc: am I missing something? [08:27] I've got this error while running make as of revno 15 over existing build-win32 [08:27] sidnei: are you here? [08:27] something wrong [08:27] I did not see this before [08:28] bialix: I suspect it's a problem but not one I know how to solve [08:28] are you adding uninstall action? [08:28] bialix: I certainly don't understand how the uninstall actions hang together, why they exist, what they do, etc. [08:28] * bialix trying to remove build-win32 and starting from scratch [08:29] bialix: I think that will work but ... [08:29] it may be quicker to go into build_win32 ... [08:29] everything worked for me at weekend [08:29] and then into explorer/trunk [08:29] and then run pull manually [08:30] bialix: I've been doing something like that instead of digging into the uninstall stuff [08:30] vila: do you remember yesterday we talked about wt format? [08:31] bialix: yes, you think you can fix it ? [08:31] branching over http works fine [08:31] do you know why? [08:32] I've just found that my 2.0.0 branch was cloned from http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0.0/ and it was in correct wt format [08:32] maybe that branch has actual wt? [08:32] but bzr info -v http:// does not say so [08:32] bialix: no idea, except that http use VFS [08:33] igc: I've removed build-win32 and still have the same problem [08:34] igc: that said that now I'm unable to build installer at all [08:34] igc: you'd better disable this uninstall stuff [08:34] igc: err, wait [08:34] bialix: I'm not sure what to do - I never touched the unistall stuff [08:35] bialix: I really think we need sidnei to help us here [08:35] no, EPEBKAC [08:36] it seems working, I've ran wrong command [08:36] working now after deleting entire build-win32 [08:44] poolie: https://code.launchpad.net/~bialix/bzr/2.0.0-setup.py-qbzr-deps/+merge/11767 [08:51] bialix: I'm heading off for the day sorry [08:52] igc: bye [08:52] bialix: please ping sidnei if the installer still has issues. Hopefully he can help us get them sorted [08:52] he's from South America? [08:54] igc: stuff seems to working now, from scratch [08:55] heading home soon [08:57] bialix: is it at all possible jam would object to it? [08:57] i don't expect so [08:57] bialix: yes, sidnei is in brazil i think [08:57] Rio Grande del Sul? [08:57] see https://edge.launchpad.net/~sidnei [08:57] poolie: I think everything is possible [08:57] :) [08:58] poolie: eta fro 2.0 final? [08:58] poolie: eta for 2.0 final? [08:58] soon, maybe tomorrow [08:58] i'd like to see if we can do the web site first but maybe we can freeze the code, get that up, then announce it? [08:58] poolie: this fix is not strictly required, as I've mentioned in revision commit message [08:59] poolie: it will be very nice to have it, but not critical === abentley1 is now known as abentley [09:09] hey guys. If I have 2 branches of a website-one on my machine and one on the server- and want them to have different database config files, how do I do that? do I just not version them? [09:09] Hi! I'm using sftp as proto on a server a long long time ago in a galaxy far far away, but it's rather slow. The process of commiting 30-50k worth of text takes about 1m, including connecting and uploading. Is there a faster/better protocol? [09:10] spirov92: usually you don't have site or user specific configurations in the repos [09:10] ok, thanks [09:11] so how do I exclude a file from versioning without deleting it? [09:13] spirov92: bzr ignore [09:13] or pattern [09:15] I did bzr ignore application/config/database.php.. [09:16] "These files will continue to be version controlled unless you 'bzr remove' them." [09:16] and when I modify the file and do bzr diff, it shows the changes [09:33] spirov92: bzr rm --keep [09:33] grr, gone [09:35] Odd. [09:36] I think ignore should do whatever it takes to actually ignore the file [09:36] OR they should rename it to "ignore-maybe" [09:36] it's counter intuitive and unproductive with the extra step of removing the file [09:48] SamB_XP: there is a bzrtools package in experimental [09:48] SamB_XP: bzr-doc ? === kgoetz is now known as Kamping_Kaiser [11:30] vila: It's quite unfair of you to not be getting errors :| [11:30] fullermd: yeah, so totally unfair :-/ [11:31] MP maybe? My 7.x box is 2-core, and 8.x is 4-core. It doesn't seem overly likely that that would matter, would it? [11:31] The tests are sequential... [11:32] MP leading to revision not found, wow, you're truly desperate :) [11:32] my VM is 4 cores [11:33] I can't imagine how it would, since (a) any given test is sequential, and (b) it's so stupidly perfectly repeatable. [11:33] But yeah, desperate :p [11:33] f00f bug? [11:34] That was lockups, not VCS horkage :p [11:34] (and bzr _better_ not be doing floating point division, either...) [11:35] endianess ? [11:35] We're all little-endian. [11:35] sadly, yes [11:35] just checking [11:36] I wonder if anybody IS running bzr big-endian. SPARC I guess. AIX guys maybe? Isn't RS/6000 big-endian. [11:36] * LarstiQ has retired his ppc :( [11:37] RS/6000 is power-era old I believe, so probably [11:37] I have a BeBox... [11:37] First *nix system I adminned was an RS/6000. The scars are still quite visible. [11:37] * fullermd twitches. === beuno is now known as beuno-lunch [11:37] Pff, SunOS was worse I'm sure [11:38] SunOS was a dream, relatively :p [11:38] ouch :) [11:38] I did UUCP sendmail ! [11:38] moin * [11:39] I certainly don't believe you have some magical data corruption causing tests to _pass_. That would be nuts. [11:39] And I know I don't causing them to fail. It wouldn't be near so deterministic, and anyway I have ECC memory and ZFS with SHA256 block checksums. [11:39] (if my data goes, I intend to KNOW about it) [11:40] zfs... [11:41] Timing issues? Wouldn't be deterministic. System libraries? Ours should be near enough as no difference. [11:41] * fullermd frowns. [11:42] racing issues with zfs sounds worth checking [11:44] What race? All it does is read the .py_ files. [11:45] fullermd: if I knew I wouldn't want to try [11:45] Temp files are gone so fast they'll never hit disk, and even if they did, they'd be read back out of the buffer cache. [11:45] (and anyway, my /tmp is plain old md-backed UFS) [11:45] all the tests run in /tmp [11:45] md-backed ? [11:46] Memory filesystem, swap backed (but it never needs to hit the swap) [11:46] (well, memory block device actually) [11:46] hmm, I didn't set that for freebsd, but I use it for jaunty [11:48] Ordering? No way, I can run any of them individually and get the same failure. [11:49] !!! [11:53] I guess I'll have to find time at some point to sit down with one of them and try single-stepping :( [11:53] fullermd: I'm trying to see if one is simpler than the others [11:54] Well, the first one on the list is probably the obvious choice. [11:54] blackbox.test_info.TestInfo.test_info_standalone [11:54] I think the rest are per_whatever's, so there are lots of formats to loop through. [11:54] blackbox tests are hard to debug because of the redirections (not all though) [11:55] pfff, talk about LOCALIZATION DEFECT, seen the test in question ? [11:56] 433 lines... [11:56] sorry for yelling [11:57] yeah, the info tests... [11:57] ...besides, that defect localization, so there [12:05] fullermd: can you try with a newly created user (just to rule out some more possible leaks) [12:05] fullermd: running a single failing test should be enough [12:06] but what if it doesn't fail! [12:06] then he'll have to run *another* one! [12:12] SamB_XP: ^ [12:12] SamB_XP: there is a bzrtools package in experimental [12:12] SamB_XP: there is no bzr-doc package [12:12] jelmer: there isn't ? [12:12] than what was that thing I had installed ? [12:15] SamB_XP: "rmadison bzr-doc" agrees [12:16] * SamB fires aptitude up [12:16] * SamB wonders why his computer rebooted almost 5 hours ago, anyway ... [12:16] * SamB thought he'd fixed that by making it clock down when it got hot ... but could it have been a power outage of some kind ? [12:17] jelmer: it's from bzr ppas [12:19] the available versions are, uh, [12:20] 1.18-1~bazaar1~jaunty1 and 1.18+4684+126~9.04 [12:21] jelmer: and I am not seeing this experimental package you speak of [12:22] * SamB notices that the PPA packages of bzrtools are laxly versioned [12:22] * SamB tries one of those [12:23] (er, have laxly-versioned dependencies on bzr, that is) [12:26] ... heck, it apparently even loads ... [12:26] jelmer: so, you should really sync up with the PPAs somehow ? [12:27] in terms of what packages are built for bzr itself ;-) [12:42] vila: did you land the setup.py change to the bzr/2.0.0 branch? [12:42] (morning) [12:42] morning jam ! [12:43] pqm'ed it when I said "I'll merge" [12:43] something wrong with it ? [12:43] jam: I thought you had an already full plate this week... [12:43] I haven't seen it yet, and I'm hoping to have win32 installers for them to use [12:44] vila: looks like it is just in pqm now [12:44] jam: was about to tell you that :-) Just in front of yours [12:44] I guess you said "ill merge" 20 min ago [12:45] so about right [12:45] vila: I'm just waking up [12:45] jam: how are things going ? [12:46] Running [ 0% 1 test(s) ] Current test: /home/pqm/bzr-pqm-workdir/home/2.0.0/bzr [12:46] the training and such is going fine. It's pretty informal [12:46] vila: I'm pretty sure the status line is completely borked :) [12:46] :-D [12:46] too bad.... [12:46] And now that we have no "[ascii]" tests, I don't usually have a good feel for when it will be done [12:47] jam: well, you feel it's faster at least :) [12:47] vila: sort of... it is still something you send out and then forget about by the time you get the success/failure message [12:54] vila: of course, while all of this is going on, igc and bialix are changing the installer, and how we build the installer, and ... [12:54] It is all good in the end [12:54] but painful for me [12:55] even stupid stuff like now we depend on "doc.bazaar-vcs.org" for the pre-compiled help files [12:55] which means I have to add the doc.bazaar-vcs.org to the hosts file so that it can be found [12:55] :-/ [12:55] for some reason buildout is *really* slow (maybe just the machine?) [12:56] * vila is still slowly setting up a windows dev env as automatically as possible... [12:57] vila: is bug 424913 a wishlist or a won't fix? [12:57] Launchpad bug 424913 in bzr ""bzr pull -r 10000" doesn't pull entirety of 9998-rev branch" [Wishlist,Confirmed] https://launchpad.net/bugs/424913 [12:59] a wishlist [12:59] The wish is that the error message could say: [12:59] revno 10000 does not exist, the last revision is: YYYY [12:59] which might work as well. [12:59] comment added there [13:03] vila: And my point is I don't think we are going to ever do that... [13:03] huh, so much for multi-pull -q :-( [13:03] the issue is where are you strict about input, because it indicates typos [13:04] the actual desire of the person in that bug is to have resumable fetch... [13:04] jam: you can be strict and displays an informative message [13:04] anyway, still trying to get 2.0.0rc2 built, but I have to go get some food [13:05] jam: that person is me, btw [13:05] SamB should speak with bialix who wants to implement a multi-step push/pull [13:05] SamB: *I* know :) [13:05] vila: imo, we should change the internal to just fetch 1k revs at a time... but certainly it can be implemented otherwise [13:05] SamB: Let jam wake up peacefully please === beuno-lunch is now known as beuno [13:05] it was so wierd to slowly realize that he was talking about me ;-) [13:06] oops forgot a smiley there [13:06] jam: I missed the discussion but bialix seemed to think the consensus that this will not happen, or not soon [13:07] SamB: I don't see how any of this would block a "multi-pull -q" [13:07] If you have a command that ones to pull a bunch of branches [13:07] jam: that was an unrelated statement [13:07] have it connect, find the last revision, and then split it up [13:07] I said that before I noticed you had been talking about me ;-) [13:07] I said it because it's not all that quiet ... [13:09] ... even if I give it /dev/null for stdin and pass stdout and stderr through cat :-( [13:10] Ew. I'm not cleaning THAT litterbox... [13:10] well, I'm rather pleased that that didn't affect it [13:10] but displeased that it was not quiet [13:10] SamB: file a bug [13:11] with at least the strings that escape your humt :) [13:11] vila: well, I guess I'd better try the latest first to make sure [13:11] hunt, damn it [13:11] my hunt ? [13:12] track ? redirecting stind because -q does not work sounds like "output hunting" to me :) [13:12] oh, I thought maybe you were suggesting that I ought to look inside ... [13:12] feel free to hunt where you see fit... [13:13] hmm, "push -q" with no explicit target isn't quiet either [13:17] okay [13:18] somebody seems to be trying to use my uncylclopedia account ? [13:18] (maybe they thought it was theirs ?) [13:31] vila: http://pqm.bazaar-vcs.org/ [13:31] I see [ascii] tests running... [13:31] maybe it wasn't "fixed" on the 2.0.0 branch? [13:33] 8-) Ouch, fixed in trunk after 2.0 splitted I guess [13:34] err, that was 8-( [13:39] Isn't that intentional? [13:40] fullermd: the typo or the [ascii] tests ? [13:40] The ASCII tests. [13:42] The constraint was relaxed because the botnet took charge. [13:42]