[00:04] what is the fake shell used for locking down bzr access? [00:04] i know there's a popular one [00:08] savanah use a thing called rsh [00:08] not your grandfathers rsh [00:09] there is a contrib/ script in bzr's source tree too [00:40] I seem to have an issue where the repository is lying to me about its contents. [00:40] Specifically, repository.has_revisions() is returning a revision that I'm pretty sure is not in the repository. [00:41] This is a probably a result of a bug in my plugin, but I don't know how to debug it. [00:41] well [00:41] are you accessing the repo via a stacked branch ? [00:43] No, it's a normal branch. Possibly its not correctly reflecting the repository contents however. [00:44] can you share a bit more context about what your plugin wants to do and whats going on [00:44] ? [00:46] Sure, it's a plugin for using Team Foundation Server as a foreign VCS. [00:47] I've had import working for a while and have been working on getting round-tripping viable. [00:47] So I pushed some revisions into TFS last night, pushed another one this morning. [00:48] In between there were some updates, (about 18 revisions or so) [00:48] awesome [00:48] Attempting to pull those revisions however, says "nothing to pull". [00:49] Normally I just call target_repository.has_revisions with the list of revision ids from the source repository. [00:50] But the target is telling me that it has those 'missing' revisions even though that's pretty likely to be false. [00:50] so [00:50] the target is a bzrlib native repo [00:51] the source is TFS accessed via your plugin [00:51] Correct. [00:51] the revisions you want to fetch are the new ones in TFS [00:51] Yes. [00:51] in the target [00:51] you can do [00:51] bzr cat-revision -r revid: [00:51] to quickly get at a revision from the command line [00:53] poolie: are you still caring for the kanban board? [00:55] lifeless: Hmm.... ERROR: u'revision' is not present in revision [00:55] you have a revision called revision ? [00:56] No, sorry, I ommitted the actual revision id at the end of error message. [00:56] so bzr doesn't think its there [00:56] if you open up python [00:56] and do from bzrlib import repository [00:56] target = repository.Repository.open('pathtorepo') [00:56] target.lock_read() [00:56] target.has_revisions(....) [00:57] you can see what is going on a bit more closely [00:58] I suspect that has_revisions might be giving me spurious results. I'll do some more delving and see if I can narrow down the problem a bit more. [00:59] Thanks for pointing out cat-revision, that should help with investigating. [01:06] poolie: you might like http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/ [01:15] lifeless: Heh, I typed "cat revision" earlier instead of 'cat-revision'. [01:16] So the missing revisions are in the bzr repository, but aren't reflected in the corresponding branch. [01:16] ok [01:20] So what does that mean? Has my branch history been corrupted? Has my plugin missed the fact that the branches diverged? Possibly should have caught it at the last push? [01:21] well [01:21] branches have a single tip [01:21] what is the tip revision of your bzr branch [01:24] Is there an easy way to get that from the command line/ [01:24] Branch history is different to the repository. A revision can be in the repository but not in the branch's ancestry. [01:24] bzr revision-info [01:25] or [01:25] bzr log -r -1 --show-ids [01:26] The tip's what I expect, the last revision that was pushed. [01:26] right [01:26] so you've pushed something [01:26] now [01:27] tell me what happens in TFS [01:27] if you push something [01:27] and someone else pushes stuff after [01:27] do they have to merge your thing first [01:27] or does the TFS server merge for them [01:27] or is TFS not distributed [01:27] so it actually just counts new work as new commits [01:27] TFS isn't distributed. [01:31] OK, so my working theory is that the branches diverged after push #1, push #2 should have failed as they were divergent but succeeded anyway. [01:32] push 2 probably shouldn't have succeeded [01:33] because you haven't incorporated the content of the other changes [01:33] what you probably want to happen is to have had bzr give you a diverged branches error, made the user (you) merge TFS, commit, and then push suceed [01:35] lifeless: Exactly. [01:36] still [01:36] it sounds like you've got an impressively close system there [01:38] Thanks, just waiting on legal to approve putting it on Launchpad. [01:38] \o/ [01:42] So is there a way to 'fix' my branch history? [01:42] well [01:43] this is the risk when buliding foreign interfaces :) [01:43] the revids are uuids [01:43] so their meaning is pretty hard to change [01:43] its why svn ones are hashes [01:43] (and so are git and hg ones) [01:43] Well, I know that - I was thinking I could reparent the revs to simulate a merge. [01:43] (their representation in bzr I mean) [01:44] I can think of two routes [01:44] lifeless: did you get a failure from pqm for the socketpair patch? Or should I send it myself and receive a failure directly? :) [01:44] do a manual merge - 'bzr merge -r revid..revid .' of the things that god skipped over [01:44] spiv: oh, we nuked the merge queue [01:44] about 11 [01:44] so please send [01:45] Ah, I thought I'd seen you say you'd requeue. Will send. I assume PQM is all happy now? [01:46] I was [01:46] then the u1 pqm claimed to have blown up [01:46] so I was up to 1:30 getting a handle on that and forgot [01:46] sorry [01:46] That's ok :) [01:46] jbowtie: then when you commit that merge you'd end up with what TFS has and after that it would be all ok [01:46] jbowtie: alternatively, you could nuke your repo and pull fresh from TFS [01:52] lifeless: OK, I'll try the merge first, I really want to avoid nuking the repo again if I can help it. I've done that often enough developing this thing. :) [02:14] lifeless: Thanks, the manual merge appears to have done the trick! I'll probably nuke the repository over the weekend anyway but I feel much more confident about repository integrity using my plugin. [02:54] lifeless, hi, yes i still care for and about the kanban board [03:07] poolie: I was asking because it seemed a little stale [03:12] any bit in particular? [03:25] you and spiv seem to be looking at fetch perf [03:25] not jam and I [03:25] I've hesitated to take my name off that; I have updated the pqm and loom branching stuff as it progressed [03:25] mm i don't know if single user assignment is a good match [03:26] perhaps we should have it unassigned [03:26] I think from mary's perspective yes - team accountability [03:26] also their ui fails unless you have a gravatar attached to your canonical email address [03:27] thats odd [03:27] not fails as in crashes, just fails to be very useful [03:28] yes, I got that ;) [03:28] its odd that they'd not cater for people wanting private photos ;) [03:29] mm [03:30] anyhow, I like the brevity of kanban [03:30] I was hoping it was just a little stale and not given up on [03:30] which it was/is - so thats great. [03:31] i like the brevity too [03:31] i don't love this specific ui [03:31] it seems a bit slow and klunky [03:31] I'm moving some things that appear stalled into backlog [03:32] shout if you think thats wrong, and I'll put em back [03:33] done [04:00] spiv did you manually test the socketpair thing? [04:00] I did. [04:01] does inetd use pipes or socketpairs [04:01] and more broadly [04:01] should we file a bug on launchpad-code to use socketpairs [04:01] neither, inetd directly connects the server to the socket [04:01] inetd uses neither [04:01] or less broadly [04:01] entirely unrelatedly [04:02] should we make sure launchpad-code connects its twisted daemon that is doing ssh with the subprocess bzr via a socketpair [04:02] bug 595331 classic title :) [04:02] Launchpad bug 595331 in QBzr "All button blows up (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/595331 [04:02] see the problem is [04:02] you should be pushing the Any button [04:02] Heh :) [04:02] I can't find the Any key [04:03] spiv, lifeless, you can get decent coverage of this kind of thing by running it under wine [04:03] ah, i guess it would depend on having an external ssh accessible under wine [04:03] but that should be possible [04:03] 'this kind of thing' meaning will it blow up without socketpairs on windows [04:04] Well, in this case you can temporarily hack in "import socket; del socketpair" too [04:04] er, "del socket.socketpair" [04:05] (And we already have the BZR_SSH variable for exercising the paramiko code path, which was also changed) [04:06] I find it interesting [04:06] that all of (me, jam, poolie) have immediately assumed there are going to be issues validating/working on windows ;) [04:06] and that spiv seems to have taken them all into consideration [04:06] :) [04:06] mm [04:07] i was commenting more in response to john's review [04:07] i don't anticipate there being platforms that have the python module but not the feature [04:07] though it probably can happen [04:07] sure [04:07] you may have missed it [04:07] but I grilled spiv about windows last night [04:08] with a similar sort of angle to the questions [04:08] for all that they were different [04:08] I'm not offering any conclusion, I just found this an interesting thing [04:09] Well, it's a good habit to ask "what about Windows", because we don't get as much automatic testing there. [04:10] anyhow [04:10] winepython++ [04:10] if in doubt just run it [04:10] (I mean both because PQM doesn't test windows, and because fewer bzr devs run bzr on windows day-to-day) [04:10] you may not be able to easily/quickly run the whole suite but you can fairly easily run one module of tests [04:10] i often do that [04:10] Good idea, thanks for the reminder :) [04:12] wine is amazingly good these days [04:12] mm pinot [04:15] did you see the http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/ link ? [06:18] lifeless, i did, and that makes sense [06:19] one thing i would add is that tests can become write-once [06:19] ie they're there, they pass, you don't want to break them but you also may not often actually improve them [06:20] i don't think shell-like tests are the ultimate but that patch definitely made the tests cleoaner [06:20] i'd like to work out how to test tribunal [06:20] what kind of tests would be most useful [06:52] lifeless: ping [06:58] hi parthm [06:58] parthm: hi [06:58] hi poolie, lifeless [06:58] poolie: tests that catch bugs ;) [06:59] lifeless: in the context of jams test (https://code.launchpad.net/~parthm/bzr/250451-better-url-for-break-lock/+merge/27187) i was wondering if 10 or 30 s timeout sounds ok to you [07:00] thats the only thing pending on that patch now before i can put it for review [07:00] lifeless, mm i might wait until i have an idea of typical bugs and then see what to do [07:01] at the moment most of them are lack of understanding of how something will interact with gtk [07:03] hi all [07:05] vila: hi [07:12] parthm: I'm easy either way [07:12] parthm: we can always change our mind later [07:13] lifeless: sounds fine. I will put it for review with the current value of 30s. thanks. [07:14] is thr any software which could show differennt revisions side by side. something like meld. [07:19] assad: you can use meld [07:19] assad: well, you could always use meld :) But there's also 'bzr qdiff' (from the qbzr plugin), for instance. [07:20] hi vila [07:22] assad: also, bzr diff --using=meld ... you can set up an alias if you use it frequently. [07:23] ok thank you guys [07:30] lifeless, did my 'gnuness' branch bounce? [07:30] poolie: hmm, I forgot that one, no probably it get killed when pqm was wipped [07:31] s/no/no,/ [07:31] poolie: when did you submit it [07:31] you did, 20 hours ago [07:31] ok [07:31] no, it got zapped [07:31] lifeless: pretty sure it was just after I submitted the broken one that got cancelled === radoe_ is now known as radoe [07:32] cleared out the stuff I'd submitted when the base64 thing was noticed [07:32] there was some confusion about who was resubmitting [07:32] That is, I was confused, noone else stood a chance ;) [07:33] vila: oh hai [07:33] vila: my loom support branch [07:33] ok, re-sent [07:33] vila: please check the most recent commit on it; minor stuff [07:34] lifeless: on bzr ? loom ? both ? [07:34] oh, as soon as I push it [07:34] bzr/loomsupport [07:34] has an open, approved mp [07:34] I want to land a little bit more. [07:34] ok, should be there now [07:35] vila: rev 5299 [07:35] vila: loom trunk has its stuff already [07:35] lifeless: updating diff [07:36] vila: just diff -c lp:~lifeless/bzr/loomsupport ;) [07:36] vila: I'm asking for incremental [07:37] lifeless: updating, ooooh upstream up to thread.... Thanks abentley !! [07:38] lifeless: byt the way, you mentioned several times something about.... noisy merges in a loom, my leaking-tests loom has lots of those, can you explain a bit more what you have in mind and does it apply there ? [07:38] s/upstream/up-thread/ silly typo [07:40] vila: I'm rather tired after last night [07:40] vila: my tomorrow first thing I'd be delighted to discuss it more [07:41] lifeless: ok, no problem, I wanted to ask for some time but keep missing the right window [07:48] vila: so, the loomsupport change is ok ? [07:48] lifeless: yup, except for the NEWS entry order [07:48] vila: whats wrong with the NEWS entry order? [07:49] 'branch' < 'knit' [07:49] no ? [07:49] oh [07:49] I was asking for the incremental change to be reviewed [07:49] not the entire branch [07:49] I will fix that [07:50] but it would have saved you some time :) [07:50] the incremental change seemed obscure at first glance s//from_/ :) [07:50] ok [07:50] I wonder if diff -c should show the commit message too [07:55] webnumbr.com is really cute [07:55] lifeless: maybe, but maybe fixing the tests so that calling make_from_branch_and_tree wasn't necessary (dunno if this makes sense anyway) would have resulted in an easier to read change, as long as it works, I don't care that much [07:56] spiv: nice! the big G had something similar but the sources were (much) more constrained [07:56] vila: i think being able to do default format stuff is good too [07:57] lifeless: sounds perfectly reasonable [07:57] The interface for creating a graph is quite neat, and the API is pretty cute too. [07:57] rrd graph would be good as well [07:57] but it is a good api [07:58] lifeless: I was speaking as a lazy reviewer not as a pedantic tester :-) [07:59] suggestion submitted [07:59] * mlh goes back to work [08:07] spiv: hmmm, open bugs in bzr, boom. [08:07] as in , should be trivial [08:09] though [08:09] hah [08:09] the ajax d-feats it [08:09] parthm: you didn't pushed your latest changes, but my last vote was tweak anyway, so please land [08:12] vila: the diff shows the latest. anything missing? [08:12] lifeless: yeah, you have to be cunning :/ [08:12] I've filed a ticket [08:12] vila: i will land it. thanks for the review. [08:12] lifeless: [08:12] http://webnumbr.com/bzr-in-progress-bugs [08:14] Heh, the "average" function in the API appears broken... it sums N data points ok, but they seem to have forgotten the "divide by N" step. [08:15] parthm: weird, sorry for the noise, I didn't see the push in the mp comments and didn't check the diff itself [08:15] parthm: well, I meant, I *still* don't see the push in mp comments :) [08:16] spiv: growth ! growth ! That's the only important thing ! [08:17] vila: yes. it i don't see it inline either. its 5293 'cleaner handling of lock_url display.' ... maybe a bug due to needs review -> wip -> needs-review transition. [08:17] parthm: no worries [08:18] vila: or maybe a feature for wip :) [08:19] parthm: features like that are bugs :) [08:19] parthm: can file one against lp-code ? [08:19] * vila insert 'you' above [08:19] vila: will do. [08:19] hmm, almost aligned ;) [08:33] vila: bug #595392 .. feel free to add to it in case i have missed out something. [08:34] Launchpad bug 595392 in Launchpad Bazaar Integration "commit not seen inline during needs-review->wip->needs-review transition (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/595392 [08:35] parthm: perfectly clear :) === assad is now known as assad|lunch [09:18] poolie, could you please take a look at bug 367545 again. [09:18] Launchpad bug 367545 in Bazaar "Huge memory usage for bzr branch/checkout (affected: 5, heat: 21)" [High,Confirmed] https://launchpad.net/bugs/367545 [09:43] heya bzr [09:43] bonjour vila [09:45] bialix: privet Sacha :) [09:46] :-) [09:46] vila: I'm about to tweak right now [09:46] my I beg you to land that patch then? [09:46] s/my/may/ [09:47] bialix: sure, push your changes and ping me [09:47] ok [09:48] bialix: I wasn't sure you had a working pqm setup [09:48] vila: I don't have one [09:48] and poolie latest patch infers I should use Hydrazine [09:48] I'm afraid of this beast [09:51] anyone seeing crazy memory usage during a pack operation? [09:52] Right now, it's looking like 17.5x-20x the file size when repacking texts. :-( [09:52] jszakmeister: crazy is too subjective :-/ [09:52] size of which file ? The biggest pack ? [09:53] I'm re-creating a problem that we saw with another repo... [09:53] I'm using a single file, file.bin, and completely changing it's contents every commit... [09:53] and it has 100m of binary data in it. [09:54] It *seems* to be relative to the size of that file. [09:54] AFAIK repack shouldn't consume insane amount of memory anyway, commit is still about ~x3 IIRC [09:55] Yeah, that's what I thought too... but it's definitely real high when repacking texts. :-( [09:55] jszakmeister: so what is the peak memory ? 2GB ? [09:56] Yeah, depending on when the process gets sampled, I see anywhere from 1.75 to 2.0GB. [09:56] I know jam has some way to track this but I don't remember if there is an env variable for that [09:56] checking with him later in the day seems the best option [09:57] For a 100MB file. I'm going to try this with a larger one and see how it changes, but I'm pretty sure it'll grow. [09:57] vila: ping-ping, ring a bell :-) code tweaked, bzr.dev merged, news conflicts resolved, pushed to lp. ready to land! [09:57] vila: For max memory consumption you mean? [09:57] That'd be helpful if he does! [09:59] bialix: sent to pqm [09:59] :-)- [09:59] jszakmeister: yes [09:59] jszakmeister: and even a plugin (meliae) to investigate [10:03] Neat. BTW, that figure was the "real memory" used. I think the actual VM size is larger. [10:04] vila: commit message slightly out-of-date, sorry, I forgot about it [10:06] bialix: ? Show unicode filenames in diff headers using terminal encoding sounds fine to me [10:08] no more "on Windows-only" [10:12] ha, rats, well the NEWS entry is correct, that's the most important [10:15] okay [10:26] * bialix bbl [10:56] Hi there [10:56] when setting up a shared repository with bzr, I put a 02770 right on the top folder [10:57] now when users add directories, they have the right group, but they don't inherit the "g+w" bit, so other members of the group don't have write access to the contents of this new directory [10:57] is there a way to do this? [10:58] What do you mean by 'add directories'? As in push in new branches? [10:58] yes [10:58] or just add a directory inside a branch [10:59] Yeah, I'm pretty sure bzr doesn't have any builtin support for inheriting permissions like that. [10:59] well I think this has to be done using unix permissions [10:59] It does for stuff under .bzr/, but new bzrdirs, not so much. [10:59] CVS seems to force the permission inheritance when adding a directory with "cvs add" [11:01] In the working tree? I'm pretty sure it doesn't... [11:02] well I just tried [11:03] I have a repository in /cvsroot/test [11:03] when I do a "mkdir /cvsroot/test/toto" , it gets drwxr-sr-x [11:03] but if I do it with cvs add [11:04] it gets drwxrwsrwx [11:04] That's in the repository, not the WT. [11:04] well CVS add works directly in the repository, for sure [11:04] bzr inherits inside the repo (though there's no mirror of the tree structure in the repo layout in non-antique formats of course) [11:04] my point is that when I do a CVS add, it seems to not only do a mkdir on the repository, but force the inheritance of the parent dir [11:05] when you say inside the repo, you mean locally? [11:05] Wherever a repo is touched. [11:05] say, in bzr, I do a branch of my repo [11:05] * fullermd thinks we're talking past each other... [11:06] I do a bzr add on a directory [11:06] and I commit it [11:06] then I push it back to the parent branch [11:06] I won't get the same result I can get with CVS, which is that this repository will have g+w so the other members of the group can commit to it [11:06] It will if the repo has perms right. bzr WILL inherit those perms on new pack files etc. [11:07] At one time I knew exactly which dir it grabbed from. But I don't bother remembering, I just `find .bzr -type d -print | xargs chmod g+w` or its immoral equivalent. [11:08] you mean you have a hook on the server to do that? [11:08] No, I mean I do that manually when I setup the repo in the first place. bzr preserves the g+w on new files it makes in the repo. [11:09] ok [11:09] let me see [11:11] thank you for your help already fullermd [11:14] hmm I just tried again [11:15] the whole repo is g+w and g+s [11:15] it's a shared repository [11:15] I'm pushing back my branch [11:15] which ends up in $reporoot/branches/mynewbranch [11:16] and it doesn't inherit g+w [11:17] Paste a ll of the file? [11:17] drwxr-sr-x 3 rpinson scm_spp 4,0K 2010-06-17 12:14 testraphink [11:17] and the parent dir is [11:17] drwxrwsr-x 166 rchalumeau scm_spp 12K 2010-06-17 12:14 /cvsroot/spp/sppcpp/.bzrroot/branches/ [11:18] OK, so we're talking past each other. [11:19] what do you mean? [11:19] bzr preserves perms on files inside the repo, like [...]/.bzr/repository/packs/* [11:19] You're talking about perms on a [new] branch, which don't inherit. [11:19] yes [11:19] so new branches cannot be shared? [11:19] bzr doesn't touch those at all; it's all determined by the system via umask etc. [11:20] ok [11:20] but if I add a dir in an existing branch, then it will work [11:20] Yes, those are all internal objects in the revision, which get stored in packs in the repo, which bzr DOES set perms on. [11:21] alright [11:21] For instance, if instead of pushing a new branch, you'd pushed your changes onto the existing branch. [11:21] so then we have to setup shared branches with g+w and use these for merges [11:21] for the group [11:21] other created branches will remain with individual rights, while these can be used for group purposes, right? [11:22] Generally, branches fall into one of two categories: (1) long-lived shared branches, and (2) short-lived individual branches. And those perms aren't a problem for either, since in the first place you'd just blat a g+w over them manually once and forget it. [11:22] It's only with relatively transient branches that you still want multiple people writing on that you get into trouble. [11:23] You could try fiddling with things so that when bzr is invoked (I'm assuming you're all going over bzr+ssh) it sets the umask to allow group writes. [11:23] Though that's a little dangerous on GP, and wouldn't be suitable if that weren't the only config being used on the box of course. [11:23] thanks for the clarification [11:24] I'm afraid the categories for the devs are not that clear ;-) [11:24] You could setup a cron job to just g+w all the branches under a given dir Every So Often(tm). [11:24] ;) [11:25] bzrtools has a 'branches' command, so you could `cd /where/ever && bzr branches | xargs chmod -R g+W` [11:25] Or just forget about subtlety and g+w the entire dir tree under the repo point. [11:26] hi there [11:26] fullermd: rom1 is the dev having this issue [11:26] :) [11:26] I was just proxyfying the conversation [11:27]