[00:01] <GungaDin> yes.
[00:01] <GungaDin> thx.
[01:38] <GungaDin> is there a special way to rename a branch in bzr?
[01:43] <LeoNerd> mv
[01:43] <LeoNerd> A branch doesn't need to know its own name.. it's simply a location, a directory path on disk
[01:45] <KombuchaKip> What is the difference between bzr pull and update commands?
[01:47] <fullermd> pull is for updating one branch relative to another.  update is for updating a working tree relative to its branch.
[01:47] <spiv> '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] <fullermd> (except for bound branches, which break the rules to keep you on your toes)
[01:48]  * KombuchaKip is confused
[01:49] <fullermd> My work here is done   :)
[01:49] <jbowtie> The way I remember it is:  bzr checkout, use bzr update; bzr branch, use bzr pull.
[01:49] <KombuchaKip> So in the centralized model, does it make a difference?
[01:52] <peitschie> KombuchaKip: in the centralized model, you are usually be using checkouts correct?
[01:52] <jbowtie> 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] <KombuchaKip> peitschie: Yes, I use typically a checkout first time.
[01:53] <peitschie> KombuchaKip: jbowtie beat me to it :).... so you'll be using update, not pull
[01:53] <KombuchaKip> peitschie: Ok, so I will just forget pull for now.
[01:54] <peitschie> KombuchaKip: yup :).  when to start treading into branching and such, then you can learn about pull/push/merge etc.
[01:55] <KombuchaKip> 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] <peitschie> 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] <KombuchaKip> peitschie: My main concern is compression and handling of large binary files.
[01:57] <KombuchaKip> 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] <peitschie> KombuchaKip: that does help.  What size binary files are you talking about out of interest?
[01:58] <KombuchaKip> On the order of tens of megs to possibly around a gigabyte.
[01:58] <KombuchaKip> peitschie: And they won't compress well, nor will deltas be computed likely efficiently.
[01:59] <peitschie> 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] <KombuchaKip> peitschie: I hope though that there is some attractive GUI for managing an apt repository that draws from Bazaar source.
[02:00] <KombuchaKip> peitschie: Well, to be fair, I don't know of any SCM that handles them well.
[02:00] <fullermd> I think that's the arena that Alienbrain targets.
[02:01] <peitschie> 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] <KombuchaKip> peitschie: Yes, I'll take a look.
[02:02]  * fullermd glances at the site.
[02:02] <fullermd> Oh, and alienbrain is highly portable; it works on both Windows AND MacOS!
[02:02] <peitschie> 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] <peitschie> lol... wow! both of them?
[02:03] <KombuchaKip> fullermd: lol ;) I only run GNU.
[02:03] <fullermd> In Africa, the GNU runs YOU!
[02:03] <KombuchaKip> 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] <KombuchaKip> fullermd: ;)
[02:04] <KombuchaKip> Hmm Alienbrain doesn't look like it's free.
[02:04] <fullermd> I think it's highly not.
[02:04] <peitschie> yes... it's so non-free my wallet would hurt from talking to it i think :(
[02:05] <KombuchaKip> 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] <peitschie> 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] <fullermd> Well, the needs of meda management and text file management are pretty divergant.
[02:06] <KombuchaKip> fullermd: Agreed.
[02:06] <fullermd> AB's biggest selling point is integration with all sorts of meda-type programs (photoshop, stuff from Avid, etc)
[02:07] <fullermd> Second to that is handling big files.  I mean *big*, multi-hundred-gig-plus, files.
[02:07] <peitschie>  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] <fullermd> bzr probably isn't going to target files that size any time soon  ;)
[02:07] <KombuchaKip> fullermd: I understand.
[02:07] <peitschie> hehe... for sure.... theres a lot of very specialised memory management stuff that needs to happen at that level
[02:08] <KombuchaKip> Thanks for everyone's help and advice. I'm going to go eat some avocados now.
[02:08] <jbowtie> Yeah, it would be great if we get the Unity3D people to talk about how they do asset management.
[02:09] <jbowtie> They've got some sort of homegrown VCS for managing all those ame assets.
[02:09] <jbowtie> *game assets
[02:09] <KombuchaKip> 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] <KombuchaKip> 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] <peitschie> rofl
[02:10] <peitschie> i never thought of it that way... my mind expands once again :-/
[02:11] <fullermd> Well, I know I've dealt with software that felt like it gave me salmonella before...
[02:11] <KombuchaKip> 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] <KombuchaKip> fullermd: Or diarrhoea.
[02:12] <peitschie> KombuchaKip: open source does tend to build the freshest binaries...
[02:12] <KombuchaKip> 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] <KombuchaKip> peitschie: That's right, organic too, and not sprayed with DRM.
[02:13] <peitschie> 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] <KombuchaKip> 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] <peitschie> KombuchaKip: an admirable aim for sure :)
[02:15] <KombuchaKip> peitschie: ;) Alright, dinner time.
[02:19] <KombuchaKip> By the way, what's the "Gateway to LAN" I see in the Bazaar preferences for? Sounds cool.
[03:55] <jbowtie> OK, here's a scenario. Decided to branch a large, slow repository. Connectivity is lost partway through.
[03:55] <jbowtie> So on disk I have most of a repository, no branch, no working tree.
[03:56] <jbowtie> 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] <jbowtie> Where do I start?  Somewhere in sprout?
[04:01] <jbowtie> Looks like what I want is BzrDir.open_branch(), followed by WorkingTreeFormat2.initialize(), followed by a bzr pull. Does that sound right?
[04:13] <lifeless> jbowtie: bzr checkout .; bzr pull
[04:13] <lifeless> ?
[04:14] <spiv> 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] <lifeless> 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] <spiv> https://bugs.edge.launchpad.net/bzr/+bug/116148, and also https://bugs.edge.launchpad.net/bzr/+bug/125067
[04:19] <jbowtie> spiv: OK, at least its bzr and not my code.
[04:19] <spiv> What you can do is fetch smaller amounts, e.g. 1000 or even 100 revs at a time.
[04:20] <jbowtie> lifeless: Actually I'm converting a foreign repository, commits after each revision, so that should be all right.
[04:21] <spiv> Oh, 1 at a time works too :)
[04:22] <spiv> In that caes lifeless' first suggestion is good.
[04:22] <jbowtie> Oh, I actually missed that line. I'll see if that works.
[04:25] <jbowtie> That didn't work, mucked up the bookkeeping playing with bzr reconfigure I think.
[04:25] <jbowtie> But I'll try it if I lose the server connection again.
[06:23] <poolie> hi spiv
[06:45] <spiv> Hi poolie.  I've made some progress on bug 653307, as perhaps you've seen in my comments to it.
[06:46] <spiv> 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] <spiv> It seems to be a similar kind of problem to bug 485601.
[06:53] <peitschie> spiv: you need a test sucker?
[06:56]  * fullermd mentally pictures a giant squid with a clipboard...
[06:56] <spiv> peitschie: this is a different bug, not involving bzr-svn :)
[06:57] <spiv> 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] <peitschie> 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] <poolie> hey spiv, that sounds good
[08:06] <vila> hi all
[08:08] <bialix> bonjour vila!
[08:08] <vila> _o/
[08:08] <mgz> morning all.
[08:10]  * fullermd waves at vila.
[08:12] <maxb> 16:03 < vila> maxb: yeehaa for the beta-ppa !
[08:12] <maxb> 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] <maxb> 16:05 < vila> maxb: did you remove the install-related failing one ?
[08:13] <maxb> 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] <vila> excellent work ! That's a significant stepping stone on the MRE road
[08:15] <vila> So, how did you skip the test ? Unconditionally or based on source tree availability ?
[08:16] <maxb> 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] <maxb> So I fixed that
[08:17] <maxb> In the packaging branch only. Need to merge propose that
[08:17] <vila> maxb: ok, can you put up... yeah :) Can you try to target 2.2 for it ?
[08:18] <maxb> Not 2.1? In case we want to SRU lucid?
[08:18] <vila> I don't think we'll be able to run the tests successfully for 2.1 (or did I misremember ?)
[08:18] <vila> maxb: but if you can target 2.1, that's better anyway
[08:20] <maxb> oh, alright
[08:21] <vila> 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] <vila> maxb: you may want to update bug #644015
[08:33] <C-Keen> DerGuteMoritz: ah it is something in my code, could affect the gazette as well then
[08:33] <C-Keen> oops sorry
[10:00] <jbowtie> Cause I don't really want spend the next 8 hours pulling revisions by hand when I already have 95% on disk.
[10:00] <vila> jbowtie: still there ? If the local repo is sane, bzr won't pull the already present revisions
[10:00] <jbowtie> vila: Yes and sounds good.
[10:01] <vila> jbowtie: bzr missing should tell you, but it can be a bit verbose...
[10:09] <ddaa> No help in #emacs, so I'll ask here...
[10:09] <jbowtie> vila: Almost works, this is where some of the corner-cutting in my bzr-tfs plugin rears its ugly head.
[10:09] <ddaa> anyone knows how to teach emacs that ReST comments are multi-line?
[10:10] <jbowtie> Not this vim user.  ;)
[10:10] <vila> ddaa: no idea
[10:12] <jbowtie> 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] <jbowtie> Thanks for the hints, will go away and hack for a bit until this works.
[10:13] <vila> jbowtie: make sure your plug your transport into the test suite
[10:13] <vila> jbowtie: that could reveal many subtle bugs there
[10:14] <jbowtie> vila: Yeah, it's probably far enough along now to make that worthwhile.
[10:15] <vila> jbowtie: roughly you need a get_test_permutation function defined in your transport module
[10:15] <vila> jbowtie: hmm, you also need a test server... that may be more complex :-/
[10:16] <vila> jbowtie: there is lp:bzr-local-test-server that can help use a real server under certain conditions though
[10:16] <jbowtie> 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] <vila> ha
[10:17] <jbowtie> vila: Don't laugh, it's horribly painful even when it works.  :)
[10:17] <vila> jbowtie: not laughing at all, it was more a: 'Ha, hmm, yeah, not trivial'
[10:18] <jbowtie> 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] <yann2> Hello, I ve got a question about the "decentralised with shared mainline" workflow
[11:03] <yann2> the developer creates his own branch using bzr branch, regularly gets update to the mainline using bzr merge...
[11:03] <yann2> commits locally using bzr commit - but how can he push his changes back to the mainline?
[11:03] <Glenjamin> it depends on who has write access to mainline
[11:03] <yann2> I cant seem to find how to do a bzr merge <dest>
[11:04] <Glenjamin> basically you bzr push <dest>
[11:04] <yann2> the push wont overwrite changes made to the mainline by other users?
[11:04] <Glenjamin> if there are changes which the destination doesn't have, the push will be rejected
[11:05] <Glenjamin> hang on, i'm not explaining this well, lemme start again
[11:05] <yann2> 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] <Glenjamin> yann2: thats correct - but with one caveat
[11:06] <Glenjamin> push makes the destination a mirror of the source, so pushing could alter the order of the history slightly
[11:06] <Glenjamin> the best approach is to have a direct mirror of the central branch locally
[11:07] <Glenjamin> merge your feature branch into that, then push it back to central
[11:07] <yann2> you mean bzr pull instead of bzr branch?
[11:08] <yann2> ah you mean having two branches locally, one a direct mirror, and one a branch of that mirror...
[11:08] <Glenjamin> yes
[11:08] <Glenjamin> 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] <yann2> 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] <Glenjamin> where you bzr branch your feature branch from is unimportant, but yes
[11:10] <Glenjamin> you can also use bzr checkout and bzr update to have your local mirror of mainline remain in sync
[11:10] <yann2> I got only one dev so will try without for now... but will definitely get back to this if we get more
[11:10] <yann2> afraid I might scare him otherwise :)
[11:10] <Glenjamin> yeah, if you're not too worried about history order possibly changing, then just push
[11:11] <yann2> thanks for your help
[11:18] <elmo> how do I review a branch against mainline without merging it?
[11:18] <elmo> and preferably without making a copy of mainline and merging into that to do the diff
[11:18] <Glenjamin> merge --preview, or (q)diff
[11:19] <Glenjamin> bzr diff --old=path/to/mainline
[11:20] <elmo> Glenjamin: thanks
[11:40] <aa_> hi everyone, can I extract a subdirectory of a repo as a new repo with revision history intact?
[11:45] <spiv> 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] <spiv> So the answer is: sort of.  You can synthesise a new revision history that just contains the subdirectory.
[11:46] <aa_> spiv: ok, great, that sounds like what I meant anyway, a new history would need to eb generated I guess
[11:46] <aa_> spiv: thanks :)
[11:47] <spiv> 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] <aa_> spiv: ooh, didn't think of that
[11:48] <aa_> but then I have all the revision history too
[11:48] <spiv> Right.
[11:48] <spiv> So which you want depends on exactly what effect you want.
[11:48] <aa_> the first one
[11:49] <spiv> *nod*
[14:16] <virus_found> 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] <virus_found> Do I need to pull/fetch/whatever it in order to see the log of 491 revision?
[14:17] <rubbs> 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] <virus_found> Oh, thanks, I'll try.
[14:18] <rubbs> something like $ bzr log -r491 lp:cuneiform-linux
[14:18] <rubbs> np.
[14:18] <virus_found> Thank you so much :)
[14:18] <virus_found> Works.
[14:19] <rubbs> not a problem. glad to have helped
[14:19] <virus_found> :)
[15:20] <vila> mgz: ping, do you have a wip about the transport hook ?
[15:27] <vila> mgz: and did we have a bug for it ?
[15:28] <mgz> vila: not yet but it's down for today, and no.
[15:29] <mgz> I'm guessing branching off lp:~spiv/bzr/hooks-refactoring is the lower conflict path.
[15:37] <vila> mgz: but you have a branch already no ?
[15:38] <mgz> nope. I read some background, but haven't had multiple uninterrupted hours till now.
[15:39] <mgz> (I do now have a branch, but really just now)
[15:39] <vila> mgz: what did I try then ? Only a pastebin'd patch ?
[15:40] <mgz> oh, I'm not building on that one, it was just a hack branch to test the theory.
[15:43] <vila> oh I know, I found it back
[15:47] <mgz> ah, sorry, I didn't realise you wanted it again, would have pasted the link
[15:47] <vila> np, my question was vague anyway
[15:51] <mgz> okay, that's a hook stubbed out.
[15:51] <mgz> as a post connect hook is going to (potentially) be called multiple times per transport
[15:51] <mgz> accounting for reconnections
[15:52] <mgz> but disconnect is a once? per transport thing, what should the test code do with this new hook exactly?
[16:00] <mgz> okay, implemented.
[16:01] <mgz> working backwards though, now I need to work out what tests I need.
[16:02] <awilkins> Is there an svn-fast-import (not export) ?
[16:11] <vila> 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] <vila> awilkins: meh, may be the svn devs know better ? ;)
[16:12] <mgz> my code at the moment is just calling disconnect multiple times in this case and it seems to not blow up.
[16:12] <mgz> so I'll do that for the moment and people can think of better ways in review
[16:13] <vila> Hmm, disconnect should be protected against multiple calls because a connection can be shared between several transports
[16:14] <vila> mgz: yup, it is (at least the http one I'm looking at)
[16:15] <awilkins> 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] <awilkins> vila, Although silly me, I shall probably construct a repo in Bazaar and just push it into an SVN one
[16:16] <awilkins> vila, Was just thinking that you could store course materials as fast-export and run it on any VCS
[16:16] <vila> awilkins: things are often clearer when you need to explain them to someone other than.. yourself ;)
[16:16] <vila> Also, groups B S... are you sure ? ;)
[16:16] <awilkins> Bazaar and Subversion :-)
[16:17] <awilkins> I might address group S first in any given location :-|
[16:17] <vila> Oh, I got that, but some people have such perverse habits to deform everything the teachers say...
[16:17] <Glenjamin> then always say them in the other order
[16:17] <Glenjamin> "Groups S and B"
[16:17] <awilkins> Anything that excites their neurones enough to keep them conscious
[16:17] <vila> awilkins: good point
[16:18] <awilkins> Not like I'm training nuns
[16:18] <fullermd> Not habitually anyway.
[16:19] <vila> 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] <fullermd> Sleep?  I've heard of that, I think...    I thought it was just a rumor.
[16:21] <awilkins> In the same tone, I will call my working copy folder "WC"
[16:22] <awilkins> Although my course materials for this are usually sandwich recipes. Less hilarious.
[16:23] <vila> sandwich recipes in working copy folders ?
[16:23] <fullermd> I think he's just trying to flush out all the bad puns.
[16:24] <awilkins> 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] <awilkins> Sometimes I have to give this kind of instruction to people who are not programmers
[16:24] <Glenjamin> interesting, what format?
[16:24] <awilkins> .txt
[16:25] <vila> Glenjamin: triangle or baguette
[16:25] <awilkins> Cut crosswise! Remove crusts! To toast, or not to toast, that is the question!
[16:26] <fullermd> Wrong question.  Corned beef or proscuitto?
[16:26] <vila> nope, baguette ham butter, the ultimate
[16:26] <awilkins> Corned beef or pastrami
[16:26] <fullermd> Acceptable.  As long as it's measured in pounds.
[16:27] <Glenjamin> i cut mine like this: http://pastebin.com/Dr6cZ3BN
[16:27] <vila> gherkin is a nice option
[16:27] <awilkins> Trapezoid cut sandwiches .....
[16:27]  * awilkins gathers some ideas for "libraries"
[16:28] <Glenjamin> halfway between rectangles and triangles
[16:31]  * awilkins now has trapezoid, oblong, diagonal sandwich cut ASCII arts :-)
[16:32] <awilkins> You get authors credit on the trapezoid one
[16:34] <mgz> okay, two crappy tests I've ripped off parth.
[16:34] <mgz> really this needs some higher level stuff checking that say, the http transport uses the hook
[16:34] <mgz> but might put up for review as is so I stay way ahead of schedual for the day
[17:02] <mgz> vila: mp posted.
[17:22] <vila> mgz: reviewed and pre-requisites pinged
[17:22] <vila> mgz: thanks !
[17:26] <mgz> 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] <vila> mgz: started
[17:31] <vila> mgz: hmm, almost. Re-started
[17:32] <vila> mgz: be aware that I upgraded a bunch of hosts today, so all failures may not be your fault ;)
[17:32] <mgz> :)
[17:57] <vila> mgz: doesn't look good: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-gentoo/lastCompletedBuild/testReport/
[17:58] <mgz> cool, gives me a set of tests to check.
[17:59] <vila> probably very shallow
[17:59] <mgz> and some of it at least is just me being dumb.
[18:09] <mgz> okay, the other part looks like a clash with transport_util
[18:09] <mgz> just updating that should do.
[18:10] <mgz> it's like... exactly the code I wrote but tests only.
[18:14] <vila> mgz: which part ?
[18:15] <vila> mgz: I'm almost off ;) But ping me later if you want a re-rerun, I'll pass around
[18:15] <mgz> the adding a hook in _set_connection bit. am just deleting code now to see how much of the rest is needed.
[18:15] <mgz> will do vila.
[18:18] <vila> mgz: oooooh, I see, this probably can be rewritten better now, this is very very old code ;)
[18:18] <mgz> right. :)
[18:18] <mgz> I'm hoping for a delete-whole-file, just thinking through what the scheme replacing stuff is trying to do.
[18:19] <vila> while this may shed some doubt about my memory, I think it re-enforce my coherency :)
[18:19] <vila> 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] <mgz> I'll try deleting it and seeing how many broken pieces I get.
[18:20] <vila> 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] <vila> mgz: you don't have to address that yet IMHO, a big FIXME would be enough
[18:22] <roryy> that's a FIXME in extra large font?
[18:22] <vila> roryy: yup, red and blinking
[18:23] <mgz> 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] <sidnei> 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] <MTecknology> Is there a difference between bzr up and bzr pull?
[18:28] <fullermd> MTecknology: Yes.  That was easy   :)
[18:28] <MTecknology> :P
[18:28] <MTecknology> thanks
[18:29]  * fullermd is a helper!
[18:30] <MTecknology> fullermd: indeed
[18:30] <fullermd> For my next trick...
[18:35] <MTecknology> fullermd: You going to write a bzr plugin to do everything I'm doing?
[18:35] <fullermd> Yes!
[18:35] <fullermd> I think.
[18:35] <fullermd> If that's code for "eat a sandwich and take a nap".
[18:36] <MTecknology> that doesn't sound like a plugin
[18:36] <MTecknology> the plugin i want...
[18:36] <fullermd> What do you have against napping?
[18:37] <Glenjamin> its probably the sandwich he objects to
[18:37] <Glenjamin> is bzr xml output included by default in most packages?
[18:37] <MTecknology> I meant it doesn't sound like a bzr plugin
[18:37] <MTecknology> bzr create-new-server-configure-it-and-migrate-existing-site-in-one-layout-to-new-server-on-completely-different-setup
[18:37] <fullermd> Hm.  Well, I'm flexible; I'll go with cocktail shrimp if that's better...
[18:37] <MTecknology> ^ that's the bzr plugin you should make for me :D
[18:38] <Glenjamin> sounds to me like you should configure your servers more uniformly :D
[18:38] <fullermd> You wouldn't have this problem if all your stuff was in Teh Cloud!
[18:38] <fullermd> '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] <MTecknology> In dev I need to fully lock off every website from every other website on the same system
[18:40] <MTecknology> 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] <fullermd> I use Makefiles (or their immoral equivalent) for that sorta thing.
[18:42] <MTecknology> I know makefiles are great for this, but I'm just using a bash script
[18:42] <MTecknology> and a python script
[18:42] <Glenjamin> what language is the app?
[18:42] <MTecknology> ... and about 4 other python scripts
[18:42] <MTecknology> It's Pressflow
[18:43] <Glenjamin> if you know python, i'd always use python scripts over bash
[18:43] <Glenjamin> and generally spend your time developing a proper build/deploy script - deployment/building is the most important feature of any app
[18:44] <MTecknology> except in bash I can just say.. tar "$(grep ... | sed ..).tgz" "$root_dir$(grep ...)"
[18:44] <Glenjamin> and no-one can read that
[18:44] <Glenjamin> short != good
[18:44] <MTecknology> I had to learn python to do this actually
[18:44] <MTecknology> I never worked with python before
[18:45] <Glenjamin> then you could have used php-cli
[18:45] <MTecknology> There's some pretty screwy things I need to do to make this work too
[18:46] <fullermd> 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] <MTecknology> yucky
[18:49] <MTecknology> apache is too much like msft to me
[18:49] <Glenjamin> anyway, i missed the start of this conversation, i don't actually know what the original problem was
[18:49] <Glenjamin> apache is a known quantity, mostly :)
[18:50] <MTecknology> I've saved many people by moving to Linux because of the high system load Windows caused for older hardware
[18:51] <MTecknology> And also s/Linux/Ninx/ s/Windows/Apache/
[18:51] <MTecknology> Glenjamin: my original problem.. I asked about bzr pull vs. bzr up - then the convo kinda digressed
[18:51] <Glenjamin> ah yes
[18:51] <Glenjamin> reminds me, does post-pull run after update?
[19:03] <mgz> vila: pushed some updates if babune can have another go at running the branch when you next pass this way
[19:33] <vila> mgz: passing, noticed http://babune.ladeuil.net:24842/job/selftest-subset-maverick/9/testReport/bzrlib.tests.test_source/TestSource/test_coding_style/
[19:34] <yann2> is it possible to do a bzr export to a remote server?
[19:34] <mgz> gra, need to watch my reindent
[19:35] <vila> mgz: started a new one
[19:35] <yann2> or what bzr command should I use to deploy the latest version of a branch to a production server?
[19:35] <vila> mgz: that's what you get for reporting an indent bug this morning ;)
[19:35] <vila> yann2: lp:bzr-upload if you don't want to publish your history
[19:36] <mgz> I need a pre commit hook with some stuff, juggling editors means I always mess something whitespacey up.
[19:36] <vila> yann2: lp:bzr-push-and-update if your want both the branch and the working tree on the remote server
[19:36] <yann2> I dont have such a command vila
[19:36] <vila> yann2: there are plugins
[19:36] <vila> they*
[19:37] <yann2> how do I install them?
[19:37] <yann2> I dont want the history so upload looks like it
[19:37] <vila> yann2: that os/bzr versions are you using
[19:37] <yann2> ubuntu server 10.4
[19:37] <yann2> 64bits if thats of interest
[19:37] <vila> yann2: http://doc.bazaar.canonical.com/plugins/en/
[19:37] <vila> yann2: upgrade to 10.10 :-D
[19:38] <yann2> cant, just upgraded to 10.4 :)
[19:38] <vila> ha no, server, LTS ?
[19:38] <yann2> yep, keeping all my servers lts
[19:38] <vila> yann2: I suggest using the bzr ppa to get access to the latest stable release and plugins
[19:38] <yann2> https://itwiki.thehumanjourney.net/images/7/7f/Devworkflow.png trying to get this done
[19:39] <vila> rats, upload is not part of the stable ppa
[19:40] <vila> yann2: yup, typical use case for bzr-upload
[19:40]  * vila off
[19:44] <maxb> Well, we can add bzr-upload easily enough... :-)
[19:44] <maxb> Shall I do it right now?
[19:45] <yann2> 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] <yann2> any idea how to access the man though?
[19:47] <yann2> ii  bzr-upload                0.1.1+bzr60-1             Bazaar plugin for uploading to web servers
[19:47] <yann2> seems exactly like what I was looking for though ;)
[19:47] <GaryvdM> yann2:  Once installed: bzr upload --help
[19:47] <yann2> cheers
[19:48] <maxb> A fair number of fixes after revno 60
[19:57] <yann2> maxb, what issues should I be aware of?
[19:58] <yann2> I like to stick to regular repos whenever possible, but if there are serious bugs of course I'll install a ppa
[19:58] <maxb> I don't use it myself, I just glanced at the commit logs
[20:09] <GaryvdM> zazyPing2
[20:10] <GaryvdM> sigh
[20:15] <yann2> I get this error using bzr-upload if anyone has an idea: http://pastebin.ca/1962389 ...
[20:20] <Glenjamin> 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] <yann2> Glenjamin, but then the .bzr archives would be accessible via http?
[20:26] <Glenjamin> depends on your config
[20:26] <yann2> well even I'd like to keep that out of the vhost if I can
[20:26] <yann2> but right now  I get nothing working :(
[20:27] <Glenjamin> yann2: try sftp instead of bzr+ssh
[20:27] <yann2> that worked :) thanks a lot
[20:28] <mwhudson> jam: did you get the mail about lp-service failures?
[20:29] <mwhudson> jam: is it just that the acceptance tests are not starting a forking service?
[20:29] <jam> mwhudson: that's what it looks like. I didn't see those tests when I was looking around
[20:30] <jam> it seems "bin/test lp.codehosting" doesn't actually run the codehosting tests
[20:30] <jam> (it runs *all* tests for some reason)
[20:30] <jam> anyway, I'll fix it up, thanks for running it for me
[20:30] <mwhudson> jam: basically all the bzr+ssh tests failed and non of the others, so it's likely something fairly simple
[20:30] <lifeless> jam: bin/test -t <pattern>
[20:30] <mwhudson> jam: that sounds strange
[20:30] <mwhudson> lifeless: should work without the -t though
[20:31] <lifeless> zope.testrunner is extremely idiosyncratic
[20:31] <jam> lifeless: that *loads* all tests and then runs a subset
[20:31] <jam> which is ok, but slow
[20:31] <mwhudson> then the pattern just matches the module path
[20:31] <lifeless> jam: yes, but it works :)
[20:31] <mwhudson> of course, you should _always_ have -vv in there
[20:31] <jam> bin/test lp.codehosting.sshserver runs the subset I thought I cared about :)
[20:32] <mwhudson> sadly not
[20:40] <mwhudson> jam: you ok to make the required changes?
[20:40] <mwhudson> oh, you already said that
[20:50] <eross> how do I check something out without having to be a contributer - eg.  not entering a pass phrase
[20:50] <lifeless> use an anonymous protocol like http
[20:53] <jam> mwhudson: I'll let you know if I can't figure out how to get the service running, but I'm hoping it will be fairly straightforward
[20:54] <mwhudson> jam: yeah, it shouldn't be too bad, there's code to manange the ssh server process, you'll just need to make it manage the forking service too
[20:57] <jam> mwhudson: at this point, I should be updating against launchpad/devel, correct?
[20:57] <mwhudson> jam: yep
[20:59] <GaryvdM> jam: Out of interest, have you ever worked with python amd64 on windows?
[21:00] <jam> GaryvdM: nope, I've never had 64-bit windows (ever)
[21:00] <Glenjamin> i ran it briefly once, 3rd party lib support was poor, and 32-bit mode was fine
[21:01] <eross> ty
[21:01] <GaryvdM> jam, Glenjamin: Cause Iq
[21:02] <GaryvdM> jam, Glenjamin: Cause I'm trying to do an amd64 python installer, and I'm finding what Glenjamin said.
[21:02] <Glenjamin> I last tried it 2-3 years ago
[21:03] <Glenjamin> dissapointing it hasn't improved since :s
[21:03] <Glenjamin> but in general, windows x64 has transparent support for all 32 bit apps, and hopefully bzr isn't using more than 3.4gig of memory
[21:04] <GaryvdM> e.g. no 64 installer for setuptools, but found on from 3rd party.
[21:05] <jam> Glenjamin: well, you can only get access to 2GB of memory unless you run special flags, and then you can only get 3GB
[21:05] <jam> (both boot-time flag /3G and the program needs a bit toggled to say that it is high-bit safe)
[21:05] <Glenjamin> heh, that'll teach me to be vauge in a tech-related channel :D
[21:07] <jam> I just looked into it very closely in the past for other work
[21:07] <jam> as when you have a 4GB machine, it is a shame that you can't actually use it in a single process
[21:07] <jam> also, if you are allocating *large* chunks of memory
[21:08] <Glenjamin> anyway, my point was that if you're trying to run bazaar in 64 bit python, you're probably savvy enough to go build it yourself
[21:08] <jam> the cap is often like 1.3GB because of fragmentation due to how windows maps shared libraries into your process space
[21:08] <jam> Glenjamin: well, we were hoping to build an installer for people, so that they wouldn't have to be savvy enough to install it themselves
[21:08] <Glenjamin> oh i see
[21:09] <Glenjamin> as a windows 64 user, i'd say ~50 of my apps run in 32bit mode, and there are no issues with this
[21:09] <jam> Glenjamin: I would also say that memory consumption usually doubles in python 64-bit, since almost everything is a 'long' or a pointer
[21:09] <jam> so while you have access to more, suddenly you consume a lot more too
[21:10] <Glenjamin> a quick survey shows: 40/83 processes running in 64-bit mode
[21:10] <jam> Glenjamin: and the other 43 are all system processes, right ? :)
[21:11] <Glenjamin> hrm
[21:11] <Glenjamin> 4 non-system 64-bit processes
[21:13] <Glenjamin> so yeah - i'd expect windows users to be happy with a 32-bit installer. unless 64-bit turns out to be simple (which i doubt)
[21:14] <jam> Glenjamin: people are currently complaining because of running OOM with large files and enough mem to handle them otherwise
[21:14] <Glenjamin> oh
[21:14] <jam> not *many* people, but enough that we're trying
[21:14] <jam> at least to give them the option
[21:15] <Glenjamin> well i'm happy to test out the installer if you want
[21:15] <GaryvdM> Glenjamin: thanks, watch this space.
[21:18] <Glenjamin> do you guys know of a version control tool that can version inside of archives?
[21:20] <Glenjamin> for example, docx is just a compressed set of mostly xml files - in theory a VCS could apply this knowledge to intelligently merge word documents
[21:20] <dash> Glenjamin: that would require knowing how to intelligently merge xml files :)
[21:20] <Glenjamin> haha
[21:28] <poolie> hello jam
[21:28] <jam> hi poolie, shocking to see you here so early
[21:29] <vila> jam, poolie: ouch, I should really go then ;)
[21:29] <jam> sleep well, vila
[21:29] <vila> hehe, soon, soon
[21:30] <poolie> heh, yeah, sleep well
[21:30] <poolie> hi jam, i'm trying to migraet towards your timezone
[21:30] <poolie> i'm actually fairly often on 30-60m after this
[21:31] <vila> poolie: I just noticed that my mps about bug #323111 were first posted more than a month ago, I will go to sleep and dream that they'll get reviewed enough for me to fix them so that we can land them :-D
[21:33] <poolie> that would be nice
[22:10] <poolie> jam, how are you?
[22:12] <jam> poolie: doing pretty good. there were some failing "acceptance" tests because we weren't starting the extra service there, I'm tracking that down now
[22:13] <poolie> oh ok
[22:13] <jam> not sure why mailman is repeatedly failing to import
[22:13] <jam> while running codehosting tests
[22:13] <poolie> ah, i think i've seen failures there too
[22:13] <poolie> trying to load something that looked like it might be auto generated?
[22:13] <poolie> mailman_path.py?
[22:13] <poolie> something like that?
[22:14] <jam> "no module named mailman.monkeypatches.lpmoderate"
[22:16] <poolie> mm i saw that too; you could ask on the lp list i guess
[22:25] <poolie> is bzr rebase included in the windows installer?
[22:25] <poolie> re https://answers.edge.launchpad.net/bzr/+question/129467
[22:25] <poolie> s//rewrite
[22:26] <Glenjamin> rebase in the message implies its not up to date?
[22:30] <jam> poolie: rebase was renamed to 'rewrite' and the new installer installs the new one, but doesn't delete the old one
[22:30] <jam> known bug, I believe it is attributed to bzr-windows-installers
[22:34] <Glenjamin> Are there any plans to put xmloutput in core? I've run into a few things lately where tools are parsing the normal log output (since they usually copy the svn implementation and tweak it). It'd be nice to be able to rely on xml being available
[22:36] <maxb> Is there any convention to log messages for bzr - wrap at 80 characters, vs. one linebreak per notional paragraph?
[22:36] <maxb> s/convention/recommendation/ I guess
[22:42] <poolie> wrap before 80, like in code
[22:43] <poolie> Glenjamin: i'd be happy to see it in core if you would like to put up a merge proposal
[22:44] <peitschie> mornin all :)
[22:45] <maxb> Did I do something wrong with https://code.edge.launchpad.net/~maxb/bzr/2.1-test_setup-skip-properly/+merge/38465 - why is it listing a PQM revision under "Unmerged revisions" ?
[22:47] <jam> maxb: because you started at bzr/2.1 and targeted bzr
[22:47] <jam> and that specific revision hasn't propagated up eet
[22:47] <jam> yet
[22:47] <jam> did you mean to target lp:bzr/2.1 ?
[22:47] <jam> (The branch name would hint at that)
[22:47] <maxb> urgh
[22:48] <maxb> I entered ~bzr-pqm/bzr/2.1 in the form. I guess the radio button must have been wrong
[22:48] <jam> maxb: it is possible that entering text doesn't update the radio button
[22:48] <jam> IIRC I filed a bug on that a long time ago
[22:48] <jam> for a different form, though
[22:49] <maxb> right, reproposed properly this time :-)
[22:50] <jelmer> maxb: Did you see my updated meta-lp-deps mp?
[22:50] <maxb> I did. And then I forgot about it. Oops :-)
[22:55] <jam> mwhudson: got the failing tests to run, now to fix... oops EOD
[22:56] <mwhudson> jam: ok
[22:56] <jam> the one good thing is that while waiting for the test suite to run, it gives me time to work on bzr code
[22:56] <mwhudson> jam: i'll subscribe to the branch and look to see for stuff tomorrow morning
[23:56] <spiv> Hooray hard disk failure :/