[00:34] <BasicOSX> hmm, test suite core dumping
[00:34] <lifeless> :(
[00:34] <BasicOSX> trying pristine pbuilder to make sure my environment isn't the problem
[00:39] <thumper> hi guys
[00:39] <thumper> if I have a branch that is stacked on another
[00:39] <thumper> how can I confirm (in a unit test) that the branch that is stacked doesn't have all the revisions?
[00:40] <thumper> a simple count of revisions in the branch's repository would suffice for the test case I guess
[00:42] <lifeless> stacked_branch.bzrdir.open_repository().all_revision_ids()
[00:42] <thumper> lifeless: ta
[00:42] <lifeless> stacked_branch.repository.all_revision_ids()
[00:42] <lifeless> set and difference kgo
[00:42] <lifeless> spiv: ping
[00:44] <spiv> lifeless: pong
[00:45] <lifeless> so jam and vila seem to not be fixed by the bug fix
[00:45] <lifeless> see last night around 11
[00:48] <spiv> Hmm.
[00:49] <abentley> thumper: yes.
[00:53]  * spiv tries to reproduce
[01:06] <spiv> lifeless: I can't reproduce; if I push that same bbc-1.14 branch with bzr.dev I get the error on pull, and if I push it with the fix branch I don't get the error.
[01:07] <lifeless> spiv: then I blame 'they didn't use the new branch'
[01:07] <spiv> lifeless: that's my guess.
[01:08] <spiv> It's possible that at the time vila pushed up the bzr.dev in LP was a bit different so as to tickle subtly different case, but that strikes me as unlikely.
[01:12] <lifeless> agreed
[01:12] <lifeless> vila: ping
[01:12] <lifeless> jam: ping
[01:12] <lifeless> ^^^^
[01:30] <skip_m> hello - is this the place for bzr help?
[01:30] <lifeless> its a place ;)
[01:30] <skip_m> anyone will do - thanks ;-)
[01:34] <skip_m> I'm a *complete* bzr naif.  Here's my problem. (Sorry if my terminology is wrong.)
[01:34] <skip_m> I branched mailman 2.1 awhile ago and made changes to one file, .../cron/gate_news.
[01:34] <skip_m> I then pushed that to launchpad.  Now I want to make a mailman 2.2 branch and
[01:34] <skip_m> transfer all my changes to that branch.  How do I do that?  I have my mailman 2.1
[01:34] <skip_m> branch and a pristine mailman 2.2 branch.  My first change was at rev 1135.  My
[01:34] <skip_m> last was at rev 1139.  Do I just get a diff and apply it with patch or is there a more
[01:35] <skip_m> bzr-ish way to do that?
[01:35] <lifeless> cd mailman2.2; bzr merge $path_to_mailman2.1
[01:35] <james_w> you could first try "bzr merge <your 2.1 branch with changes>"
[01:35] <james_w> depending on how mailman 2.1 and 2.2 are maintained this may do more than you want
[01:36] <james_w> if it's small things such as the version number you can revert them and commit
[01:36] <skip_m> Yeah, I just want *my* changes to the 2.1 branch
[01:36] <james_w> if it's huge then you want to cherry-pick
[01:36] <lifeless> skip_m: start by trying the simplest thing
[01:37] <lifeless> skip_m: if that grabs too much, use merge -r branch:lp:mailman/2.1.. $your-mailman2.1-branch
[01:38] <skip_m> The simplest thing for me is 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' but is that the correct way to do things?
[01:38] <skip_m> liefless: I don't understand the merge -r branch... thing.
[01:39] <lifeless> skip_m: it would figure out the 1134..1139 for you
[01:39] <lifeless> 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' is better written as 'bzr merge -r 1134..1139 ../mailman2.1'
[01:40] <skip_m> And if that merge command doesn't do what I want is there a way to easily revert it or do I just blow away my mailman2.2 repo and branch again?
[01:40] <lifeless> 'bzr revert'
[01:41] <skip_m> ok  - skip holds his breath and gingerly types 'bzr merge -r 1134..1139 ../mailman2.1' RET
[01:43] <lifeless> have you tried just 'bzr merge ../mailman2.1' ?
[01:43] <skip_m> not so good.  Something about 34 conflicts.  To many files I didn't touch.  bzr revert looks bad too.  Time for 'rm -rf ; bzr branch ...'
[01:43] <skip_m> lifeless: no, i'll try that next.
[01:43] <lifeless> skip_m: huh, no need to rm -rf
[01:43] <lifeless> what did bzr revert do?
[01:44] <skip_m> it was ugly:
[01:44] <skip_m> % bzr revert
[01:44] <skip_m> -   cron/
[01:44] <skip_m> -D  cron/gate_news.OTHER
[01:44] <skip_m> -D  cron/spambayes.ini
[01:44] <skip_m> Conflict: can't delete cron because it is not empty.  Not deleting.
[01:44] <skip_m> And I wound up with a mailman2.2 which had a 2.2 directory and an empty cron directory.
[01:44] <skip_m> It's all gone now.
[01:45] <skip_m> (should I be using pastebin or something for these little snippets?)
[01:45] <lifeless> skip_m: no, its fine
[01:45] <lifeless> anyhow, if you ever feel the need to rm -rf, just ask; you shouldn't ever get that wedged with bzr
[01:45] <lifeless> so, try 'bzr merge ../mailman2.1'
[01:46] <skip_m> lifeless: that's what people tell me about mercurial too.  I think it probably boils down to me being an old fart.  CVS and Subervsion are probably about all my feeble brain can handle. :-/
[01:46] <lifeless> its the simplest, and often the right command to use
[01:46] <Ursinha> hey beuno :)
[01:47] <Ursinha> do you know if there's an equivalent in bzr to rebase in git?
[01:47] <lifeless> so all the conflict means is that there was a file (gate_news.OTHER) that bzr didn't put in cron, that would be permanently lost if bzr deleted the cron directory
[01:47] <lifeless> Ursinha: 'rebase'
[01:47] <Ursinha> hahaha
[01:47] <Ursinha> simple as that :)
[01:47] <Peng_> It's a plugin, though, bzr-rebase.
[01:48] <Ursinha> oh, now I understand why I couldn't find it right away
[01:48] <Ursinha> thanks Peng
[01:48] <Ursinha> Peng_, even
[01:48] <Ursinha> and lifeless
[01:48] <lifeless> np
[01:48] <lifeless> skip_m: so, bzr doesn't delete cron and lets you decide how to handle the situation
[01:50] <lifeless> skip_m: how did 'bzr merge ../2.1' go for you ?
[01:51] <lifeless> (and when we say ../2.1, we mean the path to your patched copy of 2.)
[01:51] <spiv> (although, IIUC, it seems like a bug that revert doesn't implicitly mark conflicts as resolved, thus removing the conflict files, thus removing one common source of irritating and confusing "can't delete some_dir" conflicts)
[01:52] <skip_m> ok - i figured out what went wrong.  I had INSTALL, FAQ, cron, ... in my mailman2.1 dir.  When I branched in my mailman2.2 dir it created a 2.2 dir containing INSTALL, FAQ, cron, ...  Doing a bzr merge there failed miserably.  Next time around I mv'd 2.2/* and 2.2/.bzr* to . which then made mailman2.1 and mailman2.2 proper siblings.  The merge worked *much better*:
[01:52] <lifeless> spiv: it does, but revert can conflict itself
[01:52] <skip_m> % bzr merge ../mailman2.1
[01:52] <skip_m> +N  cron/spambayes.ini
[01:52] <skip_m>  M  cron/gate_news
[01:52] <skip_m> Text conflict in cron/gate_news
[01:52] <skip_m> 1 conflicts encountered.
[01:52] <skip_m> I'm sure I can fix the gate_news conflict with no problem.
[01:52] <skip_m> Thanks for the help folks.  Right now I'm off to the pool (swim, swim, swim - sure beats typing at the keyboard every now and then!!!)
[01:52] <skip_m> ciao
[01:53] <spiv> lifeless: any case that "bzr merge SOMETHING; bzr revert" doesn't Just Work smells odd to me.
[01:54] <lifeless> spiv: I agree; skip_m hadn't done that though :)
[01:54] <lifeless> the .orig file causing the conflict was the output of patch
[01:55] <lifeless> igc: could I bother you to get usertest to tell us if trunk has regressed in performance at all
[01:55] <lifeless> igc: what with the big merges yesterday
[02:11] <igc> lifeless: sure. I'm working on exactly that (great mind think alike)
[02:11] <igc> lifeless, spiv: some pain though ...
[02:11] <igc> bzr.dev 4266 can't branch Bob's 1.14rc branch :-(
[02:12] <igc> the AbsentContentFactor get_bytes_as bug
[02:12] <spiv> igc: grab it via http rather than bzr+ssh
[02:12] <spiv> as a workaround
[02:13] <igc> spiv: cool. I was about to try that
[02:13] <igc> spiv: just a reminder about how bad that bug is (not that you needed reminding)
[02:24] <igc> so spiv: how do I find http address for an lp branch? It's no longer in the UI?
[02:24] <igc> jml: ^
[02:24] <spiv> igc: lp:~aa/bb/cc -> http://bazaar.launchpad.net/~aa/bb/cc
[02:24] <igc> thanks
[02:38] <thumper> igc, spiv, poolie: can we get some reviews of abentley's big branch for nested trees please?  We don't want it to go stale again.
[02:59] <thumper> lifeless: you around?
[02:59] <thumper> lifeless: I have a stacking question
[03:07] <lifeless> thumper: ask the question :)
[03:08] <thumper> lifeless: skype would be easier I believe
[03:08] <lifeless> spiv: I reckon land that fix
[03:08] <lifeless> thumper: ok
[03:15] <spiv> lifeless: hmm, yeah
[03:18] <davidstrauss> Any major bzr folks in the Bay Area?
[03:31] <lifeless> davidstrauss: thats SF right?
[03:31] <davidstrauss> lifeless: yes
[03:31] <davidstrauss> lifeless: I'm in SF for the week for Drupal.org sprinting, and I'm always looking to see friendly free software faces :-)
[03:32] <lifeless> davidstrauss: uhm, dunno :). robey pointer is there I think, but he's paramiko/loggerhead and other things, not so much a regular bzr person
[03:32] <davidstrauss> lifeless: I met with Aaron when I was in Toronto
[03:32] <lifeless> davidstrauss: I'd drop a mail to the list TBH
[03:32] <lifeless> or twitter or whatever
[03:32] <davidstrauss> lifeless: TBH?
[03:32] <davidstrauss> lifeless: I'll tweet it
[03:32] <lifeless> to be honest
[03:32] <davidstrauss> ok
[03:32] <davidstrauss> lifeless: thans
[03:32] <davidstrauss> lifeless: thanks
[03:49] <rockstar> igc, ping
[03:53] <igc> hi rockstatr
[03:53] <igc> rockstar^
[03:53] <igc> thumper: sure, planning to review it RSN
[03:54]  * spiv -> lunch
[03:54] <igc> thumper: just running some performance tests first so we know when 1.14 is better than 1.13 and --development is better than --1.9
[03:55] <Peng_> jelmer: Yay, you upgraded bzr-svn to btrees. :)
[03:59] <thumper> igc: great
[04:00]  * igc lunch - bbiab
[04:04] <rockstar> igc, hi, for some reason, your response didn't turn my tab blue.
[04:04] <davidstrauss> If I branch a library into a subdirectly of tree and "bzr join" it, will I still be able to merge in upstream changes from the library's original branch?
[04:05] <davidstrauss> And, if so, how would I perform such a merge?
[04:07] <rockstar> igc, I'm integrating your revnocache into loggerhead.
[04:07] <rockstar> igc, and I'm can't think of a single use case for RevnoCache.
[04:11] <rockstar> igc, but I can see a use case of the opposite graph: {revid: revno}
[04:16] <rockstar> Er, I mean {revno: revid}
[04:27] <rockstar> igc, so I guess I have two questions: (1) how is RevnoCache supposed to be used, and (2) why use a tuple to describe a dotted revno?
[04:38] <igc> rockstar: so the secret to integrating revnocache is this: make sure loggerhead is getting the graph by using Branch.iter_merge_sorted_revisions()
[04:38] <igc> rockstar: there is no step 2 :-)
[04:39] <igc> rockstar: revnocache is about to be superceded by bzr-historycache btw
[04:39] <rockstar> igc, :(
[04:39] <igc> bzr-historycache will do the same thing but more
[04:40] <davidstrauss> Is --reference being dropped as an option to "join"?
[04:40] <thumper> davidstrauss: the nested tree stuff is actively being changed right now
[04:40] <rockstar> igc, so my RevGraphCache gets created with Branch.iter_merge_sorted_revisions()
[04:41] <thumper> davidstrauss: abentley is the man to ask
[04:41] <igc> rockstar: so revnocache had multiple ways of caching revnos - history will use just the best of those and be configurable as to whether it's on or not
[04:41] <davidstrauss> thumper: Currently, if I join a branch, I lose "common history" with the branch I joined from
[04:41] <igc> rockstar: yes
[04:41] <davidstrauss> thumper: I'll ask abentley
[04:41] <thumper> :)
[04:41] <igc> and the next call to it (or the next call to a dotted revno lookup) uses that cache
[04:41] <rockstar> igc, ah, so I was using all three types of cache, but it seems like RevGraphCache and a mapping of revno->revid should be all I need.
[04:42] <igc> rockstar: you want graph caching, I think it's called "revgraph" or something like that in revnocache
[04:43] <rockstar> igc, yea, RevGraphCache.
[04:43] <igc> ignore the others
[04:43] <rockstar> igc, yea.
[04:44] <igc> rockstar: I'm about a week away from releasing historycache
[04:44] <rockstar> igc, so, I also need to convert a stringified revno to a tuple revno for that graph.  Is there a helper function for that, or do I create my own?
[04:44] <igc> I have some other things ahead of it in my queue, e.g. confirming the NG format is performing well on all use cases, reviewing nested trees, etc.
[04:46] <igc> rockstar: I'll look, but something like tuple(revnostr.split('.')) ought to go close
[04:46] <rockstar> igc, yeah, that's similar to what I was thinking.
[04:49] <igc> rockstar: so it turns out to be slightly more complex ...
[04:49] <igc> grab parse_revno from revnocache/revnocache.py
[04:49] <thumper> if I have an open branch, how do I get the transport for that branch?
[04:50] <igc> it would be nice to have that in the core I guess, so put up a patch if you get a moment
[04:50] <igc> rockstar: ^
[04:51] <igc> rockstar: any other questions for now? I'm about to head into the other room where my desktop is for a while
[04:51] <poolie> hello igc
[04:51] <igc> hi poolie - welcome back!
[04:51] <poolie> thanks
[04:52] <igc> poolie: hope you had a great break
[04:52] <rockstar> igc, I don't believe so.  I'm already pretty far along.
[04:52] <poolie> it was great, thanks
[04:52] <igc> rockstar: if you do, just put a message into IRC or email and I'll check back later
[04:53] <rockstar> igc, thanks for the help.
[04:58] <thumper> nm
[05:27] <sohail> how can I update my working tree to a specific revision?
[05:31] <BasicOSX> I'm not finding the "Register a release" under the 1.14 series, perms problem? vila ? poolie ?
[05:31] <poolie> hi BasicOSX
[05:32] <BasicOSX> hi, attempting to register 1.14rc1 and upload the .zip and tar.gz, but do not see the "Register a release" for 1.14 series
[05:32] <poolie> sohail: 'bzr pull -r 123 .'
[05:32] <poolie> BasicOSX: hm me either
[05:33] <BasicOSX> don't see it for 1.13 either :-(
[05:33] <poolie> BasicOSX: i think this changed in the last release of lp
[05:33] <BasicOSX> hmm, once I figure it out, I'll need to update the releasing documentation
[05:34] <BasicOSX> I see your Code for this series now
[05:34] <poolie> BasicOSX: maybe you need to add a milestone?
[05:35] <poolie> there was some work on fusing releases and milestones
[05:35] <BasicOSX> There is a 1.14rc1 milestone there already, let me look at it
[05:35] <poolie> http://blog.launchpad.net/coming-features/linking-project-releases-in-launchpad-to-milestones
[05:38] <lifeless> BasicOSX: you could ask in #launchpad
[05:38] <lifeless> some devs idle there ;)
[05:39] <skip_m> I get this message from bzr status: 'Text conflict in cron/gate_news'
[05:39] <skip_m> I took care of the conflicts in the source and deleted the cron/gate_news.<STUFF> files. Still the
[05:39] <skip_m> conflict message is there. How do I get rid of it?
[05:39] <SKArfaceGC> long time cvs user. . . been reading about and playing with bzr.  Seems v.cool, is this an appropriate place to ask questions if I need help?  (after researching first)
[05:40] <lifeless> SKArfaceGC: 'bzr resolve'
[05:40] <lifeless> sorry
[05:40] <lifeless> skip_m: ^
[05:40] <SKArfaceGC> :)
[05:40] <lifeless> SKArfaceGC: sure it is
[05:40] <SKArfaceGC> cool.
[05:40] <lifeless> but not from me right, now
[05:40]  * lifeless heads to the shops ;)
[05:40] <SKArfaceGC> Don't have any at the moment.  just lurking
[05:40] <skip_m> lifeless: thanks
[05:42] <skip_m> In my mailman2.1 repo I have this push branch:
[05:42] <skip_m> bzr+ssh://smontanaro@bazaar.launchpad.net/%7Esmontanaro/mailman/SpamBayes/
[05:42] <skip_m> Can I just push to it from my mailman2.2 branch without creating problems?
[05:42] <AfC> SKArfaceGC: you may want to know that both this channel and the project's mailing list are used jointly for  user[s of bzr]  as well as hacker[s working on the tool] discussion. So sometimes it can get a little esoteric
[05:45] <SKArfaceGC> I write large security software for a living.  I can deal with esoteric.  :)
[05:46] <sohail> poolie, thank you!
[05:46] <skip_m> I used bzr push --overwrite ... which seemed to work.  If that was a bad thing, speak now or forever hold your peace. :-)
[05:59] <spiv> skip_m: push --overwrite will overwrite the history in that branch to be the same as the branch you are pushing from
[05:59] <spiv> skip_m: so if that's what you wanted to happen, then that's fine :)
[06:00] <skip_m> spiv: Thanks - that's fine.  Mailman 2.1 is a dead end.  I was asked to port my changes to Mailman 2.2.  I officially no longer care about
[06:00] <skip_m> mm 2.1.
[06:00] <spiv> lifeless: btw, my fix branch failed because it adds one more get_parent_map call the stacked push acceptance test.
[06:00] <spiv> skip_m: sounds good then.
[06:02] <spiv> skip_m: (normally in that situation I would have merged 2.2 into my branch and committed that, in which case a regular push would work just as well as there is no divergence of history)
[06:03] <SKArfaceGC> hrm. . . are there any karma granting/branch locking hooks available?  Something like sheila for CVS
[06:03] <skip_m> spiv: i know nothing about the possibly divergent histories of mm 2.1 and 2.2 (and don't really care).  I just wanted to get my little enhancement out there for people to use.
[06:07] <lifeless> spiv: as it stands it has to
[06:07] <lifeless> spiv: so +1 to increasing the ratchet
[06:08] <spiv> lifeless: that's my feeling too.  Glad you agree :)
[06:11] <Peng_> BasicOSX: Congrats on the release (candidate). :)
[06:11] <BasicOSX> long road traveled on this one.. thank you though
[06:13] <Peng_> On a different subject, is it just me or do some of BasicOSX's gpg-signed emails fail verification? Like the 1.14rc1 announcement on the announce list.
[06:15] <BasicOSX> That's the 2nd time I've heard that. Seems to be only to mailing lists.
[06:15] <Peng_> Oh, nice.
[06:16] <BasicOSX> First time was a user on Win32, so I, well, kinda ignored them
[06:16] <BasicOSX> tbird doesn't have the best pgp hooks
[06:16] <BasicOSX> (not that mail.app is any better)
[06:17]  * Peng_ is using Thunderbird + Enigmail
[06:17] <BasicOSX> :-P
[06:17] <BasicOSX> On windows? :-)
[06:17] <Peng_> No, an out-of-date Ubuntu box. :D
[06:18] <BasicOSX> sheesh bug reports coming in on 1.14rc1 already
[06:20] <Peng_> I think several of you have been to bed and gotten up again while I've been awake. :\
[06:21] <Peng_> (Well, if you haven't, then you should be getting more sleep!)
[06:29] <spiv> lifeless: btw, I'm using ec2test.
[06:43] <BasicOSX> PQM playing 1.14rc1 back into bzr.dev, afk for dinner
[06:45] <lifeless> spiv: liking it ?
[06:53] <spiv> lifeless: it's neat, but it'll be much more likeable with the rough edges smoothed off :)
[06:53] <lifeless> spiv: thats true
[06:56] <lifeless> spiv: feel free to shave :)
[06:57] <igc> lifeless: any thoughts on bug 357478?
[06:58] <lifeless> igc: none beyond my reply
[06:58] <igc> oh, I didn't see that - I'll look
[06:58] <vila> hi all
[06:59] <lifeless> hmm, I may not have disabled tree references enough
[07:06] <igc> hi vila
[07:14] <lifeless> spiv: +1 on any changes to ec2.test
[07:14] <lifeless> .txt
[07:17] <lifeless> spiv: possibly we should ask the source, or more-local of the repositories for the parents.
[07:17] <lifeless> spiv: or something
[07:18] <spiv> lifeless: yeah.  It would be nice to have a good way of saying "get these {parents,revisions,whatever} from a set of repositories, but try the most local first".
[07:18] <spiv> It's a desire that comes up occasionally.
[08:18] <sabdfl> hello all, congrats on landing brisbane-core in trunk
[08:18] <sabdfl> two observations
[08:19] <sabdfl> commit after status seems really quick (delta over status is low)
[08:19] <lifeless> excellent
[08:19] <lifeless> that was one of the key things we were removing overhead on
[08:19] <lifeless> and thanks
[08:19] <sabdfl> explicit commit (commit file file file) seems slower than normal commit, which i don't understand since it doesn't have to check as much dirstate
[08:19] <sabdfl> and commit after add seem much slower than it used to be
[08:20] <lifeless> explicit commit: we can't use the new commit code path in all cases yet; we have to teach our core diff logic (iter_changes) to report parent directories in some cases, or you end up with a broken commit
[08:21] <sabdfl> aha
[08:21] <lifeless> this is one of the things we'll polish while its a beta format
[08:21] <lifeless> so you're seeing the older commit codepath when you do commit [paths..]
[08:21] <lifeless> doing commit -x path  will trigger that too, as iter_changes hasn't been taught to do excludes
[08:23] <lifeless> commit after add: is it slower for both the initial commit, and later commits after adds, or just the initial one?
[08:24] <lifeless> the split inventory structure requires more calculation to create the initial tree than the old flat-file xml format (but it wins massively on subsequent commits as you're seeing)
[08:25] <lifeless> so another item of polish is to work on making that initial tree operation faster
[08:28] <lifeless> The old format just wants everything in the tree appended to a list, whereas the brisbane-core format builds a dictionary. That said, there is plenty of room for optimisation.
[08:46] <lifeless> BasicOSX: please do update NEWS in bzr.dev :) its in the process I thought..
[08:47] <BasicOSX> I merged bzr.dev into my local branch, fixed up the conflicts, PQM'd it back, got a success
[08:48] <BasicOSX> merge lp:~tanner/bzr/1.14rc1 http://bazaar-vcs.org/bzr/bzr.dev
[08:48] <BasicOSX> Command was successful.
[08:48] <vila> lifeless: ec2 fix BB:approved, lowering (but not zeroing !) ec2 setup priority :)
[08:48] <BasicOSX> I did merge my lp branch "merged" so it doesn't show
[08:48] <BasicOSX> and a fresh branch of bzr.dev show my merge
[08:48] <lifeless> ok
[08:49] <lifeless> I've just not pulled in the last 40 minutes :P
[08:50] <BasicOSX> hmm, patch succeeded at 1:22am CDT
[08:50] <lifeless> fsvo 40
[08:50] <lifeless> :P
[08:51] <vila> BasicOSX: bzr version now shows 1.14rc1 in bzr.dev !
[08:51]  * BasicOSX hides
[08:51] <lifeless> lol
[08:52] <BasicOSX> I'm bring down fresh, I'm sure I forgot something :-( last part of releasing documentation isn't very detailed (I'm fixing that)
[08:52] <lifeless> BasicOSX: when you merge back you need to preserve bzr.devs concept of being bzr.dev
[08:53] <lifeless> so its merge, tweak NEWS bzr bzrlib/__init__.py
[08:53] <BasicOSX> yes, my mistake
[08:53] <vila> BasicOSX: visual inspection bzr diff -c 4267 doesn't reveal anything else, you're doing good !
[08:55] <vila> BasicOSX: I suspect you're bumping into many "it's so obvious it's not documented" points due to previous RMs being more experienced and you did a good job already updating the release process documentation, so, it's just part of it
[08:57] <BasicOSX> sadly, my free time is 11pm-3am, so the documentation is my double check when I'm sleepy
[08:57] <lifeless> well, the docs used to say to do this
[08:57] <lifeless> but perhaps lost at some point
[08:57] <BasicOSX> If it's not already done, advance the version number in bzr and bzrlib/__init__.py. Submit this back into pqm for bzr.dev.
[08:58] <BasicOSX> I read that as advance it from 1.13final to 1.14rc1
[08:58] <lifeless> that line lies
[08:58] <lifeless> or
[08:58] <lifeless> is overly brief
[08:58] <BasicOSX> I got notes now, need to make sure it's 'dev'
[08:59] <lifeless> so advance means 'change 1.14dev to 1.15dev'
[09:00] <BasicOSX> ok, just need branch, it's 1,14,0,'dev',0,
[09:00] <lifeless> yup
[09:00] <lifeless> later all
[09:01] <BasicOSX> do I need to update bzr's _script_version too ?
[09:06] <vila> BasicOSX: yes, it's even surprising it isn't mentioning dev...
[09:15]  * BasicOSX winks
[09:15] <BasicOSX> lifeless:  beat me to pqm
[09:16] <BasicOSX>   lp:~tanner/bzr/bzr.dev has my fix in it, if someone wants to verify
[09:16] <BasicOSX> v$ ./bzr --version
[09:16] <BasicOSX> Bazaar (bzr) 1.15dev
[09:17] <BasicOSX> 3:17am, sleep, email me if I need to work on other stuff I messed up :-)
[09:18] <vila> BasicOSX: good night !
[09:47]  * igc dinner
[09:50] <johnf> spiv:  you about?
[10:11] <poolie> hello johnf
[10:12] <johnf> poolie: howdy
[10:55] <Mez> using the central repository model, is there an easy way to get the server to run a test suite every time something is checked inot the branch (or merged in, etc)
[10:57]  * Kinnison uses a pqm for that, perhaps a server-side commit hook?
[11:13] <Bluehorn> Mez: PQM is here: https://launchpad.net/pqm
[11:14] <Bluehorn> *: Is there a way to aggregate multiple changes into a single revision in bzr?
[11:14] <Bluehorn> Background: I was messing around with bzr-gtk (not having used pygtk for a while) and would like to post the patch.
[11:15] <Bluehorn> But I don't think anybody would like to see the debugging code I originally had in there and the bzr misuse I did (created a conflict due to bzr push not updating the working copy).
[11:16] <lifeless> Mez: sure use a pre_branch_tip_change_hook
[11:16] <lifeless> Mez: (see bzr help hooks)
[11:17] <lifeless> Mez: pqm is not easy ;P
[11:17] <Bluehorn> lifeless: but it looks like an interesting concept ;-)
[11:17] <lifeless> Bluehorn: it is, and it works well, its just not easy ;)
[11:48] <Mez> lifeless: only through p1m?
[11:48] <Mez> lifeless: never mind, was reading something els.e
[11:48] <Mez> I'm actually looking for a post-hook, but something easy
[11:49] <lifeless> mail the list, its late for me, I'll whip one up for you tomorrow
[11:49] <Mez> thanks lifeless
[12:41] <ormandj> Hi, I am attempting to follow: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style however, I am unclear about the setting up the shared repository step. I did the setup mentioned at the "Starting a central branch" section a bit higher up, then followed the distributed setup, but after I make my feature branch, and try to merge ../trunk/ to the feature branch, it complains I have uncommitted chang
[12:41] <ormandj> es
[12:41] <ormandj> the documentation didn't make this clear what I should expect
[12:55] <lifeless> ormandj: you haven't committed your changes
[12:55] <lifeless> ormandj: you need to commit after you make a change to a branch
[12:55] <ormandj> lifeless: the documentation example didn't show the commits that's why i was confused about this
[12:55] <ormandj> it shows running the merge *before* committing
[12:56] <ormandj> ie: merge from the trunk to my new branch, then commit the merged changes along with my updates
[12:57] <ormandj> (i'm doing the distributed style setup described)
[13:07] <lifeless> well, the new branch has no changes in it when its just made; if you are getting told you have changes something odd is happening :)
[13:50] <xnevermore> Hey. I want to use bzr on my web server to keep web development projects organized. I'd like to have a main branch and a development branch, then my main public_html folder where i would pull from the main branch for deployment. What would this kind of workflow look like?
[13:51] <lifeless> it would look like a main branch, a development branch, and your public_html folder a third branch :)
[13:51] <lifeless> or you could use bzr-upload for deployment
[13:52] <xnevermore> so the main folder used to serve web pages to apache would be a bzr branch itself? or a mirror? or something else?
[13:53] <lifeless> most people seem to use bzr-upload for that folder
[13:53] <lifeless> its a plugin
[13:53] <LarstiQ> that is what I would advise
[13:54] <xnevermore> cool
[13:54] <xnevermore> i'll check that out
[13:54] <xnevermore> thank you
[14:37] <lifeless> vila: I've just sent a new [MERGE] request
[14:37] <lifeless> vila: which has the other stuff I was muttering about
[14:40] <vila> lifeless: ok, will have a look (by the way, the tests *were* passing here ;-)
[14:41] <lifeless> vila: not with my print intend change
[14:41] <lifeless> vila: your write() call wasn't indented
[14:41] <vila> lifeless: indeed, because I just copy/paste from my branch :)
[14:41] <lifeless> see ;)
[14:42] <vila> lifeless: doesn't really matter, it's just that we talked about it but it was never merged
[14:42] <lifeless> sure
[14:42] <lifeless> I think you'll like it
[14:46] <lifeless> vila: if you wanted to review it now, I could land it immediately ;)
[14:46] <vila> lifeless: I am
[14:47] <lifeless> thank :)
[14:50] <vila> BB:tweak, I think there is another atexit.register() you may want to get rid off, the one that delete the /tmp dir, plus some tests for done, startTests() :)
[14:50] <vila> or did I miss the tests ?
[14:50] <lifeless> well
[14:50] <lifeless> I moved code
[14:51] <lifeless> nothing 'new' really :) so existing tests should suffice
[14:51] <lifeless> if nothing was testing the output, then I haven't reduced the coverage; if it was tested, then I preserved the behaviour
[14:51] <vila> nothing 'new' but startTests() and done() just want to be extended/overriden :0)
[14:52] <lifeless> what sort of tests would you like to see?
[14:52] <vila> simplest ones: they are called once
[14:53] <vila> seeing the modification of InstrumentedTestResult made me think they should be trivial to add
[14:53] <jam> morning lifeless, shouldn't you be sleeping by now :)
[14:54] <lifeless> jam: yes
[14:54] <lifeless> vila: cut you a deal :) add some tests, land it ? :)
[14:54] <vila> deal
[14:54] <lifeless> cool - thanks
[14:54] <vila> More often than not I feel I want to do that for many reviews...
[14:55] <lifeless> with this, the output from selftest --parallel=forked looks like normal
[14:57] <vila> err, I hope you haven't addressed the tracebacks *during* execution :-)
[14:57] <lifeless> oh, you'll want https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/5346
[14:57] <lifeless> for obvious reasons
[14:57] <lifeless> what tracebacks?
[14:58] <vila> lifeless: when tests errors out, the tracebacks is output directly *and* when selftest finish
[14:59] <vila> I know it's a bug, but I like it :)
[15:00] <lifeless> thats normal
[15:00] <abentley> jam: I have tried to use py_memory_dump, but the files it creates are truncated at 128MiB
[15:03] <lifeless> vila: its done by the ExtendedTestResult
[15:13] <lifeless> I'm off to sleep
[15:14] <lifeless> vila: jam has plain tweaked :) - but I'll leave it in your capable hands
[15:46] <jam> abentley: I've got 200+ MB ones here.
[15:47] <abentley> jam: What python are you using?
[15:47] <jam> 2.5
[15:47] <abentley> I'm using 2.6, though I'd be surprised if that was the difference.
[15:47] <jam> mwhudson was using it with 64-bit python 2.4 and it worked for ~140MB ones, IIRC
[15:47] <jam> abentley: I'm just using fprintf() I don't see why that would be truncating anything
[15:47] <abentley> jam: Hey, all I know is that it's truncated.
[15:48] <jam> abentley: what platform?
[15:49] <abentley> I'm doing "bzr selftest", then using ^\ to get a pdb, and then calling dump_gc_objects
[15:49] <abentley> jam: Jaunty
[15:49] <jam> abentley: can you try adding a file.flush() in memory_dump/scanner.py ?
[15:50] <abentley> jam: sure.
[15:54] <abentley> jam: I tried twice.  Both were truncated; one at 120 MiB and one at 123 MiB.
[16:22] <jam> abentley: you aren't running out of disk space, or something weird like that  (sorry for the delay, I was on the phone with Vincent)
[16:23] <abentley> jam: 92 G left
[16:24] <jam> abentley: is the program crashing, or returning just fine, and the file is just clearly truncated?
[16:24] <jam> (I certainly don't do anything like truncate.... so something strange is happening)
[16:24] <abentley> bzr.dev selftest is not crashing.
[16:24] <abentley> The function is returning None.
[16:25] <abentley> jam: Have you tried it from pdb like me?
[16:26] <jam> abentley: I generally was using it via ^|, which drops you into pdb, yes
[16:26] <jam> I wasn't doing it for selftest, more for 'bzr branch'
[16:26] <jam> i'll try something again
[16:30] <abentley> jam: I tried it with bzr branch, and that also truncated it.
[16:33] <jam> abentley: does "python setup.py build_ext -i && python run_tests.py" work for you?
[16:33] <jam> I just found it starting to fail on a different platform, which is a bit strange, but I'll try to sort it out
[16:35] <abentley> jam: no: http://pastebin.ubuntu.com/147034/
[16:35] <jam> hmm... seems to be a negative integer problem here
[16:35] <jam> abentley: you are running that in the 'runsnakerun' branch, not the memory_dump branch
[16:35] <abentley> jam: No, I'm just running it in the wrong branch.
[16:36] <jam> (I *do* have a negative integer problem here, which I'm going to fix just now)
[16:36] <jam> not that it would have anything to do with what you were seeing
[16:36] <abentley> jam: still borked: http://pastebin.ubuntu.com/147035/
[16:37] <jam> abentley: yeah, it seems that under Linux you get more malloc() in the upper memory segment
[16:37] <jam> (>2GB)
[16:37] <jam> so I just need to handle the high bit being set
[16:39] <jam> abentley: I just pushed revno 59, can you see if that gets the tests to pass for you?
[16:39] <jam> (just an 'unsigned long' versus 'long' fix)
[16:44] <jam> I just dumped 262MB...
[16:44] <jam> maybe a 2.6 issue?
[16:46] <jam> though I guess now loading that dump is giving me "long int too large to convert to int", but I'll sort that out, too :)
[16:46] <abentley> jam: I get two errors about expected sizes now.
[16:46] <jam> abentley: can you paste that?
[16:46] <jam> It is possible that objects changed size in 2.6 from 2.5
[16:46] <abentley> http://pastebin.ubuntu.com/147043/
[16:47] <jam> yeah, it looks like type objects have a different size...
[16:47] <jam> so not something that means the code isn't working
[16:51] <abentley> jam: The new version still truncates, though.
[16:52] <abentley> jam: The ones I've done with branch were both truncated at 28016640 bytes.
[16:54] <abentley> kfogel: I've updated http://bazaar-vcs.org/NestedTreesDesign with comparisons to other systems.  Would value your input, especially wrt SVN.
[16:54] <SKArfaceGC> are there any tools for bzr that can handle granting/revoking commit privs to a central repo?  (similar to shiela in CVS)
[16:55] <SKArfaceGC> I did some looking and didn't see anything.
[17:48] <kfogel> abentley: will look over today (it's on my calendar, actually) thx
[17:50] <abentley> kfogel: great
[17:51] <abentley> Git submodule docs: "If you want to make a change within a submodule and you have a detached head..."
[17:53] <kfogel> abentley: well, does that describe our users? :-)
[21:22]  * SamB_irssi wonders why "Bazaar Bisect Plugin does not use Launchpad as its bug tracker."
[21:26] <eka> hi all
[21:27] <eka> shouldnt bzr diff /myoriginalbranch/ do a diff between current and that original one?
[21:28] <eka> instead I use bzr diff --old /myoriginalbranch/ to see the differences
[21:34] <LarstiQ> it used to be that way, I believe it changed to --old because bzr diff /myorginalbranch/some/file is ambigious
[21:38]  * SamB_irssi leaves a question at https://answers.launchpad.net/bzr-bisect/+question/66893
[21:45] <eka> LarstiQ: But what I ment is to compare both branches, and not a file. I thought that bzr diff /otherbranch/ was intuitive :P
[21:46] <LarstiQ> eka: hey, I'm in the same camp :)
[21:47] <eka> LarstiQ: oks... still I'm new to bzr so I thought that there was something wrong
[21:48] <eka> s/ment/meant
[21:48] <SKArfaceGC> are there any tools to handle granting/revoking commit permissions per branch?  I know it can be done at the OS level, but automating user group changes seems less than ideal
[21:48] <LarstiQ> eka: it is a concious decision to do it this way. The exact reasoning would take some digging up.
[21:48] <eka> could be a bug?
[21:49] <eka> ah ok
[21:49] <eka> thx
[21:50] <SKArfaceGC> <- still very new with bzr.
[21:50] <SKArfaceGC> :)
[22:13] <nir> How can I merge various small projects branches into single branch without loosing the history of each branch?
[22:13] <mwhudson> nir: the merge-into plugin, perhaps?
[22:15] <nir> perhaps :-)
[22:21] <lifeless> vila: pin
[22:21] <lifeless> g
[22:34] <plastik9> Hi. What's the best way to manage a web site with bzr (locally, the server is located on the same machine)?
[22:34] <lifeless> plastik9: probably just use bzr-upload to upload to the directory of the website, because bzr-upload doesn't include the bzr history and metadata that you may not want people downloading by mistake
[22:35] <plastik9> lifeless: does that work the same way as a lightweight checkout?
[22:37] <lifeless> not really
[22:38] <lifeless> you would have a separate branch or checkout that you edit in, then when you want to deploy a new version just do 'bzr upload'
[22:39] <plastik9> ok, cool. thank you.
[22:40] <plastik9> i noticed there is a section of the wiki devoted to these sorts of questions (http://bazaar-vcs.org/Scenarios), but I was disappointed to see that it hasn't been completed yet
[22:40] <lifeless> that often happens with wikis :)
[22:45] <nir> I tried to use merge-into plugin - but it does not keep the history of the merged-in branch. Is it possible to to do this?
[22:45] <nir> e.g. project-a + project +b -> project-c with all history of a and b.
[22:46] <lifeless> nir: it should; why do you say it doesn't ?
[22:46] <nir> I don't see any log except the merge in
[22:46] <lifeless> what bzr version are you using?
[22:47] <nir> 1.10
[22:47] <bob2> was the log format change a speed thing?
[22:47] <lifeless> you *should* be seeing all the commits of the branch you merged in, nested in the commit that you made after the merge in
[22:48] <lifeless> nir: are you seeing any nested commits at all? If you're not try 'log --log'
[22:48] <lifeless> erm
[22:48] <lifeless> log --long
[22:48] <lifeless> jam: ping; I do have merge-into correct don't I? ^
[22:48] <jml> lifeless: thanks for pushing done() out there.
[22:49] <lifeless> jml: needed doing; I'm thinking of actually doing it as startTestRun and endTestRun
[22:49] <nir> I don't see any nesting in this case
[22:49] <lifeless> jml: and saying 'whoever creates the result is responsible for calling both these methods'
[22:50] <lifeless> because otherwise its asymmetrical
[22:50] <jml> lifeless: in some cultures, asymmetry is the cornerstone of beauty
[22:51] <lifeless> jml: This is true; I will leave the asymettrising of python code beauty appraisal to other hands than mine
[22:51] <jml> :)
[22:52] <lifeless> in fact, a german research group has disproved the 'beauty is symmetrical' theory
[22:53] <lifeless> http://www.uni-regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/Psy_II/beautycheck/english/symmetrie/symmetrie.htm
[22:53] <lifeless> summary 'the same face made more symmetrical is perceived as more beautiful, but only by a small amount'
[22:54] <nir> More info: I do see all the history when I merge in another branch.
[23:02] <lifeless> nir: I'm not sure whats going on. I suggest filing a bug or askig on the list if jam: doesn't reply here soon
[23:02] <lifeless> nir: you have committed the merge-into right?
[23:03] <nir> I did this:
[23:03] <nir> mkdir test; cd test; bzr merge-into /path-to-branch; bzr commit; bzr log
[23:04] <nir> The first merged-in branch comes without history. The second with history.
[23:04] <nir> Third also ok
[23:06] <nir> Anyway the merge is not what I expected - I want the same history in the new branch. For example, If I have branch a with 10 revisions, and branch b with 20 revisions, I want the merged branch to have 30 revisions.
[23:07] <nir> With merge-into, I have only 2 revisions.
[23:08] <lifeless> Is there something special or different about your first merged-in branch?
[23:09] <nir> Each branch may be created on different platform with different bzr version
[23:12] <nir> bzr log --short show that I have revisions -101 to 3
[23:12] <lifeless> wow, thats odd :)
[23:13] <nir> revisions -101 to 0 are seems like the revisions of the first branch
[23:13] <lifeless> could you file a bug please
[23:13] <nir> ok
[23:13] <jam> lifeless: are you guys now off of daylight savings time?
[23:13] <lifeless> jam: yes, its 0808
[23:14] <lifeless> jam: this probably interferes with your evenings
[23:14] <poolie> hello jam, lifeless
[23:14] <lifeless> hi poolie
[23:19] <jam> lifeless: yeah. We're probably going to have to work something else out for standup calls.
[23:20] <jam> hey poolie
[23:20] <poolie> jam, because this is the time when lena's coming home etc?
[23:20] <jam> poolie: yeah, stopping my work day at 6pm+ doesn't work very well.
[23:20] <jam> I might be able to do a split shift, where I come back around 8-9
[23:20] <jam> but then that is in the middle of your day
[23:21] <jam> I could probably do 1 standup per-week, or something like that
[23:21] <jam> but every day is a bit much
[23:25] <lifeless> jam: does my reply about uses_deltas make sense?
[23:27] <nir> lifeless: see #358059
[23:27] <lifeless> bug 358059
[23:28] <nir> nice bot
[23:29] <jelmer> lifeless: moin
[23:29] <lifeless> moin moin
[23:34] <jam> lifeless: anyway, I think I understand your point, and responded. I'm off for now, but I'll try to be back around later, as we haven't really chatted in a while.
[23:34] <jam> poolie: ^^ as well