[01:04] vila: ping [01:06] lifeless: zzz pong zzz [01:06] vila: your patch is wrong :) [01:06] vila: because it decodes a fs output which may not be utf8 [01:07] vila: which is why we should fix tree.get_symlink_target [01:08] lifeless: isn't tree a revision tree here ?? [01:08] no === VSpike_ is now known as VSpike [01:16] yay [01:16] after more than a year, I finally have a current copy of samba in bzr again [01:21] cool [02:19] spiv: are we getting together? [02:45] lifeless: not today, I'd be keen to pair tomorrow though. [02:45] * spiv is off to lunch === ja1 is now known as jam [03:07] when running a hook I don't suppose the current revno gets put into the environment somewhere? [03:09] johnf: a shell hook or python hook? [03:09] the former I dunno, the latter - its available via the api [03:09] lifeless: shell [03:10] yeah I just ran env as a hook and there is nothing there [03:11] might have to do something evil with builddeb pre-export and pre-build hooks using a temporary file [03:11] are they not python hooks? [03:11] Basically I want access to the revno inside the build dir [03:12] probably [03:12] Are they fired by builddeb itself? [03:12] let me see [03:12] if they are fired by builddeb, use the bzr Hook infrastructure instead [03:13] change the shell hooks to be hooks in that infrastructure, then you can write your hooks in pythn [03:13] builddeb has a run_hook method which uses popen so I'm guessing they don't use the hook infrastructure [03:33] is it possible that I lost content if I had files in mworking dir when I typed 'bzr rebase' ? [03:33] they seem to be gone [03:33] which makes me a bit unhappy [03:36] what is the way to create a new branch in format say 1.9 format using bzrlib? [03:40] thumper: look at builtins.py, cmd_init === TheMuso_ is now known as TheMuso [03:43] any chance that my content that looks lost is really stored somewhere else? [03:44] how do I list branches? [03:44] pjz: bzr branches [optional url] [03:45] pjz: you may have shelved it [03:45] pjz: or it could be a dead head (bzr heads --dead) [03:46] lifeless: ah! bzr heads --dead found it! now... how do I bring it back? [03:48] pjz: you can pull it or merge it, using -r revid:REVISIONID [03:54] lifeless: how can I change the parent branch of a checkout? [03:54] lifeless: b/c the repo it's in has a bogus parent branch set, so trying to pull -r it tries to pull that bogus parent branch and fails [03:56] pjz: bzr unbind [03:56] pjz: or bzr switch [03:56] unbind stops it being a checkout, but if the parent is deleted you can get around that [03:56] oh [03:56] pjz: "bzr pull . -r revid:REVID" [03:59] lifeless: ah! thanks muchly! [04:00] lifeless: is there a doc that describes how to use branches of a project on launchpad correctly? Like I registered and created a branch to push to, but got into trouble not knowing how to rebase up once the upstream branch advanced some [04:00] pjz: why would you rebase? [04:00] pjz: with bzr people generally just merge from trunk [04:00] lifeless: uh... how else do I movemy work to top of tree? [04:01] lifeless: ah, okay [04:01] rebase seems to be a very git thing [04:01] most other vcs's don't need it anywhere near as much [04:02] well, they do it differently [04:02] everytime you do an 'update' in svn or cvs, that's really a rebase of your working tree onto the trunk [04:03] pjz: you can do 'bzr update' too, when you have a checkout of trunk [04:03] that pivots your work into a pending merge on the old tip of trunk [04:04] lifeless: okay, so anyway, is there a 'usual-workflow' doc of bzr & launchpad somewhere? [04:04] lifeless: so what should my initial checkout be of? my branch? or the trunk? [04:04] I don't think there is; there are ones for bzr [04:04] and launchpad just expects any normal use of bzr [04:04] lifeless: ah, okay. is there a good bzr workflow doc somewhere then? [04:04] doc.bazaar-vcs.org has the users guide, reference manual etc [04:05] in short though, its usually [04:05] bzr branch trunk myfeature [04:05] hack and commit in myfeature [04:05] Ehh, is it possible to set "log --levels N" for all commands that show logs, not just "log"? [04:05] if trunk changes, cd myfeature, bzr merge $trunk; bzr commit -m 'merge trunk' [04:05] when the feature is done, [04:05] cd trunk; bzr merge $myfeature; bzr commit -m 'myfeature is finished' [04:06] pjz: both cvs and svn can do merges as well as updates btw :) [04:06] lifeless: oh, so I have to keep a trunk tree and a branch tree both around? [04:06] pjz: either that or use bzr switch to move a checkout between branches [04:07] with a checkout its [04:07] bzr branch trunk myfeature; cd $checkout; bzr switch myfeature; hack commit etc; bzr switch trunk; bzr merge myfeature && bzr commit -m 'feature done' [04:08] pjz: if its a small project, just have a couple of trees, if its big like emacs/python etc, you'll want a shared repo setup (bzr init-repo /src/repo --no-trees), which means that making new branches will not setup working trees [04:08] pjz: and then you'd use switch [04:09] pjz: this is a bit of a wart on our UI, and we're discussing at the moment how to fix this while still keeping the things we love (that branches have real url's mainly) [04:10] pjz: does this make sense? [04:11] lifeless: mrm, yeah, somewhat [04:14] ?!? Ignoring request for a stacked branch as repository already exists at the destination location. [04:14] it lies [04:14] I supplied --stacked-on [04:16] thumper: you're pushing somewhere that has a repo already [04:16] lifeless: no I'm not [04:16] lifeless: I'm pushing to launchpad [04:16] thumper: no chance that you had a partial push already at that url with a repo and no branch? [04:17] none at all [04:17] the branch didn't exist before [04:17] then file a bug [04:17] lifeless: so you still haven't told me how to set the parent branch of a checkout [04:18] lifeless: what does walking content mean when inserting stream? [04:18] pjz: pull --remember [04:18] thumper: its a progess message from the guts [04:18] lifeless: handy [04:20] lifeless: thanks muchly [04:21] lifeless: for all the help [04:21] pjz: my pleasure [04:21] lifeless: and I think things will be nicer when you can address branches in the same repo [04:21] lifeless: which should be fairly easy - just pick some separator char or path or something [04:22] lifeless: so file://foo/bar/baz/.bzr/onebranch means 'in repo file://foo/bar/baz, branch onebranch' [04:22] lifeless: b/c the real cool thing about URLs is that they can be virtual :) [04:23] pjz: so, you can already, 'bzr switch' for instances knows to lookup relative to the current branch [04:23] pjz: but yes we need to do something to make this better [04:24] lifeless: also once you get this you should be able to do things like add /parent and /push subpaths to the branch to make them addressable [04:24] lifeless: er, to the branch URI [04:24] pjz: what do you mean? [04:26] lifeless: well so if I have a branch 'feature1' from a trunk 'trunk', and 'feature1' has a subbranch called 'bugfix1', I could maybe merge it all the way to the trunk by just doing a merge with feature1/parent instead of having to remember trunk's URL [04:26] so at the moment [04:26] if I have three branches [04:27] /trunk, /feature1, /bugfix1 [04:27] and a checkout of bugfix1 [04:27] I can do [04:27] 'bzr switch trunk' [04:27] to go direct to trunk without remembering the url [04:28] repositories are just storage to bzr, we don't need to make them more than that to get nicer paths [04:28] what it needs though is the core performance stuff we're working on for 2.0 finished [04:28] then I and others can spend some serious time on UI [04:29] lifeless: how do you list what branches are in a repo? [04:29] bzr branches [04:29] which looks at . [04:29] unless you give it a url [04:29] lifeless: wow, I get a blank line when I run that [04:29] lifeless: so I have no branches? [04:29] or one with an empty name? [04:29] one with an empty name I'd say [04:30] as it defaults to looking in . :) [04:31] lifeless: so I've got a branch named '', a parent branch of http://trunk and a push-branch of lp:mybranch [04:32] lifeless: aaand a submit-branch of the old absolute path to ., that changed when I renamed what .. calls . [04:35] any way I can update the submit path? [04:36] er, submit branch [04:36] bzr submit branch-to-submit-against --remember [04:36] erm [04:36] s/submit/send [05:09] lifeless: any way to do it without actually doing a send? [05:10] pjz: you can edit the config setting directly [05:11] its the submit_branch setting (and see bzr help configuration for details on the configuration stuf) [06:08] wow [06:08] bzr just caused me a lot of data loss [06:08] orly? [06:09] I was trying to get bzr to recognize that I had moved some directories around [06:09] as I had moved a ton of directories in the cwd into a new, unversioned directory called desktop-guide [06:09] I did bzr --after libs/ desktop-guide/ [06:09] and then when I went to try to move something else into desktop-guide, it told me desktop-guide was already versioned [06:10] so I did bzr status and saw that bzr had moved libs to desktop-guide [06:10] not desktop-guide/libs/ [06:10] so I did bzr revert libs/ to undo that [06:10] and so bzr deleted desktop-guide and brought back libs [06:10] not quite what I wanted at all [06:10] that is what you asked it to do [06:10] bzr revert is not 'undo the last command' [06:11] its 'put things back to the way they were in the last commit' [06:11] Right [06:11] I thought it would bring back libs/ [06:11] not delete desktop-guide [06:11] I understand why it did [06:12] it should ahve created backup files [06:12] and they are probably in libs [06:13] oh weird [06:13] Its like it merged the two directories together [06:44] night all [07:22] hi all [07:23] When will bzr work with python2.6? [07:24] hi, what's going on with bzr lately (considering both gnome and python 'missed' it)? [07:26] nvm [07:26] I had hardy ppa enabled and not jaunty [07:26] gour, to answer your question, I heard they were working on a revolutionary new storage engine or something that is super fast and takes up very little disk space [07:28] cody-somerville: i must say that i played a lot with bzr (after moving from darcs), but have tendency to go back seeing (too) many format options in bzr not being able to settle on something :-( [07:28] gour, why? It doesn't really affect you or me. [07:29] cody-somerville: That'd be brisbane-core, which, if I understand it correctly, will allow the devs to fix all the bugs I care about, and implement (almost) all the features I care about. [07:30] indeed [07:30] cody-somerville: well, it does not impress one - storage format is one of the important issues for VCS [07:31] cody-somerville: and in the meantime most major players will migrate....and it will be extremely difficult to get 'em back [07:32] gour, Right and bazaar is continuing to innovate in that area providing you and me with improved performance and more features transparently [07:37] To a certain extent, as long as bzr-git works, I don't much care. [07:38] So what features are you interested in RAOF? [07:42] So, I'd like, in no particular order: push to not push a minimum of 1Mb of data, at a rate < 10K/sec (roundtripping to .uk!). 'bzr externals' type support. Pull to nearly saturate downstream bandwith (less roundtrippin' to UK!) [07:42] Some other random stuff that I can't remember right now, too. [08:12] RAOF: What version of bzr do you run? There were push & pull improvements in 1.12 or 1.13. [08:12] (or both?) [08:24] Peng_: 1.13; Jaunty default. [08:26] hi vila [08:27] vila: I'm seeing 2 test failures running 'bzr selftest groupcompress' in brisbane-core [08:27] vila: do you know if anyone is working on fixing those? [08:28] igc: there is a python version of gc that should land soon, what failures are you seeing ? [08:28] test_insert_record_stream_existing_keys [08:29] igc: by the way, I just fixed 3 more failures in test_commit_with_revision_id_record_iter_changes [08:29] once for groupcompress and once for groupcompress-graph [08:30] ha yes, those ones, no, nobody is on it yet AFAIK [09:00] I'm following http://bazaar-vcs.org/BazaarForWebDevs [09:00] this line does not work python setup.py build_ext -i [09:00] there is not setup file created when you get the branch bzr branch https://launchpad.net/bzr-push-and-update bzr_push_and_update [09:02] enquest: forget it, that's a typo, this is not needed [09:03] maybe somebody wants to change it http://bazaar-vcs.org/BazaarForWebDevs [09:04] thxs [09:05] enquest: hit refresh :) [09:05] :) [09:05] and the command should really be: bzr branch https://launchpad.net/bzr-push-and-update push_and_update [09:05] note: no leading 'bzr_' for the plugin directory name === thekorn_ is now known as thekorn [09:46] yo [09:46] is there any command that will tell me what history i'll get if i pull/merge with a remote? [09:47] What you will get? [09:47] the 'missing' command might be what you're after [09:47] type 'bzr help missing' and take a look at the usage [09:50] igc: ping [09:50] hi vila [09:51] hmm [09:51] vila: I've got to run sorry - dinner [09:51] bbl [09:51] igc: there is a thred in bazaar@lists.canonical.com about these failures: VF.insert_record_stream() with duplicates in stream [09:52] igc: so jam is indeed aware of the problem and already working on possible solutions, sorry I didn't make the link sooner [09:52] oh dammit [09:52] it doent tell me about all changes, but only the last merge [09:52] ronny: bzr missing [09:53] vila: yes, exactly that one ... [09:53] only shoes the latest merge in the remote, not all of the changes [09:54] ronny: hmm, bzr version ? [09:54] 1.13.1 [09:56] by alll the changes you mean merged revisions ? [09:56] i want to see all revs [09:56] not just merges [09:58] bzr pull -v should still show all merged revisions :-/ igc is working on log and changed some defaults, you may be seeing a side-effect here [09:58] ronny: if you got the the revision range you're interested into (from missing) you can still do: [09:59] bzr log -r --levels 0 [10:19] ronny: bzr missing --include-merges [10:26] lifeless: the description of that in the help is DAMN confusing and missleading [10:26] "--include-merges Show merged revisions." - my first tought about that was "hu? it shows the merges already" [10:28] That sounds like mtn-thinking carryover. [10:30] ronny: how would you make the distinction between the merging revision and the merged revisions ? === thekorn_ is now known as thekorn [10:34] ronny: is 'Show all revisions in addition to the mainline ones.' clearer ? [11:11] vila: yes, that would be very good [11:11] fullermd: well, mtn was my first dvcs [11:11] (and the first vcs i could actually use nicely, cause svn is a clusterfuck) [11:15] I'm not saying it's bad, just that mtn --no-merges and bzr --include-merges talk about completely different things... [11:15] Emergent both, kinda. [11:36] owd [11:38] Here is a question that might be a bit more general than just Bazaar. But I'm wondering: in a central environment (company) it sounds strange that DVCS can't manage multiple branches that belong to the same project and make sure that a developer never can delete history: pushes always seem to be just mere file system accesses so I as a developer can also just go ahead and delete that branch and any history of it. [11:38] Is there a practice in Bazaar to avoid this? [11:39] I'm also suspicious that LP does part of that job, but that's a no-go as it's not open source. [11:41] what? never throw branches that didn't work out?? [11:42] if you have to worry about that happening, I think you need to pay your people more ;-P [11:45] hi [11:45] Theuni1: You can totally nuke stuff on Launchpad. [11:45] so I do bzr pull, and it downlads a new revision. without messing with the revno, how to do a bzr diff between the last revision and current one? [11:46] bzr diff -1.. or something like that? [11:46] Theuni1: It sounds like you're worrying about intentional deletes from, say, an audit perspective; rather than accidental ones during normal workflow [11:46] Edulix: bzr di -c -1? [11:46] Edulix: That shows what changes were introduced by revision -1 (aka the most recent revision). [11:48] Peng_: thanks [11:48] Theuni1: ask on the list [11:57] Theuni1: you can always deny developers direct write access to the central branches, and make them go via a gatekeeper tool like PQM (https://launchpad.net/pqm). That's probably overkill, and with DVCS it will always be possible for a dev to make a non-central branch that you don't even know exists. [12:46] Hey, is there something like svn:externals for bzr? [12:46] njpatel: not yet [12:46] well, there is, but not production quality [12:47] hopefully in a month or two that will change as Aaron is working on it [12:47] james_w: hey! I thought as much :) [12:47] cool, it would be pretty useful [12:47] igc: back ? === thekorn_ is now known as thekorn [12:54] lifeless: fresh comment on http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html btw [12:55] vila: hi [12:55] igc: groupcompress has evolved quite a bit with the introduction of the python implementation, I'm about to push it to bcc [12:57] bbc even [12:57] vila: can you merge my code cleanups easily? [12:57] I don't think so [12:58] igc: let me try [12:58] vila: thank-you [12:59] igc: :-/ conflicts all over the place as I fear [13:00] The main part you modified has been split into implementation specific classes and some of your points were already addressed, the conflicts are a total mess [13:03] vila: it shouldn't be too hard, though messy, to apply the changes by hand [13:03] vila: most of them are assert -> AssertionError [13:04] and some variable renaming & docstring corrections [13:04] I'm about to start again on the assertions [13:05] vila: I guess I can apply them tomorrow by hand [13:05] but I'd appreciate any you knock off tonight [13:06] igc: I think it ill be eaiser for you to see what still applies tommorow, I'll try to see what I can do until then [13:07] vila:np [13:08] spiv: pqm seems to be overkill indeed, as handling *many* small projects with it seems to have too much overhead. [13:08] bob2: I probably will. [13:09] spiv: Actually I kinda also worry about accidental deletes. Not so much toolwise (although bzr push did at some point screw up branches on LP having to delete them) but more from the perspektive that e.g. in Subversion creating or deleting a branch is a managed operation under SCM perspective. [13:09] Which allows me to get notified when new branches get created destroyed. One of the purposes of DVCS obviously is not having to do that, but I think it might be a worthwhile scenario to support if wanted. [13:10] Theuni1: if you require that all access is via a smart server, you could do that. [13:10] spiv: interesting. that was one of the answers i hoped for. i find the documentation of the smart server a bit lacking. ;) [13:10] I'll digg deeper into the smart server then. [13:11] Theuni1: well, except that there's no way to delete branches via the smart server yet (or with the "bzr" command in general) [13:11] I'm fine with that for now. :) [13:11] Theuni1: but if/when the command does, the smart server should export a hook point you can use to find out about [13:11] Can the smart server export multiple branches of multiple shared repositories? [13:11] The basic tool you probably want is the "post_change_branch_tip" hook. [13:12] Yes, it just serves a filesystem. [13:12] Even more interesting. [13:12] I wonder whether I'm blind or the docs are evading me. [13:12] (Or a bzr transport, in fact, you could write your own virtual fs...) [13:12] I'm happy not to write too much tool-stuff myself. ;) [13:13] Some caveats: the smart server still allows arbitrary file-level operations that won't trigger any hooks, so someone could still delete stuff and what have you by scripting with bzrlib. [13:13] I didn't quite get the ending of that sentence. [13:13] (Although we're getting closer to being able to turn that off; most of the operations are now done through higher-level network RPCs rather than file RPCs) [13:14] spiv: Exactly those higher-level RPCs is what I'm looking for. [13:14] Well, you don't really want to be dealing with RPCs, you want to use the hooks. [13:14] post_change_branch_tip is the one you want. [13:14] Right. [13:14] But you need to make your own abstraction over the file RPCs to achieve that ;) [13:14] Also, you want to set append_revisions_only in your branches' branch.conf probably [13:15] The caveat about the file RPCs is just to say that it isn't watertight yet. [13:15] It will be. [13:15] Would the smart server be able to enforce that for all branches it handles? [13:15] * spiv -> gone [13:15] spiv: thanks a lot! [13:15] Even if there's stuff in the future, I'm happy to hear about the direction you're going.\ [13:15] I'll look into the smart server. === abentley1 is now known as abentley === thekorn_ is now known as thekorn === jelmer is now known as Guest67595 === Guest67595 is now known as jelmer [14:33] moin === ja1 is now known as jam [14:55] hi guys, I'm having a problem when pushing the code of my project [14:55] i got this error [14:55] bzr launchpad-login chaos.proton [14:55] bzr: ERROR: Connection error: curl connection error (SSL certificate problem, verify that the CA cert is OK. Details: [14:55] error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed) [14:55] on https://launchpad.net/%7Echaos.proton/%2Bsshkeys [14:55] any help ? [14:56] it looks like you need to make curl aware of the CA certificate [14:56] ivangarcia: try installing ca-certificates > [14:58] hmm, I have slackware, is there a package for it? [15:04] ivangarcia: I don't know, but then you'd better search what ssl implementation curl is using and whether or not there is such a thing as CA certificates installed system wide [15:05] thks vila [15:05] ivangarcia: if you don't care about certificate validation, you can also just use the urllib based http implementation instead of the pycurl one [15:11] ivangarcia: if you find the certificates but can't make curl/pycurl find them, you may want to look into bzrlib/transport/http/ca_bundle.py which gives some hints (mostly used on windows, but should apply in your case too) [15:12] ivangarcia: roughly, you make the env variable CURL_CA_BUNDLE points to the appropriate ca-bundle.crt file (*finding* that file is left as an exercise ;-) [15:23] vila: did you spend time working on resolving Ian's cleanup patch? Or should I go ahead and do that? [15:24] jam: I'm doing it as I replace the assertions, go fix InterDiffering ;-) [15:26] vila: Submitted a fix for 256612 >-) [15:26] bug 256612 I mean [15:26] Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612 [15:31] jelmer: will look into it [15:38] vila: thanks [15:38] vila: do you have a quick list of the test that is failing because of "inter-differing"? [15:38] I think I have a fix, and just don't want to wait for everything to finish [15:41] jam: -s bt.per_repository.test_fetch.TestFetchSameRepository.test_fetch_to_knit3 (for the 2 errors) [15:42] jam: -s test_fetch.Test1To2Fetch.test_two_fetch_changed_root -s test_fetch.TestFetch.test_fetch_incompatible (for the 2 failures) [15:57] vila: the "test_fetch_to_knit3" has been fixed, I'll work on the other [15:57] jam: yeah :) [16:09] igc: are you at PyCon? [16:14] jelmer: no [16:20] vila: the other two tests now pass [16:20] So I've fixed the 4 cases above [16:20] any others? [16:21] jelmer: Brisbane and about to go to sleep :-) [16:22] igc: it is what, 5am there? [16:22] ah, I guess only 1:30am [16:24] jam: let me see... 4err, 3fail - 2err -2fail -2err, that leaves only the asserts :) [16:24] igc: ahh :-) [16:25] jam: 1.24 :-) [16:26] * jelmer isn't used to seeing Australians on IRC around dinner time :-) [16:26] jelmer: dinner at 17h26 ? :-) [16:26] jam: trying to put the eol issue to bed. It just refuses to die because every man and their dog has an opinion :-) [16:26] igc: at least their cats leave you alone :) [16:26] small mercies [16:27] vila: traditionally dinner time in .nl is around 6 [16:27] igc: for what its worth.... I think your final "native" and "native:crlf" for people that really need it is a decent proposal. [16:27] vila: not that I ever eat before 8 :-) [16:27] I'm not 100% sure that the content filtering stack is 100% right, but it is probably good enough for what we want [16:28] (I think I would rather register a handler for the property name (eol) and then have it passed the value, and it returns the actual filters at that time) [16:28] but hey, you wrote it :) [16:28] I didn't [16:28] anyhow, I just need lifeless to not block releasing a 1.14 format and to get a majority consensus on eol naming and it's done and dusted [16:28] jam: there is a fallback method that does exactly that: value -> stack [16:28] of course, I can throw a big wrench, should it be called "eol" :) [16:29] thanks to jelmer bugging me about it [16:29] igc: yeah, but it is a bit cludgy versus doing that from the beginning [16:29] jam: you get both - dictionary lookup + lookup function - and can use whatever makes the most sense [16:30] jam: and it's internal-ish [16:30] getting UI consensus is the harder issue it seems [16:30] is there a way to prevent users from committing changes directly to certain files in a branch [16:31] igc: its internal ish, but hard to change for compatibility reasons [16:31] anyhow, time for bed [16:31] and only letting them be changed by merges? [16:31] night all [16:31] phinze: no [16:31] what is your use case ? [16:31] * phinze is having trouble in dev group with constant mistakes of people committing changes to a shared library too far downstream [16:32] phinze: so the issue is that in a distributed system, you don't really have any control over individuals machines ... [16:32] Providing a way to help people realize they didn't actually want to modify something [16:32] is something we would be interested in [16:33] but ultimately, the point of distrbuted VCS is that people get to do what they want [16:33] right, but when they push to a shared location we can yell at them [16:33] the hooks are there in order to examine changed files pre-commit and conditionally reject, no? [16:35] jam: was there a conclusion about whether subtrees (even in disabled form perhaps) were going to make it into the bbc format? [16:36] jelmer: both patches reviewed [16:37] jam: try -s bt.interrepository_implementations [16:37] jam: 14 errs and counting :) [16:37] vila: thanks, much appreciated [16:39] jelmer: the serializer will support subtrees [16:39] the "supports_subtrees" flag will probably be set to False [16:40] vila: are those new, or ones we just didn't see before? [16:40] new they all say 'KnitPackRepository' object has no attribute 'supports_tree_reference' so probably related to your last fixes [16:43] jam: also -s test_fetch.Test1To2Fetch.test_fetch_ghosts errors with KnitPackRepository('file:///tmp/testbzr-lKx3YV.tmp/bzrlib.tests.test_fetch.Test1To2Fetch.test_fetch_ghosts/work/tree/.bzr/repository/') has no revision ('ghost-parent',) [16:43] jam: neat [16:45] Hi. It seems the 64bit package for intrepid from the ppa is not installable, there is an error: http://paste.pocoo.org/show/110454/ [16:51] jam: so re above, conceptually are the pieces there for me to tie together to have a pre-commit hook on a certain shared branch that checked modified files and rejects commits if protected files are modified and the commit is not a merge? [16:52] not a merge from a certain branch even [17:13] vila: yeah, I had a typo in there "target.supports..." rather than "target._format.supports" [17:13] weird that the other tests started passing [17:17] grr, C-w is cut damn it, not close window, or vice-versa... [17:17]