[00:09] <lifeless> spiv: ping
[00:17] <spiv> lifeless: pong
[00:21] <lifeless> when you were working on the missing keys stuff
[00:22] <lifeless> did you happen to also have methods to get 'all the new revision ids' or something like that?
[00:23] <lifeless> I'm making StreamSink do a pack()
[00:23] <lifeless> but providing only the revision ids to pack
[00:23] <lifeless> alternatively, I could make it pack with some opaque hint about the pack names to use, which commit_write_group could be modified to return
[00:23] <lifeless> I'm still undecided.
[00:25] <spiv> I did, I can't remember if that method ended up landing or ditched, though...
[00:27] <lifeless> telling you about this I've realised a race with my current approach
[00:27] <lifeless> so I am now decided, the hint has to be opaque and list the pack names.
[00:28] <spiv> I either didn't have that method, or I had it and abandoned it in favour or something else (_KnitGraphIndex's track_external_parent_refs flag, maybe?)
[00:28] <lifeless> spiv: well, I don't want refs, I want something to id the packs themselves
[00:28] <spiv> Yeah, I prefer the sound of that approach anyway.
[00:28] <spiv> Right, it doesn't help for this.
[00:33] <SamB> jelmer: is there a bzr-svn equivalent for "svnversion"?
[00:35] <AfC> SamB: http://blogs.operationaldynamics.com/andrew/software/version-control/subversion-revision.html
[00:42] <poolie> hello all
[01:04] <poolie> jml: https://edge.launchpad.net/bzr/+milestone/2.0
[01:04] <poolie> it still shows a few bugs
[01:04] <poolie> how many are actually critical i don't know
[01:06] <lifeless> FWIW I haven't attempted to categorise all the critical bugs as blockers/not blockers at this point
[01:08] <jml> lifeless, as in, there are some bugs on 2.0 marked 'critical' that might not be blockers?
[01:08] <lifeless> no
[01:09] <lifeless> as in there are bugs marked critical that might be blockers for 2.0, but not set against the milestone
[01:09]  * SamB wonders how many GHC releases are going to go by with that critical bug in the typesystem ...
[01:09] <lifeless> using milestones to plan releases is a new experiment for us
[01:09] <jml> ahh ok.
[01:10] <jml> https://bugs.edge.launchpad.net/bzr/+bug/389272 ; https://bugs.edge.launchpad.net/bzr/+bug/376243 and https://bugs.edge.launchpad.net/bzr/+bug/365615 are the only ones I could find like that.
[01:10] <lifeless> for regular releases I think we shouldn't ever really have bugs open against the milestone
[01:10] <lifeless> 2.0 is special
[01:11] <jml> lifeless, aiui, 2.0 is special because we need some way of deciding when to change the naming convention of one of our regular releases.
[01:12] <lifeless> its special because people percieve .0 releases differently
[01:12] <lifeless> ugh spellink
[01:13] <SamB> 2.0 is special because it comes after 1.n
[01:14] <lifeless> SamB: so does 1.n+1 :)
[01:14] <SamB> well, I mean, you don't even have to know what "n" is before you start planning for 2.0
[01:14] <lifeless> sure :P
[01:15] <SamB> or alternatively, you have to pick an n
[01:15] <lifeless> what I mean though, is that people will make more of an effort to upgrade; that we are likely to be changing the default for 2.0, that rich roots will get much more exposure.
[01:15] <lifeless> we're going to _drive_ exposure of all the little issues in the system that are currently an optional experience
[01:15] <igc> morning all
[01:18] <lifeless> so 2.0 is more a readiness test than 'another month has passed'
[01:30] <jml> igc, good morning
[01:34] <fullermd> Speaking of 2.0, which we weren't, I'd like to suggest we remove the 'clone' alias for it...
[01:35] <fullermd> That would give it time to get out of circulation and cut down on surprise when we re-used it in 3.0 for cloning multi-branch repos...
[01:36] <lifeless> fullermd: put a patch up
[01:37] <lifeless> fullermd: I'm ambivalent; I think you're prematurely judging what the ui changes will be. OTOH clone is the source of some confusion today.
[01:38] <fullermd> Well, I am.  OTOH, it's an excellent word for it, matches 'git clone', and probably should be de-made a copy of 'branch' ASAP if it's ever going to come into usage meaning something rather different, so...
[01:39] <fullermd> I'll try banging something together for the list later; wouldn't want to bother if I could just hop on IRC and get told "WTF, no".
[01:39] <lifeless> I mean; specifically, we have multibranch repos today
[01:39] <lifeless> theres no real need to have the deep problems fixed to make the change you want today
[01:40] <lifeless> clone URL could just clone the entire structure today
[01:40] <lifeless> the things I'm interested in for 3.0 are removing the sand grains
[01:40] <fullermd> Would you prefer I said "git style branches"?   :p
[01:41] <lifeless> if you said that, I'd feel even more like you're prejudging
[01:41] <fullermd> Anyway, my rush wasn't so much the changes, as that moving clone instantly from being an alias for 'branch' to being a totally different command is unpleasant, and it'd be better to give it a while of being nothing in the middle, to get people away from it.
[01:42] <lifeless> I think we'll have to change much more than simply clone to do 3.0 :) If you want to do this work on clone, its fine with me.
[01:43]  * fullermd thinks you're reading a LOT more into this...
[01:43] <lifeless> could be ;)
[01:44] <fullermd> All I'm saying is "Hey, I think this is a command we'll want to use for XYZ in the future, we should stop making it mean ABC ASAP"
[01:44] <fullermd> That was we have all 2.x for people to start using 'bzr branch' instead of 'bzr clone', so they're not unpleasantly surprised out of the blue when it changes.
[01:44] <lifeless> All I'm saying is 'using it for XYZ isn't clear to me, and perhaps using it for ABC will still be appropriate. But hey, it causes confusing on ABC at the moment so changing it might be good anyway'
[01:45] <lifeless> fullermd: w.r.t. avoiding confusion, I'm fairly sure 'bzr branch' will change *too*, so I'm not buying the avoiding-of-surprise.
[01:46] <fullermd> Well, but I expect branch will always pretty much mean 'make a new branch based on X', give or take.  So it wouldn't be a conceptual shift, just syntax and details.
[01:46] <fullermd> Oh well.  I'll try starting a bikesh^Wthread on it later.
[01:47] <SamB> fullermd: that'll still screw scripts
[01:47] <SamB> you know the one nice thing about that concept?
[01:48] <SamB> ... at least those nuclear power plants only give you trouble in *making* them
[01:48] <fullermd> I was hoping it would lead to wealth and women, actually.  Oh well, back to the drawing board.
[02:10] <poolie> lifeless: so, how about upgrading bzr on launchpad?
[02:10] <poolie> good morning spiv, igc
[02:10] <lifeless> poolie: the LOSAs are all in the UK this week
[02:10] <lifeless> poolie: I don't think we should do anything risky until spm is at hand again
[02:11] <poolie> next monday?
[02:11] <lifeless> also, as we have a wide variety of users, we should really plan it carefully and socialise dates etc
[02:11] <poolie> do you know what they're doing? some kind of sprint?
[02:11] <poolie> sure
[02:11] <poolie> i'm not proposing to just run the command
[02:11] <poolie> i'm proposing to start that process though
[02:11] <lifeless> by bzr on launchpad, do you mean 'change format to 2a' ?
[02:12] <igc> hi poolie
[02:12] <poolie> yes
[02:12] <poolie> hello igc
[02:51] <igc> after a busy weekend hacking from bialix and igc, BzrExplorer hits the streets
[02:52]  * igc lunch and medical appointment - bbl
[04:49] <tedg> Uhm, bad stuff just happened.  I did a commit on a repository that had about 1900 revisions and it now said "commiting rev 1" which is scary.
[04:50] <tedg> But doing a "bzr log" I can see that all the old revisions are there, but now my log has negative revisions in it.
[04:50] <bialix> run `bzr reconcile`
[04:52] <tedg> bialix: Thanks, running now.
[04:55] <lifeless> reconcile won't fix that
[04:56] <lifeless> there is a bug open about doing 'bzr init + bzr merge + bzr commit' doing this
[04:56] <lifeless> but we've not seen anything else cause it.
[04:56] <lifeless> tedg: please file a bug about how you made this happen. use your bash history and ~/.bzr.log as data for what you did to make it happen
[04:57] <tedg> lifeless: I think it's because I had a commit waiting on another operation using a lock file.
[04:57] <tedg> I'm not sure if that'll show up in the log or not.
[04:57] <lifeless> if so its a huge bug
[04:58] <lifeless> gather as much data as you can
[04:58] <lifeless> file a bug
[04:58] <lifeless> try to reproduce
[04:58]  * tedg is still waiting on reconcile...
[04:59] <bialix> igc: I've made tar.gz and installer and upload them
[05:17] <bialix> igc1: hi
[05:17] <igc1> hi bialix!
[05:17] <bialix> hi!
[05:17] <bialix> I've upload release tarball and installer
[05:17] <igc1> I'm just looking for them now
[05:17] <bialix> do you want to provide the links for these files at wiki?
[05:18] <bialix> https://launchpad.net/bzr-explorer/trunk/0.3
[05:18] <igc1> yes please
[05:18] <bialix> https://launchpad.net/bzr-explorer/+download
[05:18] <igc1> I'll update the main overview page on lp too
[05:19] <bialix> igc1: there: http://bazaar-vcs.org/BzrExplorer ?
[05:20] <bialix> or made additiona page http://bazaar-vcs.org/BzrExplorer/Download
[05:22] <igc1> bialix: just updating the main page is good enough for now I think
[05:23] <tedg> Wow, reconcile is taking forever.  Do I want to know what it's doing?  30m of CPU time for bazaar at this point.
[05:23] <bialix> added link to https://launchpad.net/bzr-explorer/+download
[05:25] <bialix> igc1: btw, I've tried to hook in double click event handler for wt view, and failed. I'm not sure why
[05:26] <bialix> I'm not expert in Qt :-/
[05:26] <igc1> bialix: thanks for trying. My naive attempt at it failed as well, hence my email to garyvdm
[05:26] <bialix> I suspect it's related to QDirModel
[05:31] <bialix> igc1: I don't see the way to edit hats
[05:32] <lifeless> tedg: reconcile won't help you
[05:32] <lifeless> tedg: you don't need to run it for the problem you had
[05:33] <bialix> thanks for your sample with bookmarks/tags, it looks interesting
[05:33] <tedg> lifeless: Yes, but canceling in the middle seems like a bad idea, eh?
[05:33] <lifeless> ctrl-C
[05:33] <bialix> lifeless: IIRC spiv added code to fix wrong revno
[05:33] <tedg> lifeless: s/life/fear/
[05:33]  * tedg is more scared of bazaar than that :)
[05:34] <lifeless> bialix: I don't see anything to do that in log
[05:35] <lifeless> tedg: bzr is designed to be as robust as possible
[05:35] <lifeless> ctrl-C shouldn't ever be more risky than using it over the internet.
[05:37]  * tedg is going to have to stop using bazaar over the Internet.
[05:37] <tedg> :)
[05:37] <poolie> lifeless, mwh, jml, thumper, i filed bug 390502 re upgrading to 2a
[05:38] <lifeless> poolie: ah, so that was what you meant :)
[05:38] <mwhudson> cool
[05:38] <tedg> lifeless: Hah, well, whether I'm crazy or not.  Even running reconcile for that amount of time fixed my revno
[05:38] <poolie> addition/comments/etc welcome
[05:38] <lifeless> tedg: very odd :P
[05:38] <mwhudson> let us know if we can help, but doing it without losas around will be a pain i expect
[05:38] <thumper> :)
[05:38] <lifeless> bialix: jam did change reconcile, but didn't put it in a commit message.
[05:39] <poolie> are they have a sprint or something?
[05:39] <lifeless> bialix: thanks for letting me know of that
[05:39] <poolie> apparently yes
[05:39] <lifeless> yes, LOSA sprint
[05:39] <poolie> i see the mail now
[05:40] <bialix> lifeless: I remember discussion on it
[05:41] <tedg> Okay, I've documented everything in bug 390490 -- I'm not sure what the status should be now.  Thanks lifeless and bialix!
[05:53] <Peng_> Should other related projects upgrade to 2a too? Several (bzr-svn, bzrtools, Loggerhead) already use rich roots, making it a lot easier.
[05:53] <lifeless> their devs should be dogfooding locally already
[05:53] <lifeless> moving mainline forces all devs to be using 1.16
[05:53] <lifeless> thats somewhat more reasonable for bzr itself
[05:53] <Peng_> FWIW, I have a copy of Loggerhead in 2a -- https://code.edge.launchpad.net/~mnordhoff/+junk/trunk.2a
[05:54] <Peng_> Heh, I'm not dogfooding 2a locally. :D
[05:54] <Peng_> Converting between packs/btrees and 2a on every push and pull would be slow, no?
[05:55] <fullermd> I've got a 2a branch, that I don't use of code that's maintained in CVS  ;)
[05:55] <Peng_> Heh.
[05:56] <Peng_> Does stacking, say, a 1.9-rich-root branch on a 2a branch work?
[05:57] <jml> I haven't tried :)
[05:58] <Peng_> I think I've heard bad things about stacking and differing serializer formats.
[05:58] <Peng_> I don't use stacking at all (well, except for LP's mirrors of my branches), but...
[05:58] <fullermd> Well, bzr.dev still has the nested trees issue keeping it from upgrade'ing on that route.
[05:59] <fullermd> I was GONNA say 1.16 will do it, but so far it's burned about a minute and a half of CPU trying to upgrade a repo with no revisions...
[05:59] <lifeless> poolie: no
[05:59] <lifeless> you can't stack across formats
[06:00] <Peng_> What about minor format changes, like 1.6 to 1.9?
[06:00] <lifeless> I'd need to check. We don't support it even if it happens to work
[06:00] <lifeless> :)
[06:01] <fullermd> Whoah, that's wacked out...
[06:01]  * fullermd files a bug.
[06:01] <lifeless> jml: I have had a merge proposal I sent it get ignored, or something
[06:02] <lifeless> jml: what should I do
[06:03] <Peng_> Back to my other question, does converting between rich-root-pack or 1.9-rich-root and 2a on every push and pull cause significant performance problems?
[06:03] <Peng_> I suppose I should just test it myself.
[06:03] <lifeless> its probably terrible at the moment
[06:03] <lifeless> there are two bugs open
[06:05] <Peng_> That would make dogfooding 2a on one's own a bad idea, then.
[06:06] <jml> lifeless, is it this bug? https://bugs.edge.launchpad.net/launchpad-code/+bug/387683
[06:07] <lifeless> no
[06:07] <lifeless> I've just sent a bug mail for it in fact
[06:07] <lifeless> well, I say no, but what I mean is, the summary makes me think no.
[06:09] <lifeless> jml: no, its nt
[06:09] <lifeless> jml: I had a branch created, absent the correct metadata, absent the merge proposals revisions
[06:09] <lifeless> poolie: I think we should wait to move bzr for launchpad to be able to upgrade our branches
[06:10] <lifeless> poolie: [even if 'upgrade our branches means a LOSA for-script']
[06:17] <jml> lifeless, I'm reminded that there is a known bug such that errors during merge proposal creation are not reported.
[06:19] <lifeless> jml: once you've gathered any data you need, I'll push and manually submit for merge
[06:20] <jml> lifeless, I'm not going to do any data gathering on that today, sorry.
[06:21] <lifeless> jml: tomorrow morning?
[06:22] <lifeless> poolie: so you object to the class name in my branch?
[06:24] <jml> lifeless, I'd just push it and manually submit it if I were you.
[06:24] <jml> lifeless, https://bugs.edge.launchpad.net/launchpad-code/+bug/376204
[06:24] <jml> lifeless, that's probably the bug you are seeing. I'll be able to do more when I get the oops report tomorrow
[06:24] <jml> assuming I am at leisure to look at the bug.
[07:01] <poolie> lifeless: i do object to the class name
[07:01] <poolie> i think you should fix it
[07:01] <poolie> lifeless: you mean wait for launchpad rather than, for argument's sake, doing the upgrades over sftp?
[07:01] <poolie> fair enough
[07:02] <poolie> now to escape from bug mail
[07:02] <lifeless> poolie: ok, I'll change it. FWIW I chose it deliberately for more clarity in the class
[07:02] <lifeless> but I'm not deeply attached
[07:04] <poolie> the thing is it doesn't *mean* apha
[07:04] <poolie> alpha*
[07:04] <poolie> therefore it's not more clear
[07:04] <lifeless> well
[07:04] <lifeless> I'm confused by what it means then
[07:04] <poolie> it is the first 2-series format
[07:05] <poolie> i know i owe bzr a doc patch on this
[07:05] <poolie> but there was a thread about it
[07:05] <lifeless> will the next be 2b rather than e,g. 2.3?
[07:05] <poolie> yes
[07:05]  * lifeless is apparently totally confused
[07:05] <poolie> the point is:
[07:05] <poolie> it's hard to tell whether a format will change on disk between alpha testing and final release
[07:06] <poolie> and it's hard to tell precisely which release it will land in
[07:06] <poolie> and it's hard to tell which will be "the" format for 2.0
[07:07] <poolie> therefore, let's not put them into the symbol that names the on disk format
[07:07] <lifeless> if we get into this, I'll be wasting your time I think. So lets not. I'll re-read the thread and see if I can understand this time around. Because we put them into the on disk format to solve other issues
[07:07] <lifeless> and we didn't have any difficulty with the first two points for the last 3 or so formats before 2a
[07:07] <poolie> i'll try to finish things currently in train and then do a doc patch
[07:07] <poolie> and we can discuss it there
[07:08] <lifeless> I think not putting it into the disk format is a mistake, and if I failed to make that clear earlier, I'm really sorry.
[07:09] <poolie> putting what in?
[07:10] <lifeless> lets pause the conversation. I'll dig up the thread; it may be totally convincing.
[07:15] <abentley> lifeless: Any idea how long it takes to reconcile a launchpad repository in 0.2a?  I started on Friday, and it's still going...
[07:19] <fullermd> poolie: I don't understand "what does dev do specifically?"
[07:19] <lifeless> abentley: uhm, a while.
[07:19] <lifeless> abentley: is it thrashing?
[07:20] <lifeless> poolie: what was the thread name?
[07:20] <abentley> lifeless: load average is ~1.4, 1 CPU core is maxed.
[07:21] <lifeless> abentley: thats longer than I would have expected
[07:21] <abentley> Yeah, me too.
[07:21] <abentley> lifeless: It also has some old bzrs in it, but still...
[07:23] <abentley> It's spinning the spinner, fwiw.
[07:23] <abentley> But it's been in "Reconciling repository:repacking texts:Finding text refe" since Friday.
[07:26] <vila> hi all
[07:27]  * fullermd waves at vila.
[07:27]  * vila waves back 
[07:32] <AfC> abentley: Maybe `bzr reconcile` is subject to a Red Giant Bug :)
[07:57] <lifeless> igc1: I can work on iter_changes tomorrow
[08:00] <igc1> lifeless: cool
[08:00] <igc1> hi vila!
[08:00] <vila> igc1: hi Ian !
[08:01] <lifeless> hi vila
[08:01] <vila> lifeless: hi Rob ;-D
[08:02]  * lifeless EOD's
[08:26] <bialix> igc1: we have broken release
[08:27] <igc1> bialix: I'm just about to pack it in for the day
[08:27] <igc1> bialix : is it osmething you need me for?
[08:27] <igc1> or it is installer packaging, say?
[08:27] <bialix> no, I'm fixing it right now and will release 0.3.1
[08:28] <igc1> cool
[08:28] <bialix> no, this is broken sources
[08:28] <bialix> delete all pyc/pyo files from your sources and try to run bzr explorer
[08:28] <bialix> https://bugs.launchpad.net/bzr-explorer/+bug/390539
[08:29] <bialix> option --app-suite broken
[08:29] <igc1> oops - sorry
[08:29] <igc1> the registry is in app_suite now iirc
[08:30] <bialix> yes, I've chenged it
[08:30] <igc1> bialix: btw, I fixed that hat selection bug and applied a fix for bookmark editing on osx
[08:31] <bialix> yes, I saw
[08:31] <bialix> so, 0.3.1?
[08:32] <igc1> bialix: yep. Please do it ASAP - rev 100 (including your profile fix)
[08:32] <bialix> ok
[08:32] <igc1> bialix: I need to go
[08:32] <bialix> bye
[08:33]  * igc1 heads off to celebrate a good news day with the family - cancer all gone it seems. Hooray!
[08:33] <igc1> night all
[08:35] <bialix> !!!
[09:07] <guilhembi> Hello! my colleagues asks this:
[09:07] <guilhembi> "Anyone knows whether it is possible to copy a file or parts of its contents to another file and still preserve the history of the copied lines?
[09:07] <guilhembi> The problem is that i need to copy some large code over to a new file and i would like to preserve the history of those lines. "
[09:07] <guilhembi> and I believe the answer is "no".
[09:07] <mwhudson> you're right
[09:12] <vila> guilhembi: your're right, the answer is no. It's a planned feature, long term though.
[09:21] <guilhembi> vila: thanks
[09:22] <fullermd> Heck, you don't need to preserve the history, you can just guess at it later.  Ask any git person.
[09:23] <vila> fullermd: joke aside, that's the reason why I often comments in commit messages about such transitions ('start implementing X based on Y')
[09:23] <vila> s/comments/put comments/
[09:24] <vila> I started doing that back in sccs days, less so now (most of my use cases were renames which are now tracked ;-)
[09:25] <fullermd> That would take up precious space in the commit logs I could be using to mock and belittle the client, other developers, or myself...
[09:25] <vila> think about it as mocking the tools instead :-D
[09:26] <fullermd> Oh, heck no.  I'm far too animistic to dare mocking the tools I'm currently using.  They would TOTALLY find a way to get back at me for it.
[09:27]  * vila lol (sometimes that acronym can be used in its true original meaning :)
[09:30] <fullermd> vila: Can you take a look over the patch I just posted to the list?  It's kinda in your line.
[09:31] <poolie> hello vila
[09:31] <vila> hi poolie
[09:31] <poolie> vila thanks for the emacs comment on the ui branch
[09:32] <vila> poolie: np, thanks for working on that, I really like the design and I thought you could use some feedback from contexts you don't use on a regular basis
[09:33] <Peng_> fullermd: Oh, thanks for the patch. I ran into the bug once, but it didn't annoy me enough to track it down. :P
[09:33] <vila> fullermd: I can't believe it, I was so sure to have used '_unused' myself, looks like some modifications forgotten on my laptop when switching back to my desktop :-/
[09:34] <fullermd> poolie: I don't understand your comment on bug 390512...
[09:34] <poolie> yeah it madde me think of some more tests to add
[09:34] <poolie> about your point of allowing the user to turn off guessing?
[09:34] <poolie> fullermd: iirc you said "it fails in bzr'dev"
[09:34] <poolie> so does it fail with a traceback?
[09:35] <fullermd> Oh.  No, bzr.dev still has bug 388727 around, so it doesn't even try to do anything.
[09:35] <fullermd> It was a note that you have to use 1.16 to reproduce the bug.
[09:36]  * fullermd adds a comment.
[09:37] <vila> fullermd: by the way, can you use --parallel now ? I've lost track on that.
[09:38] <fullermd> vila: --parallel wants the testtools module, which I don't have an available package for   :|
[09:39] <poolie> fullermd: but i thought bug 388727 was now merged?
[09:39] <vila> fullermd: ha yes, thanks for the reminding, sorry about that again :-/ I think it's a python-only module, I know zilch about packaging but it shouldn't be hard :-/
[09:39] <fullermd> A fix was merged for 1.16.  AIUI, it's a somewhat hacky fix and lacks tests, which is why it wasn't put into bzr.dev.
[09:40] <vila> wow, 1.16 hasn't been merged back to bzr.dev ?
[09:40] <fullermd> vila: Yeah, but, see, if I made a package for it, some yutz would decide to stick me with maintaining it from now on   :p
[09:41] <vila> fullermd: yup, I think it's kinda part of deal for using a faster selftest, the time you gain from the faster executions can be used more productively now, see ?
[09:43] <Peng_> Packages are no fun! bzr branch lp:testtools /usr/local/lib/python2.5/site-packages/ :D
[09:43] <Peng_> Or co --lightweight, I guess.
[09:44] <fullermd> Having maintained installations with lifespans over a decade, I feel I can authoritatively say that fiddling around in /usr/local/ behind the package manager's back is *REALLY* no fun  ;p
[09:46] <jml> Peng_: I think someone's going to package testtools rsn.
[09:46] <vila> fullermd: whereas maintaining local version in ~/lib is quite usable :-)
[09:46] <fullermd> Anyway, longer single-thread selftest just means I have more time for reading web com^W^W^Wimportant research.
[09:49] <Peng_> Running parallel selftest on my VPS is fun. Swaps a bit, but it's fast.
[09:50] <Peng_> 'Course, The EC2 thing would be even faster. :D
[09:50] <vila> Peng: swaps ! Urgh, I'm surprised it's still faster then...
[09:52] <fullermd> Ah, swapping isn't slow if you arrange it right.  Gotta put swap on its own disk so it doesn't interfere with anything else, see.  I've got this 5 meg drive in the closet I can dedicate to things like that...
[09:52] <Peng_> vila: It's not that bad. Puts me maybe 20-100 MB over my total amount of RAM.
[09:52] <lifeless> also you don't have ext3 to contend with
[09:52] <lifeless> or do you?
[09:52]  * Peng_ 's VPS is on ext3, with swap on the same hard drives. :D
[09:53] <vila> Peng: How much RAM does the running system have and how many concurrent selftest are spawned ?
[09:54] <Peng_> vila: How much total RAM?
[09:54] <lifeless> Peng_: are the drives real?
[09:54] <Peng_> lifeless: They exist only in my dreams. No, uh, it goes through Xen, and LVM, depending on how that works, and they're in a RAID 1 (or maybe 10) array.
[09:55] <Peng_> vila: 360 MB total, about 140 MB actively used (more if Loggerhead is feeling hungry), and 4 processes.
[09:55] <Peng_> Hardware RAID, though.
[09:55] <lifeless> Peng_: so, they are vg's in LVM? or xen disk files?
[09:55] <vila> Peng: wow, that's tiny
[09:56] <Peng_> lifeless: Noo clue.
[09:56] <lifeless> :)
[09:56] <Peng_> lifeless: Heck, I don't even know what that question means. :D
[09:56] <Peng_> vila: Yeah, I'm cheap. :P
[09:58] <Peng_> Hmm, if they were just Xen disk files, using LVM would be pointless, no?
[09:58] <fullermd> Oh, I can't `missing` a merge directive?   :(
[09:59] <Peng_> vila: Could be tinier. 6 years ago, it would've been 64 MB. :D
[10:00] <fullermd> Yeah, but 6 years ago bzr used WAY less memory  :>
[10:01] <Peng_> Yes, things that don't exist don't tend to be RAM-heavy.
[10:02] <Peng_> 6 years ago the test suite was REALLY fast, too. :D
[10:02] <fullermd> Yeah, it didn't have any failures either.
[10:03] <Peng_> "bash: bzr: command not found" doesn't exactly sound like a success.
[10:03] <poolie> vila/mwh: do you have any opinion what SilentUIFactory should do if asked for input?
[10:03] <poolie> fail? or read random stuff from stdin?
[10:03] <poolie> the second doesn't seem really helpful
[10:03] <fullermd> Peng_: It's not bzr's fault bash has errors   :p
[10:03] <Peng_> If bzr+http uses SilentUIFactory, reading random crap from stdin sounds dangerous.
[10:03] <vila> from memory, SIlentUIFactory returns None which leaves upper levels decide right ?
[10:04] <Peng_> Err, wait, bzr+http uses stdin anyway. So it'd just break stuff, or do nothing.
[10:05] <poolie> run as a cgi i guess it does
[10:05] <LarstiQ> does anybody know where johnf hangs out?
[10:05] <poolie> i think it did previously read stdin which suggests that path was never hit
[10:05] <poolie> LarstiQ: on irc but not here? not really
[10:06] <poolie> he lives in Sydeny
[10:06] <poolie> Sydney
[10:06] <LarstiQ> poolie: he pinged me over the weekend
[10:08] <vila> poolie: yeah, looking at the code, I don't see how it can be used if input is needed... on the other hand making it *fail* can be useful for scripts that want to ensure no input is required
[10:08] <poolie> Sydney
[10:08] <poolie> blah
[10:08] <poolie> i mean, "yes"
[10:09] <vila> poolie: it's a bit strange it doesn't define get_boolean though
[10:09] <poolie> it inherits from CLIUIFactory
[10:09] <vila> poolie: hmm, get_boolean doesn't seem to be able to return None as currently coded
[10:10] <poolie> i'm deleting that layer too
[10:10] <poolie> i don't think it's useful anymore to make a static distinction between smart and dumb terminals
[10:10] <poolie> because it's actually more than one dimension:
[10:10] <poolie> does the user want progress, is there a tty for input, is there a tty for output, etc
[10:12] <vila> agreed
[10:14] <vila> poolie: quick question: do you know why _btree_serializer_c.pyx is not called _btree_serializer_pyx.pyx ?
[10:15] <poolie> vila, i was just wondering the same thing myself!
[10:15] <poolie> afaik it's an accident
[10:15] <poolie> vila, could you merge 1.16 to trunk sometime?
[10:15] <vila> poolie: sure
[10:16] <Peng_> bzrlib/_dirstate_helpers_c.pyx and bzrlib/_knit_load_data_c.pyx too.
[10:17] <vila> Peng: right
[10:22] <mwhudson> poolie: fail
[10:24] <Peng_> fail?
[10:28] <poolie> mwhudson: win! thanks
[10:28] <Peng_> lifeless: LVM.
[10:41] <awilkins> jelmer: Just ran into something interesting : I did `bzr version` and got prompted for auth on an SVN repo
[10:41] <awilkins> jelmer: bzr 1.14.1 bzr-svn 0.5.4
[10:42] <awilkins> It's not even a URI I recognize it's prompting for
[10:44] <mbnoimi> what the different between Bazaar and Subversion ?
[10:45] <awilkins> mbnoimi: Subversion uses a single central repository ; Bazaar permits you to use distributed repositories
[10:45] <awilkins> That's the most significant difference
[10:46] <mbnoimi> what about the pull/push speed ?
[10:46] <jpds> mbnoimi: http://bazaar-vcs.org/BzrVsSvn
[10:46] <mbnoimi> is bzr faster than svn?
[10:46] <awilkins> mbnoimi: For many use-cases, yes
[10:46] <awilkins> mbnoimi: And I'd say the critical one is merging easse
[10:47] <awilkins> mbnoimi: It makes certain ways of working cost much less than using subversion so they become more viable, like per-feature or per-bugfix branches
[10:47] <LenzGr> mbnoimi: The good thing is that switching from svn to bzr is painless and the commandline interface is very svn-like.
[10:47] <mbnoimi> awilkins: I got
[10:47] <mbnoimi> I got it
[10:48] <awilkins> You make a disk-space saving on many trees, and commands like status commands are in my experience a lot faster, as are checkouts
[10:48] <awilkins> (as long as the revision data is already downloaded or present on a LAN)
[10:48] <mbnoimi> but I couldn't find any shell integration for bzr on ubuntu where there are many shell integrations for svn
[10:49] <awilkins> mbnoimi: On win32 there is TortoiseBZR, which is not by any meaasure as mature as TortoiseSVN
[10:49] <mbnoimi> awilkins: I know it, I need one for ubuntu/Linux
[10:49] <awilkins> On Ubuntu.. I think there is a nautilus plugin but I think it's quite slow because of the way GVFS works
[10:50] <LenzGr> mbnoimi: Try qbzr or the bzr-gtk plugin, if you need a GUI
[10:50] <awilkins> mbnoimi: And if you are an eclipse user, there are a couple of plugins for that
[10:50] <fullermd> Don't forget the Explorer thing that was just released...
[10:50] <mbnoimi> LenzGr: they are not shell integrations !
[10:50] <jpds> mbnoimi: What do you mean by 'shell integration'?
[10:50]  * awilkins has not treid that thing yet
[10:50] <LenzGr> mbnoimi: On my zsh, bzr commands expand nicely.
[10:50] <LenzGr> (If that's what you are referring to)
[10:51] <awilkins> He means GUI file manager integration
[10:51] <mbnoimi> jpds: just like TortoiseSVN (right click)
[10:51] <mbnoimi> awilkins: could you give me a link?
[10:52] <mbnoimi> awilkins: I googled about it but I couldn't find anything
[10:52] <awilkins> mbnoimi: nautilus-bzr is part of bzr-gtk
[10:53] <awilkins> Apparently
[10:53] <awilkins> http://bazaar-vcs.org/bzr-gtk
[10:53] <awilkins> The "Bazaar Explorer" thing sounds nice too
[10:55] <mbnoimi> awilkins: I've installed bzr-gtk but I didn't notice any thing in nautilus
[10:55] <mbnoimi> awilkins: even I looked in apt and I found nothing !
[10:55] <awilkins> mbnoimi: Do you have the GNOME Python bindings installed?
[10:57] <mbnoimi> awilkins: I didn't see it in Synaptic ?
[10:57] <mbnoimi> awilkins: so I'm not sure if it's installed
[10:57] <awilkins> You want python-gnome2-desktop
[10:58] <mbnoimi> awilkins: yes, I got it. It installed
[11:00] <mbnoimi> awilkins: how I can be sure that nautilus-bzr is working correctly ? From my side I didn't see any action in right menu in nautilus
[11:00] <awilkins> Neither do I ; I'm not sure how you configure it
[11:01] <mbnoimi> awilkins: I just installed bzr-gtk from Synaptic nothing else
[11:04] <awilkins> I'm afraid I don't know then ; I'm usually content to use the CLI and spawn qbzr windows from the command line when I need some GUI lovin'
[11:05] <mbnoimi> awilkins: anyway thanks for help, I'll migrate my repos from SVN to bzr today
[11:06] <awilkins> mbnoimi: I use it in parallel with the SVN repos at work successfully
[11:06] <awilkins> mbnoimi: It's hard to change peoples habits with version control ; even when you're the guy who migrated them to SVN in the first place..../
[11:08] <fullermd> awilkins: Well, once they've seen you push svn on them, why _would_ they ever listen to you again?   ;>
[11:08] <awilkins> fullermd: In fairness, this was before Bazaar was in version numbers mod 1
[11:09] <awilkins> fullermd: And they'd spent 2 years deliberating on whether to use CVS or Visual SourceSafe
[11:09] <mbnoimi> before leaving, in SVN I can specify access rules of svn repos by editing passwd & authz files. In bzr I couldn't find any document talking about access rules, could you tell me how I can specifying that rules?
[11:09] <awilkins> fullermd: :-p
[11:09] <awilkins> mbnoimi: There are no access rules except access to full tree
[11:10] <awilkins> mbnoimi: Bazaar itself has no access rules, you configure access to the transports you use
[11:10] <awilkins> mbnoimi: It's a bit silly to try and restrict access to subtrees in a VCS where everyone has a copy of the whole repository
[11:10] <mbnoimi> hummm, but I want to make some folders just for read only and the others forbidden
[11:11] <awilkins> mbnoimi: Aside from breaking those folders into seperate branches, can't be done
[11:12] <fullermd> Oh, you could probably do something with a pre_commit hook on the "central" branch to prevent undesirables from being responsible for changes to given areas.
[11:12] <mbnoimi> awilkins: we're programing team in a commercial company so there are many access rules needed
[11:12] <fullermd> But there's nothing you could do about what they do in their own local branches.  They're root there, after all.
[11:14] <mbnoimi> fullermd: that's mean bzr not suitable for commercial usage !
[11:15] <fullermd> Not necessarily, it just means you have to think about things differently than you do in svn.
[11:15] <mbnoimi> fullermd: access rules are very important in our case
[11:15] <fullermd> Don't think about the access rules you have now; think about what you're trying to _accomplish_ with those access rules.
[11:16] <fullermd> For instance, you have sections of the tree that are read-only [for certain users].
[11:16] <fullermd> Now, how are you preventing them from changing those files locally in their svn checkout (but not committing the changes)?
[11:17] <fullermd> The answer almost certainly is "you're not, you can't, that's ridiculous".  What you're actually trying to do is not prevent them _changing_ the files, but prevent them _checking in_ changes to the files.
[11:17] <mbnoimi> fullermd: I can preventing them from committing , that's it
[11:17] <fullermd> So a hook on the "central" server saying "only these people can check in/merge/etc revisions that change these files" accomplishes the same thing.
[11:18] <fullermd> You can't assuredly  do anything about them committing changes there in their local branches, but that's equivalent to them making local changes in their svn checkouts; it doesn't affect anybody but them.
[11:18]  * fullermd sprinkles a few more pronouns into that sentence, just to make his English teachers twitch.
[11:20] <fullermd> (I'm somewhat sure pre_commit hooks could currently do that.  If they can't, it's probably a bug, and they should be able to.)
[11:24] <jelmer_> awilkins: you need a newer version of bzr-svn
[11:24] <jelmer_> SamB: 'bzr version-info'
[11:24] <awilkins> jelmer_: Thanks, just updating server :-) ; was a weird link though, never touched it. It's recognizably something to do with the server it's on but not something I would touch
[11:27] <LarstiQ> moin jelmer_
[11:29] <awilkins> jelmer_: Still doing it with bzr 1.16 / bzr-svn 0.6.2 / subvertpy 0.6.8
[11:29] <awilkins> jelmer_: Although the link it's trying to auth with has changed
[11:30] <johnf1> LarstiQ: I see I don't have to bug you abut bzr-svn :)
[11:30] <LarstiQ> johnf1: you already did over the weekend, and today I saw those pings ;)
[11:30] <jelmer_> awilkins: what's the sort of URL its prompting for?
[11:31] <LarstiQ> johnf1: thanks for doing so btw
[11:31] <jelmer_> mbnoimi: there is nautilusbzr, included with bzr-gtk
[11:31] <LarstiQ> johnf1: all left now is to give the packages some test spins, and then they can be copied over
[11:31] <jelmer_> mbnoimi: it's experimental though
[11:31] <awilkins> jelmer_: https://cubit.extranet.collab.net/svn/cubit
[11:31] <awilkins> jelmer_: This is on a Collabnet CuBIT server
[11:32] <awilkins> jelmer_: Before it was https://cubit.extranet.collab.net/svn/cubit/branches/hilarity/ui/extauth/cubit-skel
[11:32] <jelmer_> awilkins: that requires authentication here, even with svn
[11:32] <awilkins> jelmer_: But I've no plausible reason why it would try accessing it from a "bzr version"
[11:33] <LarstiQ> jelmer_: are you still using https://edge.launchpad.net/subvertpy/+download ?
[11:33] <jelmer_> awilkins: no idea
[11:33] <jelmer_> LarstiQ: no, http://samba.org/~jelmer/subvertpy/
[11:34] <awilkins> jelmer_: pull seems to work fine (seems a bit quicker too)
[11:34] <awilkins> When you run from your local folder, do you have to copy the extensions to the bzrlib folder to use them?
[11:36] <LarstiQ> jelmer_: can you point launchpad's download page at that?
[11:37] <jelmer_> LarstiQ: It's set up to, but that feature seems to've broken recently
[11:39] <awilkins> jelmer_: That's odd, doesn't seem to do it if you've installed instead of running from build folder
[11:48] <LarstiQ> johnf1: I think I'm happy. Shall I copy over bzr-svn now?
[11:49] <johnf1> LarstiQ: ye please and bzr and bzrtools as well
[11:49] <LarstiQ> johnf1: will do
[11:49] <johnf1> thanks
[11:56] <LarstiQ> johnf: aand they're published
[12:10] <poolie> night all
[12:14] <LarstiQ> night poolie
[12:17] <LarstiQ> jelmer_: can you approve me for ~subvertpy?
[12:45] <LenzGr> So I wanted to test the Bzr Explorer, but it fails with the following message:
[12:45] <LenzGr> $  bzr explorer
[12:45] <LenzGr> bzr: ERROR: No module named lib.util
[12:45] <LenzGr> You may need to install this Python library separately.
[12:45] <LenzGr> Has anyone seen this?
[12:45] <LenzGr> I can't find said python lib...
[12:51] <LarstiQ> LenzGr: how did you install Bzr Explorer?
[12:51] <LenzGr> LarstiQ: I branched the lp project into my plugin dir, as stated in the instructions
[12:52] <LarstiQ> LenzGr: k
[12:52]  * LarstiQ tries the same
[12:52]  * LenzGr uses openSUSE 11.0, FWIW...
[12:53] <LarstiQ> LenzGr: works for me, on Debian Lenny
[12:53] <LenzGr> LarstiQ: OK, I guess I will submit a bug report then :)
[12:53] <LenzGr> Oh wait...
[12:53] <LenzGr> I guess my version bzr-qt is too old.
[12:54] <LenzGr> 0.8...
[12:54] <LenzGr> Never mind...
[12:54]  * LenzGr tries to update
[12:56] <vila> LenzGr: if updating solve your problem, file a bug anyway, bzr explorer should checks its dependencies
[12:57] <LenzGr> vila: Can do. Agreed, the error message could be a bit more helpful
[14:21] <AfC> $ bzr help revisionspec
[14:21] <AfC> bzr: ERROR: No module named subvertpy
[14:21] <AfC> You may need to install this Python library separately.
[14:21] <AfC> huh?
[14:26] <verterok> AfC: bzr-svn requires subvertpy
[14:26] <verterok> hi! :)
[14:27] <AfC> verterok: which is what? [any idea why this would have broken now whereas it was working silently for ages]
[14:27] <verterok> AfC: did you updated bzr-svn?
[14:27] <AfC> verterok: [and, hi! back Guillermo :)]
[14:28] <AfC> verterok: yea
[14:28] <verterok> AfC: installing the dependency should fix it :)
[14:31]  * AfC wonders what the dependency is. There's no *subvert* package on my system
[14:36] <johnf> Afc: you using the ppa?
[14:37] <AfC> johnf: no
[14:37] <verterok> AfC: https://edge.launchpad.net/subvertpy
[14:37] <AfC> "Alternative Python bindings for Subversion"? Never heard of it
[14:38] <verterok> AfC: and if you'r using Ubuntu adding the ~bzr ppa should be enough: https://edge.launchpad.net/~bzr/+archive/ppa
[14:38] <AfC> verterok: no, not using Ubuntu. Stopped using Debian 7 years ago. Never looked back.
[14:39] <verterok> AfC: don't know if it's packaged for your distro :/
[14:39] <verterok> AfC: bzr branch lp:subverty; and install it from source ;)
[14:39] <AfC> Does anyone know if there's a way to tell bzr-svn to use whatever it used to use?
[14:40] <AfC> verterok: ok. Is it a bzr plugin, or am I going to have to jump through hoops to try and install it somewhere?
[14:40] <verterok> AfC: I think subvertpy was part of bzr-svn
[14:40] <AfC> Oh shit
[14:40] <verterok> AfC: what distro are you using?
[14:42] <AfC> verterok: Gentoo on systems I control, RHEL on systems I don't.
[14:42] <AfC> verterok: (and some Solaris, unfortunately)
[14:43] <verterok> AfC: for  Gentoo it should be quite easy to create an ebuild....for the RHEL and Solaris...I don't know :(
[14:43] <AfC> verterok: of course
[14:43] <AfC> Just the usual "oh, joy, another dependency that doesn't already exist"
[14:44] <AfC> we went through this already once with Subversion needing to be build by hand. :|
[14:45] <verterok> AfC: subvertpy avoid requiring a patched subversion :)
[14:45] <AfC> "great"
[14:46] <verterok> but you need subvertpy :)
[14:46] <AfC> "great"
[14:46] <monkey_d_luffy> I accidentily deleted (through a bad makefile) a directory in my project. I would like to restore it from bzr. But from what I can see, I can only "export" a whole branch.  How can I do this?
[14:46] <AfC> monkey_d_luffy: does
[14:46] <AfC> $ bzr status
[14:46] <AfC> monkey_d_luffy: show it as removed?
[14:48] <AfC> verterok: [Any idea how to tell bzr-svn to use the subverty checkout I just built?]
[14:48] <monkey_d_luffy> AfC: yes, the whole dir contents is shown as removed.  How can I restore this specific directory (and files and subdirs)?
[14:48] <AfC> monkey_d_luffy: then
[14:49] <verterok> AfC: move the build into the bzr-svn checkout? :)
[14:49] <AfC> $ bzr revert path/to/directory
[14:49] <verterok> AfC: or include it in the PYTHONPATH of bzr
[14:49] <AfC> monkey_d_luffy: should restore it
[14:49] <AfC> move it into... um
[14:51] <monkey_d_luffy> AfC: thanks
[14:51] <AfC> monkey_d_luffy: (if you ever *really* get backed into a corner, you can always just branch another branch
[14:51] <AfC> (hm)
[14:51] <AfC> with say
[14:51] <AfC> $ cd ..
[14:51] <AfC> $ bzr branch bad/ good/
[14:51] <AfC> $ mv good/missing/ bad/
[14:51] <AfC> (sic)
[14:52] <AfC> or something to that effect)
[14:52] <AfC> monkey_d_luffy: you've got full history, so you can always get back
[14:57] <monkey_d_luffy> AfC: full history as long as I have commited :p          I did loose a bit of information, but not much I think.   This scared me.  If the remove was a dir up... I would have lost everything... also ".bzr"
[14:58] <monkey_d_luffy> I think it's time to backup to read-only media
[14:59] <AfC> monkey_d_luffy: nothing so drastic needed ... but this is why it's a good idea to push your work elsewhere from time to time
[15:01] <AfC> [even internal work-in-progress branches we tend to push up to our public server; not so much for anyone else to see, but it is another defence against what you describe - and tends to be fresher (since easier) that proper backups (which we also do!)]
[15:04] <Sheepherd> you here lifeless?
[15:10] <tedg> lifeless: Added a script to bug 390490 to recreate it.  I now know how to make the revno's backwards :)
[15:14] <vadi2> For a patch made with bzr diff, how can it be applied?
[15:18] <Tak> patch < blah.diff
[15:19] <Sheepherd> just reading "bazaar in five minutes" and im about to "publishing your branch with launchpad"
[15:19] <vadi2> And for windows? the said contributor has an odd setup of a gprs modem in a vm because it doesn't work on linux
[15:19] <Tak> cygwin + patch < blah.diff? ;-P
[15:19] <vadi2> heh
[15:19] <Sheepherd> set up my account properly and now the tutorial says: "$ bzr push bzr+ssh://john.doe@bazaar.launchpad.net/~john.doe/+junk/myproject" replacing john.doe with you own launchpad username
[15:19] <Tak> I dunno, tortoise might have some util for applying a patch
[15:20] <Sheepherd> i put Sheepherd @ both places but it doesnt work
[15:21] <Sheepherd> returns the errow: "Unable to loop up default port for ssh
[15:21] <Sheepherd> error*
[15:22] <Sheepherd> someone knows why this happens to me? win xp 32bit sp3
[15:23] <vadi2> Firewall?
[15:23] <Sheepherd> i allowed the app
[15:23] <Sheepherd> but wait a mom... gonna check if thats the prob
[15:24] <Sheepherd> nope... doesnt work without firewall
[15:26] <Tak> specify the port in the url?
[15:27] <Sheepherd> how?
[15:28] <Tak> bazaar.launchpad.net:22
[15:29] <Sheepherd> k thx gonna try after a reboot
[15:30] <AshtonKem> Hey, quick question. I have my own branch on launchpad. But after I did a merge from trunk, it turns out that trunk is broken. How would I revert one revision back from trunk, but not my branch?
[15:35] <vila> jam: ping
[15:42] <jam> hi vila
[15:47] <vila> jam: I just wanted to clarify the naming rules for pyrex/python modules as there seem to be several right now
[15:48] <vila> _py.py for python _pyx.py for pyrex right
[15:48] <jam> vila: it changed over time
[15:48] <jam> _pyx.pyx actually
[15:48] <jam> :)
[15:48] <vila> yes :)
[15:48] <jam> but yeah, Robert said he prefers that
[15:48] <jam> and I don't really care
[15:49] <vila> Ok, so it allows to use the same method names in both implementations
[15:50] <vila> I'm updating _dirstate_helpers to that scheme and aligning all other module names (the final aim is to be able so safely predict the generated C file name when pyrex is not available)
[15:51] <vila> I also like to call them pyrex methods/modules instead of C methods/modules to make it clearer if one day we have a third pure-C implementation for one module
[15:52] <vila> In fact, that already works for patience diff
[15:59] <vila> jam: no objections ^ ?
[15:59] <vadi2> Is it planned to fix bzr-gtk anytime soon?
[16:01] <jam> vila: no objections
[16:05]  * SamB wonders why his completions for "bzr" are so lame right now -- it doesn't complete directories in "bzr co --lightweight", for instance!
[16:05]  * SamB is using zsh
[16:09] <Sheepherd> when i try to publish my branch with launchpad i get this error: http://pastebin.com/da8a7a5b
[16:09] <Sheepherd> why is that so?
[16:10] <Tak> Sheepherd: are you using the keyset that you set up with launchpad?
[16:11] <Sheepherd> Tak: whats that?
[16:11] <Sheepherd> nvm found the issue
[16:12] <Sheepherd> forgot one slash somewhere in the command :/
[16:12] <LCIDFire> Hi. Could someone give me a hint how to get a bzr branch imported into git
[16:14] <awilkins> LCIDFire: Bidirectionally or once?
[16:14] <LCIDFire> awilkins: Every once in a while - but just pulling
[16:16] <awilkins> LCIDFire: Well, I'm not sure if bzr-fast-import works incrementally
[16:16] <awilkins> LCIDFire: But that's maybe a good place to start. And there's a bzr-git plugin too.
[16:16] <LCIDFire> awilkins: But it seems to me that they are the other way around
[16:17] <awilkins> LCIDFire: bzr-fast-import is based on git-fast-import, so the output of the frontend for bzr should be compatible with git (?)
[16:18] <awilkins> LCIDFire: I've not used bzr-git but if it's like bzr-svn it should support push
[16:18] <LCIDFire> awilkins: I'd just submit patches instead of pushing
[16:26] <lamalex> I ran bzr shelve --all and got this 'bzr: ERROR: Tree transform is malformed [('missing parent', 'new-16'), ('missing parent', 'new-1')]'
[16:26] <lamalex> anyone know why?
[16:26] <dash> woah
[16:26] <dash> no, but I sure would like to
[16:27] <lamalex> heh me too
[16:28] <LCIDFire> awilkins: do you know whether piping works?
[16:31] <awilkins> LCIDFire: piping from what to what?
[16:31] <awilkins> LCIDFire: fast-export | fast-import  ?
[16:32] <LCIDFire> awilkins: from bzr fe to git fi
[16:32] <awilkins> LCIDFire: It should work, if it's going to work
[16:32] <LCIDFire> awilkins: at least it does not complain too much - we'll see what it does
[16:33] <LCIDFire> awilkins: what is a checkpoint in bzr language?
[16:33] <awilkins> tag?
[16:33] <awilkins> I'm not sure what a checkpoint in git is though
[16:34] <LCIDFire> it's over 1000 commits
[16:34] <awilkins> LCIDFire: Ah, that would be a pack boundary, I suppose
[16:35] <awilkins> LCIDFire: It auto-repacks at intervals
[16:35] <LCIDFire> awilkins: could be
[16:37] <awilkins> lamalex: shelve was changed to use the same operations as the VCS does, but I'm not sure for the specific reason for your error, but it might be that you have a file in a folder that hasn't been added??
[16:37] <awilkins> lamalex: Looks like a bug anyway
[16:37] <LCIDFire> at 2000 commits
[16:40] <lamalex> awilkins: i have many files in my folder that haven't been added
[16:41] <lamalex> that shouldnt matter though.. if it does- definitely a bug
[16:41] <LCIDFire> awilkins: it's done - and seems pretty good - thanks a lot
[16:44] <awilkins> LCIDFire: Excellent.. does it seem to have an "incremental" feature?
[16:45] <LCIDFire> awilkins: it does not "seem" - but it might be smart enough (hopefully)
[16:47] <LCIDFire> awilkins: even if it is - it will probably still need a complete export of the branch - which is not a nice thing to do :(
[16:48] <awilkins> http://www.fthieme.net/drupal6/node/77
[16:48] <awilkins> Apparentlt it does support it
[16:49] <awilkins> Right, hometime
[16:51] <LCIDFire> awilkins: I seem to overlook the phrase where it states it...
[17:34] <jelmer_> LarstiQ: yeah, one sec
[18:56] <SamB> hmm ... is it possible for bzr diff to show context information like git diff does?
[18:57] <SamB> I mean, after the @@ .. @@ line?
[18:57] <SamB> (well, at the end, actually)
[18:58] <SamB> for example:
[18:58] <SamB> --- a/arch/x86/kernel/signal.c
[18:58] <SamB> +++ b/arch/x86/kernel/signal.c
[18:58] <SamB> @@ -340,6 +340,8 @@ __setup_frame(int sig, struct k_sigaction *ka, sigset_t *set,
[19:20] <shane_fagan> Hey im trying to push to launchpad but bzr keeps telling me no revisions to pull
[19:20] <shane_fagan> Or push ha
[19:27] <garyvdm> shane_fagan: what makes you think that there are revisions that have not been pushed?
[19:27] <shane_fagan> It isnt showing up on launchpad
[19:27] <shane_fagan> and I pushed it about 20 minutes ago
[19:29] <garyvdm> try running bzr log -l 1 lp:{your branch]
[19:30] <garyvdm> That will confirm if you have pushed, and the launchpad ui has not updated it's cache
[19:30] <garyvdm> Which is what I suspect.
[19:30] <shane_fagan> no output
[19:30] <shane_fagan> strange
[19:31] <garyvdm> Please pastebin terminal.
[19:32] <garyvdm> brb
[19:32] <shane_fagan> there is nothing to pastebin
[19:33] <garyvdm> Ok - what is you branch on launchpad?
[19:33] <shane_fagan> Ill try again just give me a sec
[19:35] <shane_fagan> Hmm still didnt work lp:~shanepatrickfagan/+junk/zeitgeist_empathy
[19:36] <garyvdm> and if you do "bzr log -l 1" in the directory that you are pushing from?
[19:37] <shane_fagan> shane@shane-laptop:~/zeitgeist_empathy
[19:37] <garyvdm> lp:~shanepatrickfagan/+junk/zeitgeist_empathy is empty
[19:37] <garyvdm> No revisions
[19:37] <shane_fagan> yep thats the problem I tried pushing to it but it says no revisions to push
[19:38] <garyvdm> What happens if you do just bzr log -l 1"
[19:38] <garyvdm> bzr log -l 1
[19:39] <shane_fagan> nothing
[19:39] <garyvdm> So your local branch is the same as the launchpad branch - so push is working fine.
[19:39] <garyvdm> Both your branches are empty.
[19:40] <garyvdm> Have you done bzr commit?
[19:40] <shane_fagan> I have 1 file in the one on my computer
[19:40] <shane_fagan> Yes but I havent on this branch
[19:40] <garyvdm> You need to do bzr add
[19:40] <garyvdm> then bzr commit
[19:40] <garyvdm> then bzr push
[19:41] <shane_fagan> Ok that must be my problem
[19:42] <shane_fagan> bzr: ERROR: Path(s) are not versioned: "lp:~shanepatrickfagan/+junk/zeitgeist_empathy"
[19:43] <garyvdm> What did you try?
[19:43] <shane_fagan> bzr commit lp:~shanepatrickfagan/+junk/zeitgeist_empathy
[19:44] <garyvdm> No - you first need to commit locally, and then push to launchpad.
[19:44] <garyvdm> So just bzr commit -m "your message"
[19:45] <shane_fagan> Ah there I feel really stupid
[19:47] <garyvdm> Don't worry.
[19:47] <shane_fagan> Thanks for the help
[20:40] <abentley> SamB: To do that, supply --diff-options="-p"
[20:40] <SamB> abentley: is there a configuration option for that?
[20:40] <ddaa> I have a very strange problem here that seems to be related to bzr in a weird and indirect way.
[20:41] <ddaa> I run an apache server, with Trac and ReviewBoard on mod_python.
[20:41] <ddaa> Both of them interfacing with bzr.
[20:41] <abentley> SamB: All commands can be configured with aliases, e.g. bzr alias "diff=diff diff --diff-options=-p"
[20:42] <ddaa> And if I run them both in different subinterpreters, then the ElementTree monkeypatching fails the second time it runs.
[20:42] <ddaa> With AttributError, no ElementTree in module.
[20:42] <ddaa> If I run them both in the same subinterpreter, it works.
[20:42] <ddaa> (actually, the test was with one in main_interpreter, and one in a sub-interpr, but I doubt it makes any difference).
[20:43] <ddaa> Does it makes sense to anyone here?
[20:44] <SamB> abentley: ah
[20:44] <abentley> ddaa: No, not something I've heard of.
[21:33] <beuno> jam, hi
[21:33] <beuno> are around?
[21:33] <jam> hi beuno
[21:34] <beuno> jam, got a sec to help me figure out a bbc bug?
[21:34] <beuno> (or what I think is a bbc bug)
[21:34] <beuno> https://pastebin.canonical.com/18839/
[21:34] <beuno> this is a new 2a branch created today
[21:35] <beuno> I suspect stacking bugs: the return of the undead
[21:35] <jam> stacked or not?
[21:35] <beuno> stacked
[21:36] <beuno> with 1.16
[21:36] <beuno> 1.16rc1 on the other end (LP)
[21:37] <jam> beuno: do you get the same error if you just try to do "bzr branch lp:..." ?
[21:38]  * beuno tries
[21:38] <beuno> jam, not into a shared repo with all the revisions already present
[21:38] <beuno> not sure how to test it without the revisions present
[21:39] <beuno> (as it's my branch, etc)
[21:39] <beuno> but someone else tried it, and it did fail
[21:39] <jam> so does merge still fail "in a shared repo with all the revisions present"?
[21:39] <beuno> cprov, ping?
[21:39] <cprov> beuno: yo
[21:39] <cprov> beuno: I don't know anything about bzr :)
[21:39] <beuno> cprov, did you get the error with my branch on merge, or on branch?
[21:40] <cprov> beuno: ah, yes, one merge or pull, it seems to be a problem in the smartserver.
[21:40] <beuno> jam, seems so, but this is new to 2a, because we've been error-less since ~1.14rc1 or so
[21:40] <jam> beuno, cprov: to test this out locally, you can "bzr branch myrepo/devel testrepo"
[21:40] <cprov> beuno: https://pastebin.canonical.com/18844/
[21:41] <beuno> ah
[21:41] <beuno> jam, so on pull it breaks as well
[21:41] <jam> and then cprov oddly enough that is a different traceback than https://pastebin.canonical.com/18839/
[21:41] <jam> not that it really matters
[21:41] <jam> I have some thoughts
[21:41] <jam> but I'll try to check it here
[21:41] <beuno> thanks
[21:41] <beuno> it's release week
[21:41] <beuno> and I need to get that branch landed somehow  :)
[21:41] <jam> have to wait for it to download
[21:42] <jam> beuno: I'm not sure if I'll have access to your branch
[21:42] <beuno> jam, I think you should, but I'll subscribe you anyway
[21:59] <jam> beuno, cprov: just to be sure, can you access it via sftp?
[21:59] <jam> (you should be able to, and that is the current workaround)
[21:59] <cprov> jam: I can try, one sec
[21:59] <beuno> jam, even if we could, EC2 can't
[22:01] <cprov> jam: it seems to work over sftp
[22:01] <cprov> jam what's the 'nosmart' trick for bzr+ssh ?
[22:01] <lifeless> moin
[22:02] <beuno> cprov, lp+nosmart://...
[22:02] <beuno> hiya lifeless
[22:04] <lifeless> jam: before you go, reviewing the patch I copied you on is really important to me ;)
[22:09] <cprov> jam: after the successful merge with sftp, bzr+ssh works as well
[22:13] <lifeless> jam: ah, found the review from you - thanks.
[22:13] <beuno> cprov, jam, it seems that once the revisions are in the shared repo, all is fine
[22:14] <beuno> smells exactly like the 1.13 stacking bug
[22:14] <lifeless> I think it is
[22:14] <lifeless> which is, that the delta being created on the server is too big
[22:15] <beuno> lifeless, and why did it come back in 2a?
[22:15] <lifeless> don't know yet
[22:15] <lifeless> there are two possibilities
[22:16] <lifeless> a) the code that chooses what to push/request, to ensure that good deltas can be made, is broken.
[22:16] <lifeless> b) the code that makes good deltas, is broken
[22:16] <lifeless> c) Something I haven't thought of.
[22:16] <beuno> ok, progress
[22:16] <beuno> now
[22:16] <beuno> 1) do you want me to file a bug?
[22:16] <lifeless> no
[22:16] <lifeless> its already filed
[22:17] <beuno> 2) how can I get passed this, and land my branch, as it's the last day to land fixes on Launchpad?
[22:17] <lifeless> use sftp
[22:17] <beuno> I can't
[22:17] <lifeless> or nosmart+
[22:17] <beuno> it needs to go through EC2
[22:17] <beuno> and EC2 uses lp:
[22:17] <lifeless> teach EC2 to use sftp or nosmart
[22:17] <beuno> re-building the EC2 image will take...  4 or 5 hours
[22:18] <lifeless> Downgrade your branch to 1.9-rich-root
[22:18] <lifeless> which will take longer :P
[22:18] <beuno> I have about 2 hours to land this
[22:18] <lifeless> land it by hand
[22:19] <beuno> how?  it needs to be in LP, and whenever it's pushed to LP it breaks
[22:19] <lifeless> that last bit didn't parse
[22:20] <beuno> how can I land this branch, if it breaks when it's pushed to Launchpad?
[22:20] <cprov> beuno: it doesn't help if you reapply the diff in a fresh branch ?
[22:20] <cprov> probably not, ignore me.
[22:21] <beuno> cprov, maybe, I don't know what will fix it at this point
[22:21] <beuno> maybe not stacking it
[22:22] <beuno> but it will take hours to push it as well
[22:23] <cprov> beuno: branch lp:~cprov/launchpad/beuno
[22:24] <beuno> cprov, thanks. I'll get someone who doesn't have the revs to branch it
[22:26] <cprov> beuno: I didn't merge you branch successfully in my local repo, it was in dogfood. I've reapplied your diff in a fresh branch in my machine.
[22:26] <beuno> cprov, the problem is that you will have stacked the branch, so it may contain the same error
[22:27] <lifeless> beuno: get a LOSA to push your branches revisions to whatever branch you stack on
[22:27] <cprov> beuno: right
[22:27] <beuno> lifeless, of course, all LOSAs are sprinting in London and sleeping by now  :)
[22:27] <beuno> fantastic day, as you can see
[22:27] <lifeless> yes
[22:28] <beuno> lifeless, I'll try and figure this out, maybe using chinstrap for speed. But, can you please make sure this is treated as critical?  it will bring the Launchpad team to a stop
[22:29] <lifeless> beuno: it is
[22:29] <beuno> lifeless, thank you
[22:30] <lifeless> beuno: however you will /need/ to fix EC2 in the short term
[22:30] <beuno> lifeless, yes, I will make sure everyone is aware
[22:30] <lifeless> because that can be done without blocking on server side changes which this needs
[22:31] <beuno> yeah, we can tackle it on all fronts
[22:31] <lifeless> jam: ping? or are you gone already?
[22:57] <abentley> beuno: You don't *need* to run the test on EC2.  You can run them locally.
[22:58] <beuno> abentley, yes, I can stop working for 5 hours while tests run
[22:58] <beuno> also, PQM will fall over as well
[22:59] <abentley> beuno: Sorry, I thought that that this was a critically-important branch.
[23:00] <beuno> abentley, it is. But tests locally take longer than EC2 (5hs vs 2.5)
[23:01] <abentley> lifeless: couldn't this be that issue where stacking is too aggressive, so it doesn't with the smart server, just dumb clients?
[23:07] <lifeless> abentley: I think its the same cause, but the details will be different for CHK
[23:08] <lifeless> 07:16 < lifeless> a) the code that chooses what to push/request, to ensure that good deltas can be made, is broken.
[23:08] <lifeless> 07:16 < lifeless> b) the code that makes good deltas, is broken
[23:08] <lifeless> 07:16 < lifeless> c) Something I haven't thought of.
[23:11] <jam> beuno: btw, I can't see your branch
[23:11] <jam> I assume you never got me subscribed
[23:11] <jam> lifeless: I'm here, but I'm just about to head out the door
[23:11] <lifeless> jam: do you agree with my analysis - have you done more analysis on this yourself?
[23:12] <jam> lifeless: I just managed to download launchpad itself
[23:12] <jam> I was going to poke at it, but haven't got there
[23:12] <lifeless> jam: you don't need lp; there are bzr branches suffering
[23:12] <jam> and yes, it is either a, b, or c :)
[23:12] <lifeless> do you have a hunch, given you touched this area for chk most recently?
[23:13] <jam> lifeless: so unfortunately this is happening on the *server* and we don't get the server traceback
[23:13] <jam> so I'm not sure where it is happening
[23:13] <jam> it certainly looks like the "iter_interesting_nodes" is thinking different things locally than it does on the server
[23:13] <jam> otherwise, it should have found that text to be missing, and have requested it be filled in
[23:15] <lifeless> bug 390563
[23:15] <lifeless> jam: ^
[23:16] <lifeless> bzr branch lp:~mbp/bzr/progress progress
[23:16] <lifeless> is suffering apparently
[23:17] <jam> lifeless: so that would indicate it isn't a bbc thing
[23:17] <beuno> jam, re-pushed
[23:17] <lifeless> oh right yes
[23:17] <lifeless> man, my thinking cap was not working at all :)
[23:18] <jam> Are we sure Martin's 'progress' branch wasn't originally pushed with a "broken client" ?
[23:19] <lifeless> jam: not entirely
[23:19] <lifeless> I'll get him to run the fixer
[23:19] <jam> So... we can be quite sure of it for the LP branches, since they wouldn't have pushed up a --2a without it :)
[23:19] <lifeless> indeed
[23:19] <jam> but i'll play around with it a few different ways
[23:20] <jam> Unless you take care of it tonight
[23:20] <jam> I need to go pick up my son
[23:20] <jam> I might check back in later tonight
[23:20] <lifeless> kk
[23:20] <jam> beuno: I still get "bzr: ERROR: Not a branch: "bzr+ssh:/...~beuno/launchpad/sprites-more-fixes/"
[23:20] <jam> I'm not on the Launchpad team
[23:21] <jam> I can only see the trunk because jml subscribed me
[23:23] <beuno> jam, you are subscribed
[23:23] <beuno> can you go to: https://code.edge.launchpad.net/~beuno/launchpad/sprites-more-fixes
[23:23] <jam> beuno: nope
[23:24] <jam> :(
[23:24] <beuno> really?
[23:24] <beuno> argh
[23:24] <beuno> you show up on the subscribers list...
[23:24] <beuno> jml, can you help?
[23:24] <beuno> jam, are you logged in?
[23:24] <beuno> on edge
[23:24] <jam> beuno: yep
[23:24] <jam> yep
[23:24] <jml> beuno, what's the problem?
[23:24] <beuno> ~jameinel is subscribed
[23:25] <beuno> jml, jam's subscribed to a branch
[23:25] <beuno> and he still can't access it
[23:27] <jam> lifeless: my simple direct tests with a --2a conversion of bzr.dev and about 500 extra revisions in a stacked location does *not* reproduce this
[23:27] <jam> so we'll need to try something else
[23:27] <jam> lifeless: I'll be back later
[23:28] <beuno> lifeless, FYI, branching trunk locally, and merging the sprites branch into it, and pushing, doesn't trigger this problem
[23:28] <beuno> no idea why
[23:28] <beuno> but it doesn't
[23:28] <jml> beuno, jam needs to be subscribed to db-devel also.
[23:29] <beuno> jml, smells like a UI bug
[23:29] <beuno> (thanks(
[23:29] <jml> beuno, it's a very complicated one that I'd be glad to discuss with you & fix when we both have the time to do so :)
[23:29] <beuno> jam, try again when you're back
[23:29] <beuno> jml, :)
[23:34] <jml> after packing, can I delete obsolete packs?
[23:34] <jml> safely, that is.
[23:37] <beuno> jml, make sure the branch still works (bzr log?) and yes
[23:37] <beuno> I do that routinely on the office branches
[23:56] <lifeless> jml:  you can remove the contents of obsolete_packs/, not the dir itself
[23:56] <lifeless> jml: but you should 'sync' first