[00:11] spiv: seen poolie [00:12] spiv: I think its because the command finding hooks have been cleared inappropriately [00:12] spiv: and/or a chdir has been done inappropriately. [00:13] lifeless: hmm, quite likely. [00:14] lifeless: regarding poolie, I haven't seen/heard anything. [00:20] jelmer, hello? [00:20] Noldorin, hi [00:21] hey [00:21] jelmer, any idea about that strack trace for bzr-svn? [00:21] Noldorin, which stack trace? [00:22] jelmer, http://pastebin.com/m122b7c64 [00:22] did you catch any of the convo with spiv ? [00:22] no, I haven't [00:22] that describes it all anyway...trying to push to an svn repo with bzr-svn [00:22] always worked until recently :S [00:23] Noldorin: have you pushed to this codeplex repository before? [00:23] jelmer, yep, worked many times [00:23] and haven't really changed the bzr repo [00:23] it might have happened when i cancelled a push to svn one time :S [00:23] Noldorin: remove the 'layout = None' bit in ~/.bazaar/subversion.conf [00:24] jelmer, it has guessed-layout = None [00:24] do i want to remove that? [00:25] Noldorin: can you remove that ? [00:25] (or comment it out?) [00:25] ok [00:26] jelmer, ok, it's doing better now... [00:26] [- ] 208KB 3KB/s | analyzing repository layout:fetchi [00:33] hi spiv, lifeless? [00:33] jelmer, 1900KB now...seems to be going a bit long :/ [00:34] Noldorin, it'll do the full repository analysis again now [00:34] fair enough [00:35] jelmer, so what's thie about layout...? why do i have to remove that line from the conf file? [00:36] Noldorin: it contains the guess repository layout [00:36] you had to remove it because it contained an invalid value (None) [00:36] ah [00:36] not sure how that got in there though [00:36] so by default there shouldn't any there...? [00:40] poolie: good morning [00:40] Noldorin: it should be there, it should just have the right value :-) [00:41] Noldorin, does it work now? [00:41] jelmer, ah fair enough...still going [00:41] 3500KB now [00:41] what should be the right value? [00:42] Noldorin: it'll be determined by bzr-svn automatically [00:42] ok [00:42] or you can specify one - see "bzr help svn-layout" [00:42] fair enough. [00:42] heh, just waiting still. 4MB seems like an awful lot, and it's still going ... [00:45] abentley: the fix for you has landed [00:45] poolie: hi [00:50] jelmer, does this make sense that so much is being downloaded? 5.5MB now and 0/36100 [00:56] it looks like it's downloading the entire revision history of codeplex, hah :P [00:59] Noldorin: No idea, sorry [00:59] Noldorin: it might be a codeplex issue, I've seen issues with it before [00:59] ah right [00:59] hrm [00:59] no worries then. thanks anyway [01:12] Noldorin: I [01:13] 'm happy to help debug though [01:13] Noldorin: If it keeps going, you might want to try again with -Dtransport [01:14] jelmer, ok i think i'll try that then [01:14] hmmm [01:14] it shows [####################/] now [01:14] does that mean it's almsot done? [01:17] jelmer, hmm? [01:18] Noldorin: it means we probably made the right decision to remove the progress bar in 2.1 ;) [01:18] spiv, hehe, fair enough [01:18] * Noldorin cancels it [01:19] Noldorin: chances are it's making progress, but I couldn't say how long it would take [01:21] spiv, yeah. so i've run it with Dtransport now [01:21] what should i check? [01:25] Noldorin: that'll add a lot of debug output to ~/.bzr.log [01:25] ok [01:25] Noldorin: so you can monitor that and hopefully get an idea of what it's doing [01:25] "hopefully" [01:25] mm [02:01] spiv, http://pastebin.com/m67c3cc57 [02:01] that's what .bzr.log gives [02:20] spiv, any ideas? [02:24] Noldorin, hi [02:24] Noldorin, this is indeed a codeplex issue [02:24] Noldorin, it's not behaving as a svn server should [02:24] hi jelmer_ [02:24] you read the pastebin eh? [02:24] hrmm [02:24] yeah [02:24] yay for MS again [02:24] any chance you can file a bug with them? [02:24] jelmer_, sure, if you tell me what to put in it :) [02:24] since i don't fully understand the source of the problem [02:25] all I can say based on that pastebin is that it doesn't actually provide all data that is requested by the client when you do a log request [02:26] If you specify the line that's being repeated in .bzr.log and your repository URL I should be able to help narrow that down [02:27] I'm off again, back later [02:27] jelmer_, ok, thanks... [02:27] i'll try to submit that tomorrow [02:27] (late here, so i'm off to bed) [02:27] night [03:51] poolie: going to fetch mary, brb [03:51] k [03:56] poolie: what version of subunit were you using when you had the problem stream on friday? [04:01] um [04:02] uhm! [04:02] hello :) [04:02] are you at lca? [04:02] hi :-) [04:02] yep [04:02] james_w: ping [04:02] lifeless: i think 0.0.4-4 [04:02] btw it has no __version__ [04:15] poolie: yeah I should add one [04:15] poolie: ok, well I still have no explanation then; its missing the xfail outcomes [04:15] poolie: and I can't trigger the fault myself so far [04:33] Now when I run bzr I always get the pre-commit hook running [04:33] I don't believe I created any myself [04:33] how do I find out which out of my ~10 plugins is missbehaving? [04:33] * xnox wants to know what's it's doing [04:34] xnox: do you mean that qwhen you commit you see 'running pre commit hooks' [04:34] yeap [04:35] and sometimes it takes a while (on big binary blob commits) [04:35] lifeless: it wasn't there before... [04:35] thats bzr telling you its at that point in the commit. It doesn't really mean anything in and of itself. Each prec ommit hook run will have its label printed out separately. [04:35] xnox: you can however get a list of the installed hooks. [04:35] uhm [04:38] oh my I do have quite a few hooks [04:38] ok in python [04:38] import bzrlib.plugins [04:39] I think I know what it is. I've enabled bzr search / index on this repo and it's activated on tip change [04:39] $bzr hooks [04:39] import bzrlib.plugin [04:39] showed me =) [04:39] bzrlib.plugin.load_plugins() [04:39] bzrlib.branch.Branch.hooks['pre_commit'] [04:39] yeah, that will too :) === abentley1 is now known as abentley [04:40] * xnox says everyone on #bzr just love to do everything with bzrlib =) [04:40] however index is post_change_branch_tip [04:41] true [04:42] then I'm clueless [04:43] cause there are no post_commit hooks installed yet it stops there for while [04:43] bzrlib.branch.Branch.hooks['pre_commit'] is just a pointer and not callable [04:43] * xnox whatever is the real name for pointers in python "object in memory"? [04:44] reference [04:45] hi all [04:45] aha! =) thank you [04:45] whats the callbacks list though? [04:45] I have to go, perhaps igc can help you :) [04:45] ciao === abentley1 is now known as abentley [04:51] lifeless: it's empty via bzrlib method also [04:51] callback=[] [04:51] =(((( [04:51] maybe another day [05:27] hi jelmer [05:30] hey James [05:30] james_w: can I upload current bzr-bd to sid? [05:30] sure [05:52] james_w: would you be ok with 2.2 as version number for that, or would you rather see a 2.2~ ? [05:59] 2.2 is fine [05:59] jelmer^ [06:00] james_w: thanks [06:01] no, thank you [06:06] james_w: Is there still a debian branch somewhere with the Maintainer: etc set properly? [06:07] there may be one on bzr.debian.org [06:07] it's probably a fair way behind if it is [07:02] hi all ! [07:03] salut [07:03] james_w: hey [07:03] hey thumper [07:05] james_w: you coming around? [07:05] yeah, I'm still writing [07:06] james_w: so is everyone here :) [07:06] you need me soon? [07:06] if you are getting more done there, feel free to finish first [07:11] thumper: we're just ordering some pizza, I'll come over post-prandially [07:12] prandially: ENOTFOUND [07:13] vila: after eating [07:14] isn't "prandially" basically a frenchism? [07:14] james_w: thanks :) I mostly deduced it from the context but my online dictionary raised the error above and I was wondering where the word was coming from.. [07:15] mwhudson: It doesn't ring any bell.... [07:16] from the latin apparently [07:16] oh, prandial, got it [07:17] mwhudson: so the English jumped over the French for this one :) [07:17] ah [07:26] hello vila, mwhudson, james_w [07:26] hey [07:26] hi poolie [07:26] hello poolie === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0b4 and 2.0.3 released [08:05] vila: hello patch pilot :) [08:05] spiv: ;) [08:06] vila: I'm about to go on leave (I'll send mail about this shortly), so you may need to take care of https://code.edge.launchpad.net/~spiv/bzr/per-file-merge-hook-491711/+merge/17279 ;) [08:06] spiv: before you left, I haven't yet look at your merge hook ... hehe good [08:07] spiv: roughly, are you confident enough to land for 2.1.0rc1 or is it something for 2.2 ? [08:07] vila: I think it may actually be ready to land now [08:07] And I think it'd be good for 2.1.0rc1 [08:07] ok [08:07] It's fairly low risk, I think. The bits that are likely to break are probably shallow. [08:08] spiv: so you can fix them in your part-time ? ;-) [08:08] e.g. maybe the news_merge plugin might accidentally cause tracebacks on some corner case, and will need to be made a little more resilient to just giving up when that case happens. [08:08] vila: right ;) [08:09] The sooner it lands, the sooner any bugs will get shaken out, of course ;) [08:09] But it would be a useful feature to land for udd [08:09] Especially if someone at the sprint can write a debian/changelog merger (see my mail to the udd list) [08:09] spiv: Yes I read that, I'll look into it asap [08:10] Having glanced at it again, I think it might actually be really easy... [08:10] I had been thinking it'd be good to do at the sprint, but maybe you'll just do it today ;) [08:10] (for someone other than me to do at the sprint, of course) [08:12] spiv: I think it's a really good target for the sprint and will spread the knowledge better. [08:12] vila: *nod* [08:12] spiv: but I'll note to land it [08:12] vila: thanks :) [08:14] james_w: hi [08:14] spiv/vila, what is? [08:14] spiv, vila: debian/changelog merger ++ [08:14] poolie: per-file-merge-hook [08:15] that sounds good [08:16] vila, thanks for being patch pilot this week [08:17] * igc dinner [08:24] * beuno waves at vila [08:24] * vila waves at beuno [08:24] * jelmer waves [08:25] beuno: you're abroad again right ? [08:25] jelmer: You're never up that early so you're definitely abroad too :) [08:25] vila: I'm in NZ :_) [08:25] mtaylor: Hopefully quite soon! :) [08:25] bingo :) [08:26] mtaylor: I already have a bzr NEWS file merger :) [08:26] spiv: yippee!!! [08:26] spiv: as someone who does a lot of merging between packaging backport branches, I will welcome this new feature [08:26] But someone else will get to write the debian/changelog one I think, I'm about to become a parent :) [08:27] vila, no, I'm startiong early so I can finish early. I'm signing the contract to move into a new apartment [08:27] spiv: congratulations! [08:27] heya jelmer [08:27] beuno: wow, *that's* early ! [08:28] beuno: Congrats for the new apartment ! I'm happy to hear that ! [08:28] mwhudson, if you're around, I'm curious about LH's performance since the latest patch [08:28] mtaylor: thanks! [08:28] hello beuno [08:28] how nice to see you [08:28] beuno: it's been ok [08:29] hey hey poolie [08:29] mwhudson, significantly more stable? or "meh"? [08:30] beuno: hard to say at this stage [08:30] beuno: perhaps a little better [08:38] spiv, I am asked to approve or disapprove of your paternity [08:38] that's kind of a big question :) [08:40] beuno: Yes, congrats! [08:41] jelmer, how's LCA? [08:41] beuno: Nice :-) Preparing our talks for tomorrow's miniconf at the moment. [08:55] spiv: so regarding per-file-merge-hook, I think you addressed jam's remarks but I'd wait for his comments/approval before landing [08:56] vila, tanks for the progress review [08:58] ta === gerard_1 is now known as gerard_ [09:01] james_w: i'm trying to use bzr-builder and failing [09:01] james_w: it would be good to fix this before tomorrow :-) === abentley1 is now known as abentley [10:21] vila: great, thanks :) [10:22] spiv: I'm reviewing right now, a couple of tweaks so far, nothing serious. [10:23] spiv: I really like your refactorings... [10:27] vila: phew :) [10:35] spiv: done. [11:09] Hello folks.. I was wondering if there was a bzr utils suite that can be used without installation on windows? [11:10] lifeeth: what do you mean by "utils suite"? [11:10] I mean just the bzr.exe [11:10] lifeeth: there are a fair few plugins available that don't need speicial installation. [11:11] Oh, hmm. [11:11] Not sure, sorry :/ [11:11] Ok.. [11:11] Need to package it with a portable app -- so was wondering if there was just one executable that can be used [11:35] Cool, there is a channel :) [11:35] Apply change? [yNfq?] [11:35] on bzr merge -i [11:35] What is the 'f' for? [11:35] Please tell me it's 'forget' [11:35] As in 'don't commit this change & then don't bug me about it again' [11:36] I have a criss-cross merge [11:37] I suggest you press '?' [11:46] maxb thanks [11:47] What does 'finish' mean then? Same as my hoped-fr 'forget'? [11:47] Or just 'stop processing more files, but process the ones already 'y''d? === Peng___ is now known as Peng_ [11:48] flavour: the latter, IIRC, but I can never remember... [11:48] So is there any way of telling Bzr to 'never hassle me about this change again'? [11:48] Any other way of cleanign a criss-cross merge other than one side dleeting & repulling afresh? [11:49] flavour: bzr revert, bzr revert --forget-merges ? [11:49] Well, I want to keep 2 LP branches in sync [11:49] flavour: never in which sense? If you do regular (non-cherrypick) merge, and resolve it and then commit it, then the next time you merge those changes will not be reconsidered. [11:49] Syncing often (coding for Haiti) [11:50] If I do a normal merge then I will lose a whole bunch of changes [11:50] Which I'll have to reapply manually [11:50] Lose in what sense? [11:50] Well, the incoming merge wants to revert a whole bunch of changes I just made [11:50] Well, you can revert those files before committing. [11:50] So I'd have to reapply the change again to each of the files [11:51] i.e. "bzr merge ../other-branch; bzr revert file1 file2; bzr commit" [11:51] Then it'll hassle me about merging again next time I think [11:51] No, it won't. [11:51] I'll try it, thanks :) [11:51] So long as "bzr st" shows a pending merge. [11:52] Then bzr will remember that you've merged in that revision (and thus all the parent revisions of that, too). [11:52] And it won't try to remerge them. [11:53] criss-crosses can make it hard to determine which changes are already merged, but even then "bzr merge --lca" tends to do a pretty good job. [11:54] question I asked on the weekend (when the channel was dead). We are doing a big code-reorganisation. Some files can be "bzr mv"ed. But there's a lot of movement of things from one file to another. No way to carry history, right? [11:56] tumbleweed: Right. [11:56] tumbleweed: right, unfortunately. [11:56] thanks [11:56] tumbleweed: If you're moving the majority of a file, it may make sense to "bzr mv" it then create a new file. (You can do that in the same revision. I think.) [11:57] yeah, unfortunatly that only goes so far [11:57] (Although someone might in the future write a fancy tool to analyze the history later and use heuristics to track code moves across files, that doesn't exist yet.) [11:57] http://paste.pocoo.org/show/166677/ [12:00] -lca made no difference to me unfortuantely...I tried it [12:00] I know clearly which files should 'win' [12:00] with only minor tweak [12:00] But a lot of files [12:00] Rest of the files reverted ok, but not this one [12:00] flavour: that "input line too long" is a weird error, I assume there's something wacky happening with your shell of environment. [12:00] s/of/or/ [12:01] Win32, so what do I expect? ;) [12:01] flavour: I expect weird voodoo that I can't diagnose for you :) [12:01] now getting it with just bzr ver [12:01] Let me cycle the shell [12:02] flavour: I'd suspect you have something that's growing an environment variable or alias every time you run 'bzr' [12:02] yeah, that fixed it [12:02] cmd window exhausted [12:33] Looks good...am going to docuemnt this for future & try it on some other branches I have probs with - many thanks! [12:53] Hi. I could use some help organizing my project. Does anyone have some time to spare? [12:55] I only have a couple of questions and it will probably not take more than 5-10 minutes. [12:58] michaelis: Someone might, but you'd have to ask your questions to find out. :P [12:59] I was thinking a private chat session but I can post my questions here. === mrevell is now known as mrevell-lunch [13:05] I, for one, don't know enough to want to talk one-on-one, but I might be able to contribute a little bit of you ask in the channel. [13:06] Peng: is correct... usually it's best to ask the group. that way different people can weigh in and help out with your problems [13:06] if you're worried about hogging the channel... don't worry, it's usually not that busy. [13:07] Besides, that's what the channel is for. [13:08] spiv: I'm not sure I understand the meaning of "That's very much for the extra review.", is it "you're asking too much" or "you reviewed a lot" ? [13:08] spiv: or yet another meaning ? ;) [13:10] I work in a municipality with water distribution/cleaning and we have many files that we would like to version control. It's everything from simple text documents, pdf's to PLC programs. Since there are many facilities and every facility has its own set of documents, every facility, according to me, is organized as a shared repository. Thereafter every specific set of directory, such as e.g.... [13:10] ...PLC programs, are organized as a shared repository beneath the previous one. Finally, every PLC program in the facility is a branch with a working tree. Could this work? [13:12] The most simple thing would be if you could checkout only part of a working tree but since this isn't possible I have to come up with something else. [13:13] * rubbs goes and gets some pen an paper. [13:13] I am too visuall of a person... I have to draw that out. [13:13] just a sec. [13:17] michaelis: what is the question? [13:17] many nested repos with branches? [13:17] yes, this will works [13:17] but what your intent? [13:17] How should I organize it in the most convenient way. [13:17] it depends [13:18] convenient for what? [13:18] michaelis: is this what you are thinking? [13:18] http://paste.ubuntu.com/358487/ [13:18] do you want to combine several branches as the complex project? [13:18] michaelis: I think that's what he means... each Facility is a project of several branches [13:18] er [13:19] bialix: ^ [13:19] Thats right. [13:19] makes sense for me, rubbs [13:19] ok, so you may be looking for the SCM plugin. [13:19] michaelis: where is your branches there? [13:19] Since I can't checkout parts of wokring tree I have to make every specific part of the facility a branch. [13:19] scmproj plugin [13:20] michaelis: that's correct. you'd have to made each part a branch. [13:20] michaelis: that's right, dvcs require you to think in the term of entire tree, not subdirectories [13:20] Another thing, I run bzr in a windows environment with the gui explorer. [13:20] michaelis: TortoiseBzr or bzr-explorer? [13:21] Bzr-explorer. [13:21] both are ok [13:21] mmm... bialix you run the scmproj right? I'm not sure how that works with guis [13:21] ah... cool [13:22] if you will want to use scmproj you need to make some operations via console or qrun dialog [13:22] rubbs: there is no GUI for scmproj yet [13:22] I myself am not afraid of running the shell version but it has to manageable by others. [13:22] michaelis: bzr-explorer has feature of open the directory with nested branches as some sort of the project [13:23] But the others will mostly checkout and commit. Can I the use scmproj? [13:23] so if you open fac1 or fac2 you should see all nested branches [13:24] if others will work only in separate branches then scmproj will be mostly transparent for you [13:25] bialix: Exactly. Now when they open fac1 they see yet another shared rep with e.g. blue prints and below that there are a set of branches for every device in that fac. [13:26] scmproj may help you to define directory structure for your branches (I calling them components in scmproj) and easily get entire project from the server for local work [13:26] also you can commit several branches at once, or push changes of the project back to the server [13:27] so only 1st step (get project for local work) is important. After that your colleges may work in separate branches [13:28] My colleges main interest is to checkout one branch at a time, make modifications to it, and then commit the changes. [13:29] There hardly will be any multibranching work going on. [13:30] if so then do you need a requirement to recreate the structure from http://paste.ubuntu.com/358487/ somewhere locally? [13:31] or you just need to select the way how to keep your branches on the server? [13:32] The structure must be on the server. How my colleges organize it locally is not my problem. [13:33] then you can keep all related branches (PLC programs, text, pdf) in the separate shared repositories with branches for each facility [13:33] is it enough for you? [13:33] Yes. [13:34] then you don't scmproj at all [13:34] don't need [13:36] But if you look in http://paste.ubuntu.com/358487/ then fac1 and PLC are shared rep according to me. PLC_prog1 and PLC_prog2 are branches. [13:37] They have to be able to checkout PLC_prog1 and PLC_prog2 seperatly. [13:38] you said you don't need this structure on the server [13:38] seperatly = separately [13:38] I obviously misunderstood you. [13:38] you don't need fac1 and fac2 [13:39] You need only PLC - shared repo, PLC_prog1 and prog2 as branches [13:39] docs -shared repo, and nested branches [13:39] and so on [13:39] remove from the picture work and fac1 [13:39] remove them as levels [13:39] and you'll see both fac1 and fac2 are the same [13:40] I misunderstood you. Since there are more than 200 fac here I need them to be represented as shared rep. [13:40] you're on the road to troubles [13:40] does your fac have something in the common? [13:40] Otherwise every branch will be called fac1 - plc_prog1, fac2 - plc_prog1 and so on. There will be more than a thousand branches in the explorer window. [13:41] They all lie in the same country... ;D [13:41] I suggest you keep fac1 as one unite branch then [13:41] michaelis: you could still do this... but nesting shared repos isn't going to help you much (I think) [13:42] That was the idea from the beginning and my question was if there was any other way than having fac1 as a shared rep. [13:42] no [13:42] fac1 should be a branch [13:42] you could do a shared repo at the PLC/docs/txt levels, but adding another at the fac level isn't going to help you much [13:43] Indeed. [13:43] you won't checkout the subdir of that branch, but that's better than thousands of branches [13:43] but if he has lots of stuff within each fac# then a big branch isn't really helpful either [13:43]