[00:20] If I have a git import into bzr that has moved a bunch of files around (basically, moved a directory with files in it into another directory) is there a way for me to tell bzr about this when I merge that branch into my branch? [00:20] cody-somerville: possibly using 'mv --after' will help [00:21] is this imported using bzr-git [00:21] yup [00:21] so I figure the files all now have new file ids since git doesn't have that concept [00:22] cody-somerville: yeah, there isn't really a good way around that atm. [00:24] :( [00:38] cody-somerville: live-helper/live-build by any chance? [00:38] mwhudson, aye [00:42] poolie: thanks for the heads up [00:42] poolie: so the intention is to get 2.2 into maverick I assume? [00:53] yes [00:54] i think we're still good for that [01:07] Good morning. [01:09] G'tag spiv [01:09] oh hi spiv [02:43] spiv, hi, is bug 522637 still open? [02:43] Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 84)" [High,In progress] https://launchpad.net/bugs/522637 [02:48] lifeless, do you know anything about just what U1 is doing with bug 607850? [02:48] Launchpad bug 607850 in Bazaar "RevisionNotPresent in repository directory synced to UbuntuOne (affected: 1, heat: 9)" [Undecided,Incomplete] https://launchpad.net/bugs/607850 [02:49] poolie: yes, it's the main thing I'm working on. The root cause has been fixed, now I'm making a repair tool. [02:50] maybe we should mark that bug fixed and file another asking for a repair tool? [02:50] i can do it [02:51] have we done a point release on all the old versions ? [02:51] do you mean a backport of this to 2.0 and 2.1 etc? [02:51] poolie: they are changing their directoy sync code, introducing a thing called 'generations' [02:51] i see you declined the tasks for that.? [02:52] poolie: yes, that was way back [02:52] so we can be confident u1-client is actually broken in this way at present? [02:52] yes [02:53] ok [02:53] because the old client is still live on lucid etc [02:53] istm we should backport bug 522637 [02:53] Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 84)" [High,In progress] https://launchpad.net/bugs/522637 [02:53] once they SRU everything and disable the old API, then we have t reevaluate [02:53] It already is, I think. [02:55] Yeah, it is. I'll update all the various bug targets, I guess I forget to update them in the relative chaos of being at the epic. [02:55] np [02:55] i'll do it, i have things open [02:55] Ok, thanks. [02:56] poolie: that john gilmore bug comment was a bit of a zinger wasn't it [02:56] kind of disappointing [02:56] yes [02:56] I think he had just had a bad experience [02:58] probably [02:58] it would be disappointing === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === timchen1` is now known as nasloc__ [04:18] If I'm running lenny, would there be any issues adding the bzr nightly ppa? [04:19] or maybe a stable ppa for it? [04:21] or maybe I should just grab the .deb? [04:22] https://edge.launchpad.net/~bzr/+archive/ppa <-- looks close if it actually had bazaar in it [04:23] there's no .deb :P [04:23] https://edge.launchpad.net/bzr/+download [04:23] MTecknology: the package is called 'bzr' [04:23] So not sure what you're saying the PPA is missing? [04:24] spiv: there's qbzr - but not bzr [04:24] unless they're the same? [04:24] They're not the same (qbzr is a plugin for bzr), but I see bzr in that PPA. [04:25] spiv: I guess it helps if I'm not looking at the lucid series [04:26] lot more going on in anything prior to lucid.. [04:26] spiv: sorry [07:40] spiv, nice test patch :) [07:41] Hm. The progress-stipple-all-over-my-terminal bug isn't a 2.2 block? [07:41] it should be [07:41] i should do it now [07:45] Yeah. Bugs like that are minor, purely cosmetic, hurt nothing... and have a hugely disproportionate "wow, this is a crappy broken tool... next!" effect :| [07:50] poolie: thanks, nice to have an idea you can implement and try nice and quickly :) [07:51] The full test suite is now taking about 8m 42s on my laptop, and I haven't experimented with ram disks yet. [07:51] spiv: i ran one launchpad windmill test on my netbook in 4 minutes earlier :-) [07:52] fullermd: i agree [07:52] Hmm, and as a side effect I think partitioning that way tends to help avoid the "can't start new thread" problem, because the thread leaks are spread more evenly :) [07:52] hrm [07:52] (At least, I'm not seeing it now, and I think I was before.) [09:17] it probably will fix it [09:17] it's probably the best way [09:18] hi poolie [09:19] poolie: I need your help or somebody else of admin [09:19] poolie: this page http://doc.bazaar.canonical.com/explorer/en/index.html supposed to be auto-generated from lp:bzr-explorer-website branch [09:19] hi bialix [09:20] yesterday I've made some small changes to that branch, but it's not visible on the website yet [09:20] ok [09:20] and it's not? [09:20] i'll check [09:20] see left side bar with NEWS [09:20] btw i went to see igc last friday [09:20] he says hi [09:20] I've changed to 1.0.2 [09:20] how's igc? [09:21] he's pretty thin but he's still hanging in there [09:21] he went home from hospital on tuesday [09:21] sad [09:21] good he's still fighting [09:22] poolie: I have a question about english. recently you wrote in the answer that igc left big shoes to fill. "big shoes to fill" means many work to do? [09:23] well, kind of [09:23] more that it will be hard to do it as well as he has [09:23] he sets a high standard [09:24] ah, in that sense [09:31] spiv, bialix, would one of you review https://code.edge.launchpad.net/~mbp/bzr/611127-2.2-progress/+merge/31824 [09:33] poolie: about bzr-explorer-website more details: initially lp:bzr-explore-website has pointed to https://code.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk, then igc changed owner of that branch to be ~bzr. maybe cron script still trying to update from his personal branch? [09:34] ah maybe [09:35] pollie: sorry, I'm a bit busy wih urgent call on work. also today I want to release qbzr 0.19 final and explorer new beta [09:35] np [09:35] yes, that was it [09:35] poolie: reviewed [09:36] And with that I'm done for today I think, little Vincent is a bit sick again :( [09:36] thanks [09:36] :( get well soon V [09:36] i'm still a bit sick myself [09:36] (little Vincent: not to be confused with big Vincent! :) [09:36] Hi, I have a launchpad project with a branch. Only I can commit, but how I can give permissions to another person to commit with the same prileges as me? [09:36] big Vincent is vila? [09:36] bialix: yes [09:36] right :) [09:37] Big Vincent :-D [09:37] shakaran: change the owner of the branch to be a team [09:37] shakaran: this will change the branch url to be eg [09:37] Then anyone in that team can change that branch. [09:37] ~myproject-dev/myproject/trunk [09:38] (But if you mark that branch as the development focus, then you can also use lp:myproject as the URL for it, regardless of who owns it) [09:38] Ok, really gone now :) [09:38] Have a good night everyone. [09:39] me too, unless there's anything else i can do for you bialix? [09:39] thanks fro maknig a relrease [09:39] obviously i should stop with typing like that :) [09:40] good night poolie :-) [09:40] I've sent you mail about book earlier, but this can wait [09:45] thanks poolie, website updated! [10:02] spiv: and pollie thanks, all working [11:39] gooooOOOOOOOO bizarre! [11:39] http://paste.pocoo.org/show/246221/ [11:40] this was from [11:40] bzr revert -r . [11:40] which I know is wrong [11:46] magcius: can you file a bug report? [11:48] bialix: unfortunately, nVidia, so that means that Launchpad is unbearably slow [11:48] Let me see if I can remember how to do the email bug report thing [11:48] would it be bzr@bugs.launchpad.net? [11:48] I guess so [11:49] you may need to gpg sign mail though [11:50] bialix: hm, should I put the backtrace in the body or attach it? [11:50] (or use a pastebin) [11:50] in the body please [11:50] magcius: wait [11:51] bialix: waiting [11:52] magcius: https://bugs.launchpad.net/bzr/+bug/613804 [11:52] Launchpad bug 613804 in Bazaar "`bzr revert -r . ` failed with traceback (affected: 1, heat: 6)" [Undecided,New] [11:52] for you [11:52] bialix: oh hey thanks [11:52] Hi all - at the company I work at, we have ~160 projects sitting in a bzr repository. A load of these projects are deprecated or replaced. I'd like to move them to a "legacy" repository - what's the best way to do this? If I init-repo and pull stuff across, can the source then be deleted...? [11:52] np [11:53] Lebannen: do you mean shared repository? [11:54] almost certainly :) [11:54] we store them in one location for neatness, but I think many of the projects are treated as branches by bzr in terms of sharing storage [11:54] you'd better create 2 new shared repos: first for old stuff, and second for actual stuff. and branch from old to corresponding new one [11:55] then backup/rename/kill old repo and replace it with second new (with actual branches) [11:55] Aha, ok [11:55] thus you will filter out the old cruft [11:56] otherwise old repo will still keep revisions of your old branches [11:56] good point. [11:56] there is no other way to collect garbage from shared repo [11:56] Hmm, could current checkouts be rebased, or is the easiest thing to blow it all away? [11:57] bzr switch --force [11:57] perfect :D [11:57] Many thanks, I'll work through that [11:58] np [12:04] Hi... I am using the nautilus-integration of bazaar and really like it. But when I right-click on a file and select "view changes" it'd be nice to have the changes dislayed in meld instead of the graphical diff that comes with bzr-gtk. Is that possible? [12:05] dakira: not at the moment, can you file a wihlist bug about it perhaps? [12:08] jelmer: that bug should go to bzr-gtk, right? I think nautilus-bzr only displays context-menu shortcuts to the dialogs of bzr-gtk. [12:08] dakira: yeah - it's the same project thugh [12:09] *though [12:09] okay [12:35] jelmer: I added my suggestions to an existing (very old) bug.. should I report a new one? https://bugs.launchpad.net/bzr-gtk/+bug/70477 [12:35] Launchpad bug 70477 in Bazaar GTK+ Frontends "integrate meld (affected: 3, heat: 5)" [Wishlist,Confirmed] [12:35] dakira: No, that's fine - thanks === Ursinha-afk is now known as Ursinha [13:23] id like to run bzr break-lock non-interactively, -q doesnt seem to do it [13:26] jave: please file a wishlist bug [13:26] jave: it should be possible to do from python, but I don't think we have that exposed on the command-line [13:26] jave: Why would you like to break locks non-interactively though? [13:48] jelmer: because I have a hudson server building emacs, and sometimes bzr leaves locks, so I want to do break-lock non-interactivly from hudson as a workaound [13:50] jave: That could lead to repository corruption, I'd recommend fixing the underlying issue. [13:58] sure, but I have no idea what the underlying issue is [13:59] you may want to inspect .bzr.log [13:59] jave: two bzr processes running on the same repository at the same time? [14:00] then its a bug in the hudson bzr plugin [14:00] jelmer: Can I get your thoughts on what it will take to convince you to merge https://code.edge.launchpad.net/~maxb/bzr-svn/fetch-svn-rev-info-progress-bar/+merge/28960 ? You expressed some hesitation on the basis that that code has been "fixed" several times in the past, but I'm quite convinced that my branch is better that what's there now. [14:16] maxb: I'll give it another look. [14:17] thanks [14:50] why doesnt this work? bzr checkout bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/future [14:55] jave: I think you need http://, afaik sourceforge doesn't run the bzr smart server [14:56] oh, they do.. nevermind [14:56] this seemed to work though: bzr init . && bzr branch bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/branches/future [14:56] jave: The bzr init . isn't necessary [14:57] jave: according to http://rudel.bzr.sourceforge.net/bzr/rudel/ there is no branch called future, only branches/future [14:57] yes aparently === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [15:48] Hi, I keep getting a crash when trying to branch a repo [15:48] http://pastebin.com/zaqSp7Sx [15:49] and bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:576fa262710cb8cadf998f50c33f4fa28ac6f57b',)] [15:49] does anyone have any idea what the problem could be? [15:50] lamalex: I think there might be an open bug about this issue [15:50] oof [15:52] it seems I already have the latest bzr from the lp ppa [15:52] is there anything I can do? [15:52] not being able to branch is pretty critical for me, heh [15:54] lamalex, see https://bugs.edge.launchpad.net/bzr/+bug/522637 [15:54] Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 86)" [High,In progress] [15:56] jelmer: so it looks like it's fixed in 2.0, when will 2.2 be released? [15:57] would an bzr upgrade possibly fix the problem? or is there some kind of metadata fixups that can be done? [15:58] lamalex: 2.2 is due out on friday I believe [15:58] lamalex: upgrade won't help as lp:do is already in the latest format [15:59] lamalex: There is an open bug about "bzr reconcile" fixing this issue in existing repositories: https://bugs.edge.launchpad.net/bzr/+bug/613698 [15:59] Launchpad bug 613698 in Bazaar "need reconcile fixer for bug 522637 "missing referenced chk root keys" (affected: 1, heat: 6)" [High,Confirmed] [15:59] yeah, I guess I'll just watch https://bugs.edge.launchpad.net/bzr/+bug/613698 and cry [16:00] lamalex: Anyway, spiv is the right person to talk to, he has fixed the first bug and is assigned to fix the second. === Ursinha is now known as Ursinha-brb [16:01] How do I ask bzr diff for the differences between a revision and one of its merged parents? [16:02] I tried bzr diff -r parentdottedrevno..revno, and it gave me the differences *of* parentdottedrevno AND revno [16:07] Oh. No it didn't. jelmer just did bunch of other stuff whilst merging my change, and confused me :-) [16:07] sorry :-) [16:22] how cheap is branching in bzr respect to git? If i get this right, it has to do a WHOLE directory again for every branch even if it is a shallow copy [16:22] please explain, i am interested in adopting bzr [16:23] to work in git-style you need bzr-colo plugin [16:23] sussler: Only if you use a new working tree for each branch. you can also re-use an existing working tree, in which case the overhead is only a couple of files. [16:23] in this case you can share the same working tree for several local branches [16:23] ok let me make an example here [16:24] let's just say that i have a really, really complicated merge history in git [16:24] like more than 20 branches merged in various ways one with the other and then merged back to master [16:25] would a similar model be possible without losing history of every working tree when doing the merge? [16:25] sussler, sure [16:26] hmm [16:26] ok, let me get this right then [16:27] branches 1 - 5 with different history getting merged with multiple bzr merge --force commands (if i am not mistaken) [16:28] each of them done with a --notree option [16:28] then i simple rm -rf the branch "dirs" and it is bye bye [16:28] correct? [16:28] nothing lost [16:28] right, their history lives on in the branch you've merged them into. [16:30] ok [16:30] there is no branch "delete" option because a branch is a physically contained directory in the filesystem [16:30] am i right [16:30] you poof the dir, cleaned up the mess [16:31] sussler, yes [16:32] sorry for being newbiesh, but i am trying to get a grip of bzr, since launchpad is so effin nice :P [16:35] ok, so, lesson learned: 1) use shared repositories 2) do branches as physical dirs inside them, 3) use no tree option 4) proceed with --force in octomerge style [16:35] correct guys? [16:37] sussler: For octopus merging --force is indeed requirement; the other points are all optional and depend on your personal preferences and workflow. [16:37] ok [16:37] thanks a lot [16:37] will study a bit more before i ask something else, you have all been very very helpful [16:37] instead of telling me to RTFM [16:37] :P [16:42] jelmer: who is active maintainer of bzr-gtk now? [16:44] bialix: There are a couple of people that fix urgent bugs when they come up, but nobody is really doing any active maintainance. [16:45] my proposal re language option is not urgent fix, of course. ok, will know [16:46] bialix: bzr-gtk doesn't really have any translation support [16:47] hmm, strange [16:47] I remember there was one in olive in old days [16:47] bialix: Yes, olive is translated but bzr-gtk is not (they're separate projects again nowadays) [16:47] ouch [16:48] bialix, Hmm? [16:48] I've missed the divorce, it seems [16:49] okay, thank you for information, I was under wrong impression bzr-gtk has i18n support [16:49] happened about 2 months ago I think [16:49] olive still depends on bzr-gtk, it's just that they're two different projects again [16:49] in a similar way as bzr-explorer and qbzr are different [16:50] I see [16:51] I really did not know that bzr-gtk has no i18n inside [16:54] Hi, I'd like to share a repo between two users on the same (Unix) machine. With SVN, I know you can run into problems if users don't have a proper umask when accessing the repo. Is there the same kind of problem with bzr? === Ursinha-brb is now known as Ursinha [17:04] yep, at least if you use SSH (or direct filesystem) access [17:06] ok, that's what I was thinking [17:06] also [17:07] I'm surprised because friends of mine are using such a setup (sftp acces rpecisely) without taking any precautions (no setgid bit on the repo, umask 022) and didsn't have any problem (yet) [17:08] you should have your shared repositories dirs (esp. stuff below .bzr) set to u+rwx,g+rwxs [17:08] I guess they are not both writing to the same repository [17:08] okay, so precisely the same as with svn [17:09] or maybe the permissions issues became less significant with newer repository formats [17:10] bzr repos used to rely a lot more on the filesystem as a database than they do nowadays [17:10] other would know better [17:10] they are writing to the same repo [17:10] it's a repo without a tree, in case it makes a difference [17:11] bzr tries to preserve dir permissions when creating subdirs, but I read that sftp servers will lie about those [17:11] they both have a checkout on their own machine, and are pushing to the repo using sftp, but with different Unix accounts [17:12] mpg... well, if it works, don't fix it :-) [17:12] you know where to look if it ever breaks [17:12] ;-) [17:12] mh random guess [17:13] maybe they are actually using bzr+ssh, not sftp [17:13] well, my question is, whether I can recommend this setup [17:13] because it's so easy to configure [17:14] no, I'm sure they are using sftp (that's what bzr info in their checkouts says, anyway) [17:15] so that's what they're using [17:15] better to recommand bzr+ssh, if bzr can be installed server-sid [17:15] it's significantly faster [17:16] I'm trying to find specifics about multi-commiters repos in the doc [17:17] I must say, I'm slightly disapointed by the doc (or what I have read of it); the svn book is much more specific about the pros and cons of various server setups [17:17] well, it's not a book [17:17] right [17:18] the doc does not say anything about setting permissions or umask [17:18] yep, I checked before asking here [17:18] so either my knowledge is outdated and the problems were fixed, or the doc is incomplete :-) [17:19] I would have felt more confident if the doc stated explicitely that there is no need to setgid and set umask [17:19] :-) [17:20] in my experience, the permission problems occured very soon, with the repository lockng system [17:20] ok === beuno is now known as beuno-lunch [17:21] bzr used a clever dumb-filesystem lockin scheme that was invented by gnu arch [17:22] since history never changes, it does not seem impossible (besides the locking issues you mentioned) that files created by one user never need to be modified (possibly by another user) afterwards [17:22] that was very clever, basically it started from "what, if anything, has atomicity guarantees on NFS" [17:23] that would not be the case with newer formats [17:24] I do not know the specifics of things now, but used to have "one file per atomic chunk of data", and it was terrible performance wise. [17:24] as the linux hackers say, "the filesystem is not a database" [17:25] ^^ [17:25] if anything, it's better to just append to a file and have file format that supports easy synchronization. [17:25] and indexes, bzr uses a bunch of indexes [17:27] so, I'd say, go for it [17:27] "the document does not say anything against it, it must be good, and it works for them" [17:28] or do your own testing if you are unsure [17:28] it's quite likely that a sensible umask is needed though [17:28] but it might be already be set sensibly on their server [17:28] right, but I'm afraid I don't know enough what to test [17:29] create a repo with one user, push a single commit there [17:29] have another user get a checkout make another commit [17:29] I checked the file permission in the .bzr on the server (to which I happen to have access), ther umask seems to be the usual 022 [17:30] Yep, I'll try [17:48] ok, so according to my tests: [17:49] * if you are using a single branch, chgrp -R && chmod -R g+w on the repo is enough [17:50] * but if you want people to be able to create and chare new branches on the repo, you have to rely on the usual setgit & umask 002 trick [17:51] I'm still not very confident about the first point, but I just didn't get any problems in my tests [17:52] you tested that on local filesystem, or through some other transport? [17:55] when i do bzr info i see a "Related branch" which no longer exists, can i remove it? [17:56] Buttons840: cannot parse that. If the push/parent branch no longer exists, you cannot remove it anymore, right? [17:57] tested on local filesystem [17:57] ddaa: i don't know, that's why i'm asking [17:57] is it different from sftp? [17:58] I'm pretty sure you cannot delete anymore something that was already deleted. [17:58] mpg: might be :-) I'm asking because I'm curious myself. [17:58] i don't want to delete literal files, but i do want to remove the reference which says Related branches: submit branch: bzr+ssh://192.168.0.104/home/buttons/Code/CallNSee/Working/ [17:58] Buttons840: you want to deleted the reference to the delete branch in the other branch, maybe? [17:59] oh, you just said precisely that as I was writing [17:59] basically i have my code on my desktop, and i branched it to my laptop to take it with me; i've since deleted that branch entirely from my laptop but this "submit branch" still lingers [17:59] Buttons840: the submit branch is a setting that's used by commands like bzr send, bzr bundle, etc. [18:00] so will i always have this non-existent "submit branch" as part of my project? [18:00] it does not do any harm as it is, but if the bzr info output annoys you, you can remove the setting by editing .bzr/branch/branch.conf [18:01] it's not part of the project, it's not even versioned data [18:01] it's just a convenient branch-specific default value for some bzr commands [18:02] ddaa: ok, editing the branch.conf will work [18:03] is there a more friendly way to remove it? i'm not so concerned about this one particular "listing" (what are they called?), but in one project i have 3 or more "listings" none of which actually exist (probably a fault of my playing around), but i would like to keep the list from growing permanently every time i make a mistake [18:05] anyways; problem solved; thanks === beuno-lunch is now known as beuno [19:20] is there a command to see the entire configuration for a particular working tree that i'm in? [19:21] `bzr info`? what do you mean exactly? [19:23] i have a path in locations.conf with create_signatures = never, and bzr seems to be trying to sign commits in that tree [19:23] bzr info shows a very limited set of things [19:25] if there's something specific you want shown, file a bug. [19:26] i want to see all the configuration affecting bzr in that working tree. so that i can debug why this suddenly stopped working [19:28] you want it to cat your conf files to the terminal? why not just open them in your favourite text editor... [19:29] there would be value in showing the values it was using and where it was taking them from, given that you can have multiple files that stack [19:29] no, i want to know if something is overriding what is in my locations.conf [19:29] and multiple stanzas in locations.conf [19:29] printing something about specific locations.conf rules seems a reasonable idea, but "all the configuration affecting bzr" isn't going to be helpful. [19:30] well having "bzr help configuration" actually show me what the current configuration is, in the context i'm in, would be more helpful than dumping pages and pages of hard to read, unsearchable text :) [19:30] `bzr version` shows you where the conf files are. [19:35] right, but bzr hasn't been updated in maverick in 10 weeks, and i haven't manually changed the config, so by all means, i shouldn't be having this problem [19:42] if you want help debugging what has msyterously gone wrong when you haven't changed anything, more details might assist those able to help you [19:43] if i had more details, i wouldn't be asking how i can get them :) [19:56] is there any way to view the value for specific configuration variables, within a working tree? [19:57] (if the answer is python -c "import bzrlib.blah.blah; do stuff" that's fine by me for now) [19:57] only from python as far as I know [19:57] how do i do it from python? [19:58] python -c "from bzrlib.branch import Branch; branch = Branch.open("."); config = Branch.get_config()" [19:59] you want "print config.signing_policy()" at the end I think [20:05] hrmm, i guess that doesn't work so well with a lightweight checkout? [20:05] no [20:06] use bzrlib.workingtree.WorkingTree for the open, and then branch = wt.branch [20:07] How can I tell bzr to stack on a different remote branch? [20:07] ah lovely, it just prints "1" [20:07] I tried --stacked-on=lp:branch [20:07] whatever that means [20:07] but it only seems to look for local ones [20:07] do I need to do the bzr+ssh:// full uri? [20:08] dobey: SIGN_ALWAYS unsurprisingly [20:09] lamalex: possibly [20:09] worth a try [20:09] heh, ok [20:09] james_w: :( [20:09] james_w: i guess it's using the default setting, rather than the one from locations.conf [20:10] quite possibly [20:10] this makes no sense [20:10] it was working fine yesterday! [20:10] you just have it set in bazaar.conf, and trying to overwrite it for one location in locations.conf? [20:10] yes [20:12] I don't know then [20:12] it's definitely ignoring what's in locations.conf though :( [20:14] dobey: you have the path to the branch, or the path to the working tree in locations.conf? [20:15] i have [/var/cache/tarmac] in locations.conf, and the lightweight checkout is in /var/cache/tarmac/libubuntuone/trunk [20:15] is it because it's a lightweight checkout? [20:15] probably [20:16] :( [20:17] definitely :-/ [20:20] ok. /me files bug [20:26] https://bugs.edge.launchpad.net/bzr/+bug/613986 [20:26] Launchpad bug 613986 in Bazaar "locations.conf settings ignored for lightweight checkouts (affected: 1, heat: 6)" [Undecided,New] === beuno_ is now known as beuno [21:37] abentley: hi, is there a way with bzr-pipeline to copy a remote pipeline to your machine? [21:37] i tried a few things with sync-pipeline but didn't get it to work [21:38]