=== Ursinha-bbl is now known as Ursinha [00:01] yes. [00:01] thx. === Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is officially released, test it ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ [01:38] is there a special way to rename a branch in bzr? [01:43] mv [01:43] A branch doesn't need to know its own name.. it's simply a location, a directory path on disk [01:45] What is the difference between bzr pull and update commands? [01:47] pull is for updating one branch relative to another. update is for updating a working tree relative to its branch. [01:47] 'pull' brings a branch up-to-date with another copy of that branch (so long as they haven't diverged). 'updated' brings a tree up-to-date with its branch. [01:47] (except for bound branches, which break the rules to keep you on your toes) [01:48] * KombuchaKip is confused [01:49] My work here is done :) [01:49] The way I remember it is: bzr checkout, use bzr update; bzr branch, use bzr pull. [01:49] So in the centralized model, does it make a difference? [01:52] KombuchaKip: in the centralized model, you are usually be using checkouts correct? [01:52] In the centralized model (svn-style) you would typically do bzr checkout, which means you'd be using bzr update (because other people are checking into the same branch) [01:52] peitschie: Yes, I use typically a checkout first time. [01:53] KombuchaKip: jbowtie beat me to it :).... so you'll be using update, not pull [01:53] peitschie: Ok, so I will just forget pull for now. [01:54] KombuchaKip: yup :). when to start treading into branching and such, then you can learn about pull/push/merge etc. [01:55] peitschie: Fair enough. I'm still trying to decide whether to use it for my project (www.avaneya.com) or not, but leaning towards it and away from svn. [01:56] KombuchaKip: bzr is definitely worth a look.... even if you decide to stick with svn for now, don't write bzr off though :) [01:56] peitschie: My main concern is compression and handling of large binary files. [01:57] peitschie: Well, fortunately I have the luxury of choice at this point since nothing is under SCM yet so I can still choose. [01:57] KombuchaKip: that does help. What size binary files are you talking about out of interest? [01:58] On the order of tens of megs to possibly around a gigabyte. [01:58] peitschie: And they won't compress well, nor will deltas be computed likely efficiently. [01:59] KombuchaKip: ahh... i get the feeling bzr may struggle with those resources. Though work is being done to improve large binary management... I suspect gigabytes will likely blow its socks off [01:59] peitschie: I hope though that there is some attractive GUI for managing an apt repository that draws from Bazaar source. [02:00] peitschie: Well, to be fair, I don't know of any SCM that handles them well. [02:00] I think that's the arena that Alienbrain targets. [02:01] KombuchaKip: i'm not too knowledgable about the apt repo based on bazaar source guis... I think there are a few [02:01] * KombuchaKip googles said [02:01] peitschie: Yes, I'll take a look. [02:02] * fullermd glances at the site. [02:02] Oh, and alienbrain is highly portable; it works on both Windows AND MacOS! [02:02] KombuchaKip: but your definitely right about large binaries... to some degree i'd suggest for now managing their life cycle outside your code if possible? [02:02] lol... wow! both of them? [02:03] fullermd: lol ;) I only run GNU. [02:03] In Africa, the GNU runs YOU! [02:03] peitschie: Yes, that might be best to do. I'll only commit source media asset files, like models and such and have derived works like large videos generated by make. [02:03] fullermd: ;) [02:04] Hmm Alienbrain doesn't look like it's free. [02:04] I think it's highly not. [02:04] yes... it's so non-free my wallet would hurt from talking to it i think :( [02:05] peitschie: hah. It would be nice if we had something free for stuff like this. Or rather, eventually extend the functionality of Bazaar and work within its framework to have it more flexible for artists and their data too. [02:06] KombuchaKip: it's definitely coming :). there is a lot of activity on the mailing lists around these types of problems... so even if its not there yet, bzr moves quite quickly... so i don't see it being terribly far off (<6months if progress maintains) [02:06] Well, the needs of meda management and text file management are pretty divergant. [02:06] fullermd: Agreed. [02:06] AB's biggest selling point is integration with all sorts of meda-type programs (photoshop, stuff from Avid, etc) [02:07] Second to that is handling big files. I mean *big*, multi-hundred-gig-plus, files. [02:07] KombuchaKip: it wont jump up to gigabytes overnight... but tens of megs is becoming more easily within range with current advances... merge tool work is being done to allow merging of binary data (e.g., merging images, tars etc) [02:07] bzr probably isn't going to target files that size any time soon ;) [02:07] fullermd: I understand. [02:07] hehe... for sure.... theres a lot of very specialised memory management stuff that needs to happen at that level [02:08] Thanks for everyone's help and advice. I'm going to go eat some avocados now. [02:08] Yeah, it would be great if we get the Unity3D people to talk about how they do asset management. [02:09] They've got some sort of homegrown VCS for managing all those ame assets. [02:09] *game assets [02:09] Well, I'll be sure to add Bazaar to game credits and boast of how great it is on the project website. [02:09] * peitschie thinks acovados then bzr sounds like a life preference [02:09] peitschie: As a raw foodist, I like my software raw as well. I don't like it when the source code is cooked out of it. [02:10] rofl [02:10] i never thought of it that way... my mind expands once again :-/ [02:11] Well, I know I've dealt with software that felt like it gave me salmonella before... [02:11] peitschie: Raw food goes perfectly with free software. I can't stand proprietary food. No joke, we've got patents on food now. Monsanto. [02:12] fullermd: Or diarrhoea. [02:12] KombuchaKip: open source does tend to build the freshest binaries... [02:12] peitschie: I even mailed Stallman a copy of The China Study since we need to get him raw. His mind is already raw, but his body needs to be too so he'll be around for another century and finally finish Hurd. [02:13] peitschie: That's right, organic too, and not sprayed with DRM. [02:13] KombuchaKip: hehe... i dont know if a century is going to be enough for Hurd to get there. Looks like Duke Nukem Forever might beat Hurd completion lol [02:14] peitschie: Oh probably. At the least, I think he is actually reading it and that's the main thing. I want to see him healthy. [02:14] KombuchaKip: an admirable aim for sure :) [02:15] peitschie: ;) Alright, dinner time. [02:19] By the way, what's the "Gateway to LAN" I see in the Bazaar preferences for? Sounds cool. [03:55] OK, here's a scenario. Decided to branch a large, slow repository. Connectivity is lost partway through. [03:55] So on disk I have most of a repository, no branch, no working tree. [03:56] What I'd like to do is implement some sort of resume command that just pulls the rest of the repository revisions, creates the branch, creates the working tree. [03:57] Where do I start? Somewhere in sprout? [04:01] Looks like what I want is BzrDir.open_branch(), followed by WorkingTreeFormat2.initialize(), followed by a bzr pull. Does that sound right? [04:13] jbowtie: bzr checkout .; bzr pull [04:13] ? [04:14] jbowtie: the key problem at the moment is that the partial stream from the remote repository will almost never be in a wholly complete/consistent state, so bzr atm can't simply save the partially fetched revision data into the local repository. [04:14] jbowtie: note that bzr's streaming fetch does /one/ big transaction, so unless you're doing just-in-time conversion, you won't be actually resuming anything. [04:14] * spiv looks up the relevant bug [04:15] https://bugs.edge.launchpad.net/bzr/+bug/116148, and also https://bugs.edge.launchpad.net/bzr/+bug/125067 [04:15] Launchpad bug 116148 in Bazaar "bzr branch should be resumable if interrupted (affected: 4, heat: 10)" [Wishlist,Confirmed] [04:19] spiv: OK, at least its bzr and not my code. [04:19] What you can do is fetch smaller amounts, e.g. 1000 or even 100 revs at a time. [04:20] lifeless: Actually I'm converting a foreign repository, commits after each revision, so that should be all right. [04:21] Oh, 1 at a time works too :) [04:22] In that caes lifeless' first suggestion is good. [04:22] Oh, I actually missed that line. I'll see if that works. [04:25] That didn't work, mucked up the bookkeeping playing with bzr reconfigure I think. [04:25] But I'll try it if I lose the server connection again. === Ursinha is now known as Ursinha-afk [06:23] hi spiv [06:45] Hi poolie. I've made some progress on bug 653307, as perhaps you've seen in my comments to it. [06:45] Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 8)" [Critical,In progress] https://launchpad.net/bugs/653307 [06:46] I've got a simple 'bzr cross-check' tool now that compares the inventory roots agree for the common inventories of 2 or more repos. [06:46] It seems to be a similar kind of problem to bug 485601. [06:47] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601 [06:53] spiv: you need a test sucker? [06:56] * fullermd mentally pictures a giant squid with a clipboard... [06:56] peitschie: this is a different bug, not involving bzr-svn :) [06:57] peitschie: (but so far looks like a similar sort of cause in the relevant code that creates bzr branches out of deb packages) [07:03] spiv: I did see that on the description... I was thinking more that I have the two pure bzr repositories made from svn that exhibit the issue if you had any interest in the results to this check :) [07:21] hey spiv, that sounds good [08:06] hi all [08:08] bonjour vila! [08:08] _o/ [08:08] morning all. [08:10] * fullermd waves at vila. [08:12] 16:03 < vila> maxb: yeehaa for the beta-ppa ! [08:12] 16:05 < vila> maxb: does this mean the tests are running there ? For bzr only or did you try for some plugins too ? [08:12] 16:05 < vila> maxb: did you remove the install-related failing one ? [08:13] Tests work! bzr only. I caused it to skip, but it was only testing whether the install script would actually run, so that's valid - since the package build implicitly tests that anyway :-) [08:14] excellent work ! That's a significant stepping stone on the MRE road [08:15] So, how did you skip the test ? Unconditionally or based on source tree availability ? [08:16] It had existing code to skip based on the presence/absence of setup.py, but the code was dodgy - it tested presence in one directory, then tried to execute it in a different directory [08:17] So I fixed that [08:17] In the packaging branch only. Need to merge propose that [08:17] maxb: ok, can you put up... yeah :) Can you try to target 2.2 for it ? [08:18] Not 2.1? In case we want to SRU lucid? [08:18] I don't think we'll be able to run the tests successfully for 2.1 (or did I misremember ?) [08:18] maxb: but if you can target 2.1, that's better anyway [08:20] oh, alright [08:21] maxb: I mean, I'd be delighted to be able to run the tests for 2.1, but I prefer to focus on 2.2 and 2.3 [08:32] maxb: you may want to update bug #644015 [08:32] Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite (affected: 1, heat: 155)" [Undecided,Confirmed] https://launchpad.net/bugs/644015 [08:33] DerGuteMoritz: ah it is something in my code, could affect the gazette as well then [08:33] oops sorry === peitschie is now known as 5EXABLZH6 [10:00] Cause I don't really want spend the next 8 hours pulling revisions by hand when I already have 95% on disk. [10:00] jbowtie: still there ? If the local repo is sane, bzr won't pull the already present revisions [10:00] vila: Yes and sounds good. [10:01] jbowtie: bzr missing should tell you, but it can be a bit verbose... [10:09] No help in #emacs, so I'll ask here... [10:09] vila: Almost works, this is where some of the corner-cutting in my bzr-tfs plugin rears its ugly head. [10:09] anyone knows how to teach emacs that ReST comments are multi-line? [10:10] Not this vim user. ;) [10:10] ddaa: no idea [10:12] vila: Just implemented Transport.clone, looks like I now need to implement Branch.get_rev_id.... oh, well, next milestone was overdue anyway. [10:13] Thanks for the hints, will go away and hack for a bit until this works. [10:13] jbowtie: make sure your plug your transport into the test suite [10:13] jbowtie: that could reveal many subtle bugs there [10:14] vila: Yeah, it's probably far enough along now to make that worthwhile. [10:15] jbowtie: roughly you need a get_test_permutation function defined in your transport module [10:15] jbowtie: hmm, you also need a test server... that may be more complex :-/ [10:16] jbowtie: there is lp:bzr-local-test-server that can help use a real server under certain conditions though [10:16] vila: One of the reasons I've been putting it off. But I can mock it since it's all XML messages in the end. [10:16] ha [10:17] vila: Don't laugh, it's horribly painful even when it works. :) [10:17] jbowtie: not laughing at all, it was more a: 'Ha, hmm, yeah, not trivial' [10:18] vila: It's also why it's so slow in creating a repository. Anything I can do to make that more resumable is a big win. [11:02] Hello, I ve got a question about the "decentralised with shared mainline" workflow [11:03] the developer creates his own branch using bzr branch, regularly gets update to the mainline using bzr merge... [11:03] commits locally using bzr commit - but how can he push his changes back to the mainline? [11:03] it depends on who has write access to mainline [11:03] I cant seem to find how to do a bzr merge [11:04] basically you bzr push [11:04] the push wont overwrite changes made to the mainline by other users? [11:04] if there are changes which the destination doesn't have, the push will be rejected [11:05] hang on, i'm not explaining this well, lemme start again [11:05] ok I think I understand - user tries to push, fails because mainline has modifs the user doesnt have - so user needs to merge and push again? [11:06] yann2: thats correct - but with one caveat [11:06] push makes the destination a mirror of the source, so pushing could alter the order of the history slightly [11:06] the best approach is to have a direct mirror of the central branch locally [11:07] merge your feature branch into that, then push it back to central [11:07] you mean bzr pull instead of bzr branch? [11:08] ah you mean having two branches locally, one a direct mirror, and one a branch of that mirror... [11:08] yes [11:08] in order to merge to mainline, you have an exact mirror of mainline on local, and use that to merge and update mainline [11:09] so bzr pull to a local mirror, bzr branch from that mirror, bzr merge to the mirror and bzr push to sync the local mirror with the mainline? [11:09] where you bzr branch your feature branch from is unimportant, but yes [11:10] you can also use bzr checkout and bzr update to have your local mirror of mainline remain in sync [11:10] I got only one dev so will try without for now... but will definitely get back to this if we get more [11:10] afraid I might scare him otherwise :) [11:10] yeah, if you're not too worried about history order possibly changing, then just push [11:11] thanks for your help [11:18] how do I review a branch against mainline without merging it? [11:18] and preferably without making a copy of mainline and merging into that to do the diff [11:18] merge --preview, or (q)diff [11:19] bzr diff --old=path/to/mainline [11:20] Glenjamin: thanks [11:40] hi everyone, can I extract a subdirectory of a repo as a new repo with revision history intact? [11:45] aa_: you can use the bzr-fastimport plugin to export the history, and then filter it to only have the directory you want, and import that. [11:46] So the answer is: sort of. You can synthesise a new revision history that just contains the subdirectory. [11:46] spiv: ok, great, that sounds like what I meant anyway, a new history would need to eb generated I guess [11:46] spiv: thanks :) [11:47] Another option is you could also just make a commit that deletes everything except the subdirectory, and moves that subdirectory to the root of the tree. [11:48] spiv: ooh, didn't think of that [11:48] but then I have all the revision history too [11:48] Right. [11:48] So which you want depends on exactly what effect you want. [11:48] the first one [11:49] *nod* [14:16] Hello. Why is it so? $bzr revno lp:cuneiform-linux returns "491", but $bzr log -r491 returns "bzr: ERROR: Requested revision: u'491' does not exist in branch: BzrBranch7('file:///home/virus_found/abs/cuneiform/src/cuneiform-linux/')" [14:17] Do I need to pull/fetch/whatever it in order to see the log of 491 revision? [14:17] you don't need to pull, but you do need to specify the remote location if you want to read the remote location's log [14:18] Oh, thanks, I'll try. [14:18] something like $ bzr log -r491 lp:cuneiform-linux [14:18] np. [14:18] Thank you so much :) [14:18] Works. [14:19] not a problem. glad to have helped [14:19] :) === Ursinha-afk is now known as Ursinha [15:20] mgz: ping, do you have a wip about the transport hook ? [15:27] mgz: and did we have a bug for it ? [15:28] vila: not yet but it's down for today, and no. [15:29] I'm guessing branching off lp:~spiv/bzr/hooks-refactoring is the lower conflict path. [15:37] mgz: but you have a branch already no ? [15:38] nope. I read some background, but haven't had multiple uninterrupted hours till now. [15:39] (I do now have a branch, but really just now) [15:39] mgz: what did I try then ? Only a pastebin'd patch ? [15:40] oh, I'm not building on that one, it was just a hack branch to test the theory. [15:43] oh I know, I found it back [15:47] ah, sorry, I didn't realise you wanted it again, would have pasted the link [15:47] np, my question was vague anyway [15:51] okay, that's a hook stubbed out. [15:51] as a post connect hook is going to (potentially) be called multiple times per transport [15:51] accounting for reconnections [15:52] but disconnect is a once? per transport thing, what should the test code do with this new hook exactly? [16:00] okay, implemented. [16:01] working backwards though, now I need to work out what tests I need. [16:02] Is there an svn-fast-import (not export) ? === james_w` is now known as james_w [16:11] mgz: sry, wasn't paying attention. Hmm, yes, it could be called multiple times by transport but only once by connection (i.e. only if we need to reconnect) [16:12] awilkins: meh, may be the svn devs know better ? ;) [16:12] my code at the moment is just calling disconnect multiple times in this case and it seems to not blow up. [16:12] so I'll do that for the moment and people can think of better ways in review [16:13] Hmm, disconnect should be protected against multiple calls because a connection can be shared between several transports [16:14] mgz: yup, it is (at least the http one I'm looking at) [16:15] vila, The use case is ; I want to give a training course, splitting the participants into two groups, Group B gets Bazaar, Group S gets subversion [16:15] vila, Although silly me, I shall probably construct a repo in Bazaar and just push it into an SVN one [16:16] vila, Was just thinking that you could store course materials as fast-export and run it on any VCS [16:16] awilkins: things are often clearer when you need to explain them to someone other than.. yourself ;) [16:16] Also, groups B S... are you sure ? ;) [16:16] Bazaar and Subversion :-) [16:17] I might address group S first in any given location :-| [16:17] Oh, I got that, but some people have such perverse habits to deform everything the teachers say... [16:17] then always say them in the other order [16:17] "Groups S and B" [16:17] Anything that excites their neurones enough to keep them conscious [16:17] awilkins: good point [16:18] Not like I'm training nuns [16:18] Not habitually anyway. [16:19] fullermd: Dunno why I wsa thinking about you... so you finally managed to get noticed when someone thinks about you... explain why you can't sleep anymore ;) [16:19] Sleep? I've heard of that, I think... I thought it was just a rumor. [16:21] In the same tone, I will call my working copy folder "WC" [16:22] Although my course materials for this are usually sandwich recipes. Less hilarious. [16:23] sandwich recipes in working copy folders ? === zyga is now known as zyga-dinner [16:23] I think he's just trying to flush out all the bad puns. [16:24] It's something people can edit and merge without thinking about code ; has a list of steps and a list of ingredients people can disagree about, etc [16:24] Sometimes I have to give this kind of instruction to people who are not programmers [16:24] interesting, what format? [16:24] .txt [16:25] Glenjamin: triangle or baguette [16:25] Cut crosswise! Remove crusts! To toast, or not to toast, that is the question! [16:26] Wrong question. Corned beef or proscuitto? [16:26] nope, baguette ham butter, the ultimate [16:26] Corned beef or pastrami [16:26] Acceptable. As long as it's measured in pounds. [16:27] i cut mine like this: http://pastebin.com/Dr6cZ3BN [16:27] gherkin is a nice option [16:27] Trapezoid cut sandwiches ..... [16:27] * awilkins gathers some ideas for "libraries" [16:28] halfway between rectangles and triangles [16:31] * awilkins now has trapezoid, oblong, diagonal sandwich cut ASCII arts :-) [16:32] You get authors credit on the trapezoid one [16:34] okay, two crappy tests I've ripped off parth. [16:34] really this needs some higher level stuff checking that say, the http transport uses the hook [16:34] but might put up for review as is so I stay way ahead of schedual for the day === beuno is now known as beuno-lunch === zyga-dinner is now known as zyga [17:02] vila: mp posted. === deryck is now known as deryck[lunch] [17:22] mgz: reviewed and pre-requisites pinged [17:22] mgz: thanks ! [17:26] vila: thanks back! might be worth giving it a go on babune too to check it's as good as the hack on all tests, I only did a subset. [17:30] mgz: started [17:31] mgz: hmm, almost. Re-started [17:32] mgz: be aware that I upgraded a bunch of hosts today, so all failures may not be your fault ;) [17:32] :) === beuno-lunch is now known as beuno [17:57] mgz: doesn't look good: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-gentoo/lastCompletedBuild/testReport/ [17:58] cool, gives me a set of tests to check. [17:59] probably very shallow [17:59] and some of it at least is just me being dumb. [18:09] okay, the other part looks like a clash with transport_util [18:09] just updating that should do. [18:10] it's like... exactly the code I wrote but tests only. [18:14] mgz: which part ? [18:15] mgz: I'm almost off ;) But ping me later if you want a re-rerun, I'll pass around [18:15] the adding a hook in _set_connection bit. am just deleting code now to see how much of the rest is needed. [18:15] will do vila. [18:18] mgz: oooooh, I see, this probably can be rewritten better now, this is very very old code ;) [18:18] right. :) [18:18] I'm hoping for a delete-whole-file, just thinking through what the scheme replacing stuff is trying to do. [18:19] while this may shed some doubt about my memory, I think it re-enforce my coherency :) [18:19] the scheme replacing stuff is only there to get the right kind of transport because that was the only one with the right hook at the time [18:20] I'll try deleting it and seeing how many broken pieces I get. [18:20] but there is still the begining where ftp/sftp is selected for all kind of environments, *this* will be harder to delete and test [18:21] mgz: you don't have to address that yet IMHO, a big FIXME would be enough [18:22] that's a FIXME in extra large font? [18:22] roryy: yup, red and blinking [18:23] well, transport_util seems to only be used in those few tests that failed in babune, so I have hopes for moving any logic we still need somewhere closer to site [18:26] heya, is it possible to mark a (autogenerated) text file as binary in bzr so that it doesn't show up in diffs and so it gets different conflict resolution? or is that a stupid idea? [18:27] Is there a difference between bzr up and bzr pull? [18:28] MTecknology: Yes. That was easy :) [18:28] :P [18:28] thanks [18:29] * fullermd is a helper! [18:30] fullermd: indeed [18:30] For my next trick... === deryck[lunch] is now known as deryck [18:35] fullermd: You going to write a bzr plugin to do everything I'm doing? [18:35] Yes! [18:35] I think. [18:35] If that's code for "eat a sandwich and take a nap". [18:36] that doesn't sound like a plugin [18:36] the plugin i want... [18:36] What do you have against napping? [18:37] its probably the sandwich he objects to [18:37] is bzr xml output included by default in most packages? [18:37] I meant it doesn't sound like a bzr plugin [18:37] bzr create-new-server-configure-it-and-migrate-existing-site-in-one-layout-to-new-server-on-completely-different-setup [18:37] Hm. Well, I'm flexible; I'll go with cocktail shrimp if that's better... [18:37] ^ that's the bzr plugin you should make for me :D [18:38] sounds to me like you should configure your servers more uniformly :D [18:38] You wouldn't have this problem if all your stuff was in Teh Cloud! [18:38] 'cuz then you'd just, like, waft sites around, and it would all work perfectly with no effort and scale infinitely. Says so right here on the label. [18:39] In dev I need to fully lock off every website from every other website on the same system [18:40] when the dev site moves live it needs to change to a setup where it runs entirely different - designed for high caching and huge req/s [18:41] I use Makefiles (or their immoral equivalent) for that sorta thing. [18:42] I know makefiles are great for this, but I'm just using a bash script [18:42] and a python script [18:42] what language is the app? [18:42] ... and about 4 other python scripts [18:42] It's Pressflow [18:43] if you know python, i'd always use python scripts over bash [18:43] and generally spend your time developing a proper build/deploy script - deployment/building is the most important feature of any app [18:44] except in bash I can just say.. tar "$(grep ... | sed ..).tgz" "$root_dir$(grep ...)" [18:44] and no-one can read that [18:44] short != good [18:44] I had to learn python to do this actually [18:44] I never worked with python before [18:45] then you could have used php-cli [18:45] There's some pretty screwy things I need to do to make this work too [18:46] Oh, that's nothing. I spent a giant pile of time last weekend in the bowels of Apache and mod_rewrite. You wanna talk about some screwy things... [18:49] yucky [18:49] apache is too much like msft to me [18:49] anyway, i missed the start of this conversation, i don't actually know what the original problem was [18:49] apache is a known quantity, mostly :) [18:50] I've saved many people by moving to Linux because of the high system load Windows caused for older hardware [18:51] And also s/Linux/Ninx/ s/Windows/Apache/ [18:51] Glenjamin: my original problem.. I asked about bzr pull vs. bzr up - then the convo kinda digressed [18:51] ah yes [18:51] reminds me, does post-pull run after update? [19:03] vila: pushed some updates if babune can have another go at running the branch when you next pass this way [19:33] mgz: passing, noticed http://babune.ladeuil.net:24842/job/selftest-subset-maverick/9/testReport/bzrlib.tests.test_source/TestSource/test_coding_style/ [19:34] is it possible to do a bzr export to a remote server? [19:34] gra, need to watch my reindent [19:35] mgz: started a new one [19:35] or what bzr command should I use to deploy the latest version of a branch to a production server? [19:35] mgz: that's what you get for reporting an indent bug this morning ;) [19:35] yann2: lp:bzr-upload if you don't want to publish your history [19:36] I need a pre commit hook with some stuff, juggling editors means I always mess something whitespacey up. [19:36] yann2: lp:bzr-push-and-update if your want both the branch and the working tree on the remote server [19:36] I dont have such a command vila [19:36] yann2: there are plugins [19:36] they* [19:37] how do I install them? [19:37] I dont want the history so upload looks like it [19:37] yann2: that os/bzr versions are you using [19:37] ubuntu server 10.4 [19:37] 64bits if thats of interest [19:37] yann2: http://doc.bazaar.canonical.com/plugins/en/ [19:37] yann2: upgrade to 10.10 :-D [19:38] cant, just upgraded to 10.4 :) [19:38] ha no, server, LTS ? [19:38] yep, keeping all my servers lts [19:38] yann2: I suggest using the bzr ppa to get access to the latest stable release and plugins [19:38] https://itwiki.thehumanjourney.net/images/7/7f/Devworkflow.png trying to get this done [19:39] rats, upload is not part of the stable ppa [19:40] yann2: yup, typical use case for bzr-upload [19:40] * vila off [19:44] Well, we can add bzr-upload easily enough... :-) [19:44] Shall I do it right now? [19:45] it is packaged on 10.4 , I just checked :) [19:46] * maxb wonders if anything has changed between lucid and what's in sid [19:46] any idea how to access the man though? [19:47] ii bzr-upload 0.1.1+bzr60-1 Bazaar plugin for uploading to web servers [19:47] seems exactly like what I was looking for though ;) [19:47] yann2: Once installed: bzr upload --help [19:47] cheers [19:48] A fair number of fixes after revno 60 [19:57] maxb, what issues should I be aware of? [19:58] I like to stick to regular repos whenever possible, but if there are serious bugs of course I'll install a ppa [19:58] I don't use it myself, I just glanced at the commit logs [20:09] zazyPing2 [20:10] sigh [20:15] I get this error using bzr-upload if anyone has an idea: http://pastebin.ca/1962389 ... [20:20] as a general rule, i like having the remote deployments be a branch/checkout - it means you can be sure exactly what revision they are [20:26] Glenjamin, but then the .bzr archives would be accessible via http? [20:26] depends on your config [20:26] well even I'd like to keep that out of the vhost if I can [20:26] but right now I get nothing working :( [20:27] yann2: try sftp instead of bzr+ssh [20:27] that worked :) thanks a lot [20:28] jam: did you get the mail about lp-service failures? [20:29] jam: is it just that the acceptance tests are not starting a forking service? [20:29] mwhudson: that's what it looks like. I didn't see those tests when I was looking around [20:30] it seems "bin/test lp.codehosting" doesn't actually run the codehosting tests [20:30] (it runs *all* tests for some reason) [20:30] anyway, I'll fix it up, thanks for running it for me [20:30] jam: basically all the bzr+ssh tests failed and non of the others, so it's likely something fairly simple [20:30] jam: bin/test -t [20:30]