[00:18] Wow. Just, wow. http://github.com/guides/completely-remove-a-file-from-all-revisions [00:19] ool huh [00:19] *cool huh [00:19] Pieter, I hope you just forgot your sarcasm tags. [00:19] no [00:19] why? [00:20] Pieter, you should never be changing revision data. Revisions should be immutable. [00:20] revisions are also immutable in git [00:20] there are valid use cases, like having a plaintext password as the guide says... that's very difficult to do in bzr [00:21] Pieter, if you commit a plaintext password, you change your password. [00:21] or you just edit it out like in the guide, that's a lot easier :) [00:22] there are other use cases, like going public with some code but having to remove some company-sensitive information before publishing it [00:22] Pieter, do what launchpad is doing and create a fresh branch. [00:23] and then how are you going to remove that info? [00:23] I wont have any local history with --no-tree? [00:23] There is no info to remove. It's bzr init. [00:23] and loose all your history just because there's some sensitive information in it? [00:23] that's kinda lame [00:24] Pieter, so you're going through all 100,000+ revisions making sure that EVERY bit of data is clean for the general public? [00:24] you don't have to have 100,000 commits ;) [00:24] but if you have, say 100, but there are a few files in it you rather wouldn't have public [00:24] sure, you do stuff like this [00:24] why not? it's easy [00:25] Pieter, okay. You change your revision data. [00:25] everybody will thank you for publishing the full history :) [00:37] one time some people on my team said the team lead was hairy and wrestled bears on his free time [00:37] the checked that into svn [00:38] I thought it was pretty funny but when I left the company, removed it :-) [00:38] why? [00:39] (At first I thought that with 'team' you meant 'baseball team' or something, and then started to wonder why they'd use svn) [00:41] lol [00:41] why remove it? [00:42] yes [00:42] and why remove it when you left? [00:42] I was still involved but in a more authoritative capacity [00:43] wanted to make sure that I didn't encourage that type of thing against others [00:43] I left the company but was consulting sorry if that wasn't clear :-) [00:43] ah, right, I was thinking "why would you care?" [00:44] it's a tricky thing [00:44] it was actually quite clever [00:45] the person responsible checked it in as a Python pickled. should have saved it. [01:41] Is there an equivalent of 'bzr cp SRC DEST'? I want to copy a file and make changes to it with its own history, after the copy, but if possible, to capture that a fork occurred. [02:09] jkakar: No. [02:10] Peng_: Thanks. [02:11] Sorry. :\ [02:27] jkakar: wow [02:27] jkakar: what an odd omission! I must be really good about not duplicating code, since I've never needed that :) [02:30] glyph: Heh. One use is when splitting a file into two. OTOH, I suppose if you organize your code well enough from the beginning, you won't need to.. [02:38] Peng_: I can definitely see uses for it === udk is now known as UdontKnow [03:47] glyph: Heh. I'm implementing a new skin and want to use the CSS file from an existing skin as the base for the new one. [04:11] Anyone know what's going on with launchpad? After gw0-0-gr.canonical.com latency skyrockets for me === BasicPRO is now known as BasicOSX [04:23] BasicOSX: WFM. Is it still happening to you? [04:23] (Just trying launchpad.net.) [04:23] Peng: yes, semi-intelligent discussion about it on #launchpad [04:23] BasicOSX: Oh, right. [04:25] Hooray for distributed revision control systems and not depending on a single point of failure like that. [04:25] I'm not sure that bazaar.launchpad.net is actually broken. [04:28] $ bzr branch lp:bzr [04:28] bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 503 Service Temporarily Unavailable [04:29] Ah, forgot about the XML-RPC server. [04:29] Heh. [04:29] But using bzr+ssh directly might well work. [04:29] I'd prefer not to step out of the documented and trusted release procedure :-) [04:31] Eh, nothing will go wrong if you do. Probably. :-D [04:56] question: can I branch a launchpad project to my local machine, and bind that branch to a hosted launchpad project on my account, so that when I bzr update, it retrieves from the original trunk and bzr commit sends to my hosted project? [04:58] I was trying it like this: [04:58] bzr init [04:58] bzr branch lp:project [04:58] bzr branch project mybranch [04:58] cd mybranch [04:59] bzr push lp:~(account)/project/mybranch [04:59] bzr bind lp:~(account)/project/mybranch [04:59] I think you just want to do a bzr push --remember your-repo [05:01] without the bind command? [05:02] Hi! I'm new to Bazaar (and version control in general), and am looking to find whether this tool is suited to my project. I'm working on a Django project solo. I would like to run the public version of my web app on mysite.com, and meanwhile be working on new features on mysite.com/test. Once I've tested a new version, I want to be able to update the main version with my development branch. What would be the simplest way to d [05:02] By the way, for more context, the precursor to this question is here: http://stackoverflow.com/questions/625256/how-do-i-run-one-version-of-a-web-app-while-developing-the-next-version [05:04] btw, uncommit rocks :) [05:07] LKRaider: sorry only 20% here, monitoring the outage on launchpad [05:09] oh, yeah, launchpad comes first :) [05:10] I believe the --remember flag is what I want. testing right now [05:12] (...alternately, let me know if another tool like SVN would be better suited for this task. Someone originally recommended SVN to me but I figured bzr could do it as well.) [05:16] RexEast: I use bzr under turbogears and works very well, use a similar strategy, except I have a production server and development server [05:17] BasicOSX: doesnt seem to work as I want it. if I do bzr update, it returns as up-to-date, even tho I have branched from a middle revision from the original trunk [05:18] LKRaider: after you branch don't do update to merge [05:18] bzr merge --remember upstream [05:18] make changes [05:18] bzr push --remember your-repo [05:18] @BasicOSX: neat! How would I get started with something that works like yours? Note: I don't need separate servers; this is a very small-time operation for now. The dev version can be on the same server as the production version. [05:20] RexEast: create your dev repo, then bzr push it to a central area [05:20] Then bzr branch from the central area into your production [05:21] work all you want in your dev repo. bzr committing as you wish [05:21] when happy with the work, bzr push dev to central area [05:21] then bzr merge in your production [05:22] If you have to tweak things in product, just bzr commit and push to a different report if need be, at least that is how I do it [05:22] There is probably some way if doing series and whatnot, but what I do is pretty simple [05:24] Thanks! I'm going to read over that for a minute and try to figure out which commands I'd use to set that up on my Linux box. [05:28] BasicOSX: thanks, your idea seem to work fine for me now :) [05:30] can I use bzr bind, after the push, so that commits go to the hosted branch automatically? or would that break something? [05:36] @BasicOSX: why do I need to have the central area? Couldn't I just push my changes directly from my dev repo to the production server? (Sorry, I'm new to all this :) [05:39] generally there's a few difference between production and development, like what database or tables you use, debug, logging, etc. The split allows for both code bases to live in the central area but branches to live in production and development [05:40] My reasons for it are more simple, I was my repository on a different box so have code in multiple places incase hardware crashes and burns [05:40] also production has live access to the Internet, development restricted access, still to the Internet, I put my repo that is not on the box incase there is a compromise [05:50] Anyone free to help a noob? Do I need to register a branch before I use bzr send -o foo.patch? [05:50] I am feeling a bit overwhelmed here trying to properly submit a patch. I have been following http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html [05:52] I think this will create a patch file that you'll have to email to the upstream project somehow [05:53] if you are using launchpad, there is a merge button that you can use to request your branch to be merged on the parent trunk [05:53] but I am a noob too :P [06:01] adelie421: If your branch is public, it would be easier to say "hey, merge my branch at http://whatever".. [06:01] adelie421: But no, you don't need a public location when using "bzr send". [06:01] adelie421: You should make sure the public_branch is set properly on your copy of the target branch, though. [06:29] Peng_: sorry, was afk. So wanted to fix some bugs in example-content. I used bzr branch (site), bzr merge, added my pieces, then bzr add, bzr commit -m "details", bzr send -o details.patch. it uploaded and said successful. Thats it, right? [06:30] lifeless: ping? Did you PQM 1.13-cherrypicks? [06:38] adelie421: ...More or less, probably. [06:38] adelie421: It's good to have the proper public_branch value set, to make it easier for people merging it. [06:39] adelie421: I'm not sure if that would happen automatically or not. [06:40] I got an email from the maintainer seperately, so hopefully they will let me know if I did id right. I figure given the time I should just take a break for now and follow up on that tomorrow [10:46] hello, does anyone know how to set a server-side variable in bzr branches? [10:47] specifically: cia_project = timekpr [10:47] ( in .bzr/branch/branch.conf ) === pigmej1 is now known as pigmej [11:52] mtaylor_: r4142 of bzr.dev looks like it might adress our push problem === AfC1 is now known as AfC [14:41] man, I wish there was a MIME registration for diff-style patches :-( [14:57] SamB: bzr-gtk registers bzr-handle-patch for one of the mime types I think [15:01] hmm, three different types [15:02] mime_types=text/x-diff,text/x-patch,application/x-bazaar-merge-directive [15:19] Spaz: saw http://bazaar-vcs.org/BzrFileCopieshttp://bazaar-vcs.org/BzrFileCopies ? [15:20] Spaz: the last one being what `bzr send` produces [17:48] hmm [17:49] how to get touching revisions for file [17:49] not a file_id ? [17:49] for file_id there is method [17:49] log.find_touching_revisions(branch, file_id) [17:50] how to do the same but without file_id ? [17:50] or how to generate file_id ? [17:51] I know only revtree.inventory.revision.path2id(file_path) [17:52] pigmej, in order to find the file id for a particular path, you need to retrieve the inventory first [17:52] jelmer: right, but I'm looking for touching revisions... [17:53] so I don't know with inventory is correct... [17:53] I need to make "list of revisions for file" [17:53] pigmej, that sounds like a chicken-egg problem [17:53] pigmej, in order to refer to a particular file you need to find its file id [17:54] pigmej, since there may be different files with the same name in different revisions [17:54] jelmer: but not the same file path [17:54] pigmej, yes, with the same file path [17:55] pigmej, e.g. if you have a revision in which path "foo" exists [17:55] jelmer: right... delefe, add and that's it... [17:55] then the next revision could rename "foo" to "bar" and add a new file "foo" [17:55] Yes you're right jelmer.. [17:55] the fileid of "foo" would stay with the original file [17:55] and the new "foo" that is added would have a new file id [17:57] So, I need to rewrite one class... :) [17:57] To avoid problems with renamed files ;) [17:57] jelmer: thanks I forgot about that possibility :d === serg_ is now known as serg === mtaylor_ is now known as mtaylor [21:52] Spaz: saw http://bazaar-vcs.org/BzrFileCopieshttp://bazaar-vcs.org/BzrFileCopies ? [21:52] Spaz: the last one being what `bzr send` produces [21:52] LarstiQ, hadn't heard of it [21:52] hm. [21:55] Spaz: oh bah, I tab-completed wrongly on that second line [21:55] Spaz: the first was for you though :) [21:55] hm ok [21:56] SamB: in case you didn't get it at the time, the `bzr send` comment was supposed to be direct at you ;) [21:56] Spaz: anyway, it seems Ian is looking at it recently [21:56] hmm [21:57] Spaz: so providing feedback/coordinating with him seems like the thing to do [21:57] i could do that [21:57] unfortunately, i'm moving atm. will be semi-difficult for a week or so. [21:59] Spaz: that's fine, I'll bother you again in a weeks time :) [22:01] i'll find time still [22:01] :p [22:50] I've tried to make my repository smaller by using bzr pack and bzr reconcile but instead it made it over three times bigger (its now at 3.2GB). [22:56] cody-somerville: Right. "bzr pack" doesn't make it much smaller. However, it *does* create a complete backup of the entire repo. :D [22:57] joy [22:57] how do I delete that? [22:57] is there a bzr clean ? :P [22:57] cody-somerville: Well, the backup is created for a reason: so if you lose power before the new pack hits the disk, you won't lose your repo. [22:58] * cody-somerville nods. [22:58] cody-somerville: rm .bzr/repository/obsolete_packs/* (but *don't* delete the directory itself!) [22:58] Peng_, okay, so that brings it down to 1.6GB [22:59] what is launchpad/.bzr/repository/upload ? [23:01] cody-somerville: Temporary storage while creating new packs (e.g. when running "bzr pull" or even "bzr pack"). [23:01] It is 647M and I'm not doing either. [23:02] cody-somerville: If there are any six-month old files in it, bzr probably crashed during the middle of a pull and didn't clean up for some reason. [23:02] cody-somerville: I'm sure it's safe to clean it out, but I've never done it, so don't sue me if something goes wrong... :P [23:03] There seems to be a lock file in there so I'll leave it be for now [23:44] BasicOSX: http://pqm.bazaar-vcs.org/ for the current queue [23:47] * LarstiQ falls asleep