[00:33] <poolie> hi
[00:35] <jml> hi
[00:43] <spiv> Oh wow, libcurl doesn't understand select.
[00:45] <spiv> It thinks if a socket is in the exceptfds that it should raise an error.
[00:46] <spiv> A generic "(55, 'select/poll returned error')"
[00:46] <mwhudson> hello
[00:46] <spiv> Hmm, and it treats poll similarly.
[00:48] <poolie> hm that kind of sucks
[00:48] <poolie> spiv, i'll call you in 12 minutes if that suits
[00:49] <spiv> Sure.
[00:49] <spiv> (I'm wondering why I'm seeing that error failing bzrlib.tests.test_bzrdir.ChrootedTests.test_open_containing all of a sudden)
[00:50] <poolie> mwhudson: mark just asked about loggerhead, have you been able to work on it recently?
[00:51] <lifeless> poolie: ping
[00:51] <poolie> oing
[00:51] <lifeless> I replied to a number of reviews; in particular the one with get_scope etc in it would like a reply back from you at your earliest convenience
[00:51] <poolie> scared him off...
[00:51] <poolie> ok
[00:56] <spiv> Gar, it's timing related.
[00:56] <poolie> spiv: can we postpone for a bit?
[00:56] <spiv> poolie: sure
[00:56] <poolie> someone just called me
[00:57]  * spiv is chasing this spurious pycurl error
[01:15] <mwhudson> poolie: no, not really :/
[01:15] <lifeless> spiv: error?
[01:16] <mwhudson> poolie: i did some work about 5 weeks ago i guess, but i kind of got stuck on how to do navigation well
[01:16] <mwhudson> and then i got swamped by code import work
[01:17] <spiv> lifeless: http://rafb.net/p/KgSYEC45.html, no changes from bzr.dev
[01:18] <spiv> lifeless: something to do with how libcurl handles the 501 that SimpleHTTPServer generates when no do_POST method is defined.
[01:19] <spiv> lifeless: if I do things like step through with the debugger, the error doesn't necessarily happen.
[01:20] <spiv> lifeless: so at this point I'm guessing a bug in libcurl.  I'd just like to know more so I can file a useful bug report and find a reliable workaround.  (returning a 404 rather than 501, perhaps)
[01:21] <spiv> I upgraded to hardy on the weekend, so maybe there's a behaviour difference vs. gutsy ehre.
[01:22] <lifeless> hmm
[01:22] <lifeless> I'm on hardy; never seen that
[01:23] <spiv> Yeah.  There's something fishy.
[01:28] <spiv> lifeless: fwiw, here's the relevant strace snippet: http://rafb.net/p/rjF7pW86.html .  Straight after that it starts reading .py source files to generate the traceback for the exception that was raised.
[01:29] <lifeless> I don't see a socket error there
[01:30] <spiv> Indeed.
[01:30] <spiv> Just a closed connection.
[02:02] <kgoetz> hi all. i was wondering if bzr could be set to pipe help into the system pager to stop it scrolling
[02:05] <kgoetz> also, is it posable to merge branches with no shared history?
[02:08] <bob2> what's your goal in the second question?  to e.g. create a tree with ./liba and ./libb where they were in the past two seperate branches?
[02:08] <kgoetz> two seperate versioned directories called 'perlscripts', started on seperatee systems with mostly seperate files. i was hoping to merge them and keep the revision history
[02:10] <bob2> I believe 'bzr join' will do that (maybe with some history-preserving mass mvs before hand) but not sure how supported that is
[02:12] <kgoetz> thanks,i'll have a look at it. the history isnt to important, just 'nice to have'
[02:16] <kgoetz> mmm. looks like bzr join wont do it. never mind. thanks for the help :)
[02:16] <bob2> hm,it won't?
[02:19] <kgoetz> by my reading they have to have been split from the same tree at some point
[02:20] <bob2> I think the bit about branch is a bit confusing
[02:20] <bob2> and just means that you branched something into a subdir
[02:22] <poolie> kgoetz: there's no builtin option for it but it would be useful
[02:24] <kgoetz> poolie: pity theres no option, i'd certainly find it handy :) is it worth doing a wishlist bug?
[02:25] <poolie> kgoetz: just check first there is not already one
[02:25] <kgoetz> poolie: sure :)
[02:27] <bob2> hm, of the above, what does bzr join not do?  seemed to let me join two independent branches and then move the files into the one dir
[02:31] <lifeless> kgoetz: merge --force will do it for you
[02:31] <lifeless> poolie: ^ no special option needed :)
[02:31] <lifeless> s/special/new
[02:34] <kgoetz> whats the 'merge base revision'?
[02:35] <lifeless> kgoetz: merge -r 0..-1 otherbranch
[02:36] <kgoetz> neat.
[02:38] <poolie> lifeless, kgoetz: oh i meant for paging help
[02:40] <kgoetz> the dangers of askin multiple questions ;)
[02:40]  * kgoetz checks bts for a pages bug
[02:41] <lifeless> kgoetz: any reason '| less' isn't good enough ?
[02:43] <kgoetz> lifeless: only that i'm looking at lots of help at the moment, so |less ing a lot is tedious
[02:43] <lifeless> I tend to shift-up
[02:43] <lifeless> to read stuff that scrolls
[02:44] <kgoetz> i tend to use screen, where shift-up doesnt work
[02:44] <lifeless> does for me :P
[02:45] <lifeless> tho if I switch windows I need to use the screen paging facility
[02:45] <kgoetz> arent you a lucky boy :p
[02:45] <lifeless> ctrl-a [ pgup :)
[02:47]  * kgoetz doesnt find that less anoying (but good to know for sure)
[02:55] <mehemiah> hey, how does one change the format of a repo?
[02:55] <spiv> bzr upgrade
[02:56] <mehemiah> thanks, i couldn't find that  on any of the pages that concerned formats
[02:59] <mehemiah> the online documentation and documentation needs to be improved emencly, Looks like I finally got an excuse to join this project.
[02:59]  * mehemiah creates a launchpad account
[03:01] <poolie> mehemiah: welcome
[03:01] <poolie> why not send mail to bazaar@lists.ubuntu.com pointing out some improvements
[03:07] <mehemiah> that works
[03:10] <poolie> lifeless: hey
[03:11] <poolie> i guess the thing about lock warnings or tests being "sufficient" or not is that, um, it seems like trying to prove a negative
[03:11] <poolie> i can tell you for sure it will still be possible to get warnings with all the tests passing
[03:26] <ubotu> New bug: #213718 in bzr "bzr could put help into pager" [Undecided,New] https://launchpad.net/bugs/213718
[03:27] <lifeless> poolie: Phone perhaps
[03:33] <bratsche> I'm getting crashers with 1.3.1rc1 (in Hardy) when I'm trying to commit to a server using 0.90.  It gives me a big stack trace followed by: AssertionError: 840 != 841
[03:33] <bratsche> Where 840 is my current revno.
[03:33] <bratsche> Does anyone know if that's a known issue?
[03:34] <bratsche> It only seems to affect bzr+ssh:// transport.  When I switch sftp:// it is fixed.
[03:34] <jelmer> bratsche: I've seen it before, but not quite sure what causes it
[03:36] <mehemiah> so then it's a hash check error?
[03:41] <lifeless> bratsche: I believe that is a fixed bug in newer bzr's, you should upgrade the server.
[03:41] <bratsche> lifeless: Cool, thanks.  I'll pester Ubuntu people to update before Hardy comes out.
[03:43] <lifeless> bratsche: what server is it ?
[03:43] <bratsche> lifeless: 0.90 which I think is maybe the version shipped in Feisty.
[03:44] <lifeless> I meant what machine ;) if its Ubuntu related I may be able to poke someone
[03:45] <lifeless> there is a repository with builds of 1.3 etc for feisty or whatever Ubuntu version they are running
[03:45] <bratsche> lifeless: No, it's a server at the company I work at.  We're still using 0.90 until all the engineers have upgraded.
[03:50] <lifeless> ah
[03:50] <lifeless> you do know you can upgrade the server earlier than the clients ?
[03:51] <bratsche> Uhh.. I did not.
[03:51] <bratsche> It doesn't really matter that much to me now, I changed all my scripts to use sftp:// transport instead of bzr+ssh:// now.
[03:53] <jamesh> bratsche: you can also use the BZR_REMOTE_PATH environment variable to run a different bzr executable on the remote end
[03:53] <jamesh> e.g. BZR_REMOTE_PATH=/path/to/bzr bzr push bzr+ssh://server/...
[03:58] <bratsche> Thanks james
[03:58] <bratsche> h
[04:32] <lifeless> bratsche: generally you should run the latest bzr server version, all clients can use any version
[04:33] <lifeless> bratsche: we add new network verbs rather than changing the meaning of old ones
[04:34] <bratsche> lifeless: Cool, good to know.
[04:34] <bratsche> lifeless: Thanks a lot!
[04:41] <lifeless> bratsche: we will probably do some bulk removal of old slow methods at some stage; we'll advertise that very clearly when we do :)
[04:43] <lifeless> another method bytes the dust of deprecation
[04:44] <bratsche> We'll probably never be -that- far behind you.  I think everyone at work pretty much upgrades their Ubuntu as the new releases come out.  Some of us upgrade to the betas a little sooner than some of the others. :)
[04:49] <lifeless> :P
[05:00] <jamesh> bratsche: you don't have the bzr PPA in your apt sources? :)
[05:01] <bratsche> Dude I don't even know what "the bzr PPA" is! :)
[05:45] <jamesh> bratsche: https://launchpad.net/~bzr/+archive
[06:07] <jml> hi
[06:08] <jml> I have a feature request that I'd like to sanity check.
[06:08] <jml> after pulling, I'd like to be able to:
[06:08] <jml> - figure out what I just pulled (log & diff)
[06:08] <jml> - 'undo' the pull
[06:09] <jml> is that sensible? is it possible?
[06:09] <Toksyuryel> doesn't it already support that?
[06:09] <jml> in that case, I'm requesting instructions, not features :)
[06:10]  * TFKyle sees a use for the former, normally just remembers where he last was and uses bzr visualize/bzr log though
[06:10] <TFKyle> (though, it does show what files have changed already when pulling iirc)
[06:10] <Toksyuryel> I imagine you'd do it the same way you do local commits
[06:10] <jml> TFKyle: I use version control so I don't *have* to remember things.
[06:10] <spiv> jml: "bzr pull -v" is part of the answer
[06:10] <mwhudson> i think the problem is know what the branch tip was before you pulled
[06:10] <Toksyuryel> diff the revsion numbers from before and after the pull, and uncommit the pull revno if you don't like it
[06:11] <TFKyle> could use tags liberally :D
[06:11] <mwhudson> knowING
[06:11] <mwhudson> the rest is easy enough
[06:11] <spiv> jml: that gives you logs
[06:11] <jml> spiv: that's certainly better than nothing.
[06:11] <jml> Toksyuryel: how do you figure out the revno from before the pull though?
[06:11] <spiv> jml: and you can easily figure out from that what the revnos to use for diff or "bzr pull -r OLD_REVNO"
[06:12] <Toksyuryel> jml: log
[06:12] <jml> spiv: that approach certainly requires the least amount of foresight.
[06:12] <jml> Toksyuryel: you'll have to be more specific.
[06:13] <Toksyuryel> jml: just use log the same way you use it for local commits
[06:13] <jml> Toksyuryel: you mean look until I find a revision that I recognise as being from before the pull?
[06:13] <Toksyuryel> the commit for the pull should be clearly labeled, unless you're Doing It Wrong
[06:13] <spiv> jml: add a "pull=pull -v" alias to your bazaar.conf?
[06:14]  * jml is Doing It Wrong apparently
[06:14] <TFKyle> Toksyuryel: afaik pull doesn't require commits, just merge
[06:14] <Toksyuryel> TFKyle: isn't undoing it the same function though?
[06:14] <jml> spiv: right, that lowers the foresight factor even more.
[06:14] <spiv> jml: what foresight is still required?
[06:15] <Toksyuryel> as I recall any change gets logged and compressed in the store, which would include snapshots of before and after merges
[06:15] <jml> spiv: none. :)
[06:15] <TFKyle> Toksyuryel: merges yes, but I don't think pull operations
[06:15] <spiv> jml: ah :)
[06:15] <TFKyle> (could be wrong though, just they aren't mentioned in bzr log/etc.)
[06:16] <Toksyuryel> TFKyle: then that should be a feature to be added, as it would help streamline things a great deal
[06:16] <Toksyuryel> I always thought pull was handled like a merge
[06:18] <TFKyle> (though, for the undo part you might actually want to use merge/commit)
[06:18]  * Toksyuryel afk to watch a movie
[06:18] <spiv> Toksyuryel: pull is basically "update my local mirror of a remote branch"
[06:19] <Toksyuryel> spiv: ohhh, I see
[06:19] <Toksyuryel> that makes sense then
[06:19] <spiv> Much like push in the other direction :)
[06:19] <spiv> Toksyuryel: enjoy the movie
[06:19]  * Toksyuryel afk for reals now
[06:36] <ubotu> New bug: #213769 in bzr "KnitCorrupt thrown when doing diff" [Undecided,New] https://launchpad.net/bugs/213769
[06:36] <ubotu> New bug: #213771 in bzr ""not updating child fraction" filling up log file" [Undecided,New] https://launchpad.net/bugs/213771
[08:16] <ubotu> New bug: #213792 in bzr "status display of pending merges is slower than merge" [High,Confirmed] https://launchpad.net/bugs/213792
[09:19] <sssslang> hi, i'm a little confused. could someone tell me how to make revno like x.x instead of x? i wanna use x.x to tag little changes in my programs.
[09:19] <Toksyuryel> spiv: thanks, I did ^^
[09:20] <Toksyuryel> sssslang: revnos are just for tracking commits, you can use the "tag" function for actual releases or really anything you want
[09:21] <Toksyuryel> the dotted format of revnos is used for tracking merges, so it would be confusing to also use it to mean "minor commit" (which is usually redunant, since most commits are minor)
[09:21] <spiv> Toksyuryel: :)
[09:22] <Toksyuryel> spiv: I watched "Into The Wild". It was an interesting take on the book. I thought the ending was too gruesome though :(
[09:22] <Toksyuryel> but overall, worth watching
[09:24] <sssslang> Toksyuryel: thanks. so you mean i should always use bzr ci wheather the changes are major or minor, and tag the former with bzr tag?
[09:25] <Toksyuryel> sssslang: revnos aren't version numbers, it'd helpful not to think of them as if they were
[09:25] <spiv> Toksyuryel: Ah, I've heard of that.  Thanks for the review!
[09:26] <Toksyuryel> since most commits are minor, it'd be better to tag the major ones (though generally a descriptive commit message works just as well)
[09:26] <Toksyuryel> spiv: you're welcome^^
[09:27] <sssslang> Toksyuryel: i see. thank you.
[09:27] <Toksyuryel> should read the book too, if you haven't. the movie kinda glosses over some of the details, and takes a few liberties with the story.
[09:29] <Toksyuryel> why is the bzr website rss feed useless =/ I just wanted to track news, not every single little change to the website itself >.<
[10:56] <ubotu> New bug: #213851 in bzr "bzr push error" [Undecided,New] https://launchpad.net/bugs/213851
[11:01] <Peng> That error is getting popular.
[11:01] <Kamping_Kaiser> grab yourself some karma ;)
[12:41] <asabil> hi all
[12:43] <asabil> is it technically feasible to come up with a repository/branch format that allows internal branches ?
[12:44] <asabil> in a similar manner to git ?
[12:44] <james_w> asabil: yes, it is.
[12:44] <james_w> there is some debate about the best way of doing that, but it is possible.
[12:47] <asabil> ok thanks
[12:47] <asabil> do you allow me to quote this on a mailing list ?
[12:47] <james_w> yeah, go ahead.
[12:48] <asabil> thanks
[12:48] <asabil> it seems to be one of the most wanted features among GNOME developpers
[14:14] <Peng> jelmer: Is it dangerous to use the same svn-cache with 0.4.9 and the 0.4 branch?
[14:16] <jelmer> Peng: yes
[14:16] <Peng> Great.
[14:16] <jelmer> the 0.4 branch may put garbage in there
[14:19] <Peng> If it did screw it up, will it be obviously broken (instant traceback), or could weird subtle things happen?
[14:19] <Peng> How much of a pain would it be to just delete the whole cache, even for largish repos?
[14:20] <jelmer> deleting the cache shouldn't be much of a problem with >= 0.4.9
[14:20] <jelmer> weird subtle things could happen
[14:21] <Peng> Fun stuff.
[14:22] <Peng> Well, I needed to garbage-collect it anyway...
[14:24] <Peng> Whee, 0.4.9 tracebacked too; it just too longer.
[14:30] <jelmer> please file a bug :-)
[14:32] <Peng> Errrr, ok.
[14:35] <ubotu> New bug: #213946 in bzr-loom "After local branch of loom I receive unusable loom" [Undecided,New] https://launchpad.net/bugs/213946
[14:36] <Peng> Bug 213953
[14:36] <ubotu> Launchpad bug 213953 in bzr-svn "NoSuchRevision while importing http://svn.pyyaml.org" [Undecided,New] https://launchpad.net/bugs/213953
[14:36] <Peng> :)
[14:45] <ubotu> New bug: #213953 in bzr-svn "NoSuchRevision while importing http://svn.pyyaml.org" [Undecided,New] https://launchpad.net/bugs/213953
[14:46] <Peng> Helpful, ubotu...
[15:20] <mw-home> simple bzr question.  is it true to say that generally, the working copy is the repository?
[15:21] <mw-home> If so, how do I back up my repository?
[15:22] <radix> mw-home: no. the repository is in .bzr/repository :-)
[15:22] <radix> mw-home: generally, the way to back up bzr stuff is to push a branch somewhere.
[15:28] <mw-home> radix: thanks.  Maybe I should schedule a daily cron job to push out my repo to another server.  Is that really the recommended way to back up>?
[15:29] <radix> mw-home: I recommend it :)
[15:33] <mw-home> is it possible to compare the status of one branch vs another?
[15:35] <mw-home> before I do bzr push, I want to know what WOULD happen.
[15:35] <radix> mw-home: I'm guessing at what you want, but it may be "bzr missing"
[15:36] <radix> It tells you which revisions your branch has that the other doesn't, and vice versa
[15:36] <mw-home> radix: yeah, bzr missing looks right.  thanks!
[15:41] <jelmer> Peng: funnily enough, this bug is fixed in the 0.4 branch
[15:42] <Peng> jelmer: Hah.
[15:44] <mw-home> I'm having a hard time understanding branch in bzr vs branching in subversion.  in svn, many branches exist inside the same repo.  in bzr, it seems like each branch is a separate repo.
[15:44] <Peng> mw-home: Yeah.
[15:44] <mw-home> so, in bzr, do people merge and destroy branches in the same way?
[15:45] <Peng> mw-home: Err.
[15:45] <Peng> mw-home: Ok?
[15:45] <Peng> mw-home: You can merge between branches (unlike svn, it actually works, but that makes cherrypicking difficult), and you can delete any rbanch you want..
[15:47] <mw-home> i think i just need to keep using bzr and over time hopefully it will become intuitive.
[15:49] <Peng> :)
[15:49] <Peng> Well, it's supposed to be intuitive from the start...
[15:49] <Peng> Have you been reading the docs?
[15:51] <mw-home> yeah, been reading.  i like the different workflows.  very good.
[15:51] <mw-home> very nice pictures too.
[16:00] <awilkins> mw-home: You can branch with a shared repo, consumes less disk space and is a lot faster for big repos
[16:00] <mw-home> awilkins: thanks.
[16:00] <mw-home> bzr vimdiff won't play nice with -c 876.
[18:34] <abentley> mw-home: Only certain commands support -c, and vimdiff is a plugin that was written long before it.  However, diff --using vimdiff ought to work with -c.
[19:03] <mw-home> abentley: I tried bzr diff --using vimdiff. Got an error: $ bzr diff -c 512 --using vimdiff ../__init__.py
[19:03] <mw-home> [19:03] <mw-home> Vim: Warning: Output is not to a terminal
[19:04] <abentley> mw-home: Do you have the diffutils plugin installed?
[19:05] <mw-home> abentley: i don't think so.
[19:05] <mw-home> diffutils isn't listed on the plugins page.
[19:06] <abentley> Ah, it's because I actually use gvimdiff.
[19:06] <mw-home> abentley: you use --using gvimdiff?
[19:06] <abentley> yes.
[19:07] <mw-home> ok, --using gvimdiff works fine.  Thanks!
[19:07] <abentley> No problem.
[19:07] <abentley> I guess interactive console differs don't play nice with --using.  Non-interactive ones like colordiff work fine.
[19:08] <mw-home> what is colordiff?
[19:08] <mw-home> never mind
[20:19] <Vantage> hi, does bzr support bzr switch for heavyweight checkouts or is it still just for lightweight checkouts?
[21:23] <jsled> I'm in a locally-repeatable siutation where `bzr push bzr+ssh:[…]` seems to terminate with return code 0 after a few (~20) seconds on the server, but does nothing on the client for many minutes, when it eventually times out.
[21:23] <jsled> This leave an open lock on the server side, and no actual push being accomplished.
[21:23] <jsled> How to go about debugging?  How to get the '-v' passed to `bzr server` when its invoked on the server side?
[21:25] <james_w> jsled: do "bzr -Dhpss push bzr+ssh://" and read ~/.bzr.log afterwards, that may provide some clues
[21:25] <james_w> also ssh to the server and read ~/.bzr.log there as well
[21:25] <james_w> (by read I mean read the end).
[21:25] <jsled> The server's ~/.bzr.log is where I'm seeing the timing and "return code 0".
[21:26] <james_w> ah, there's no other message?
[21:26] <jsled> There are some other lines about loading plugins, arguments and encoding.
[21:26] <jsled> they look innocuous, but I can pastebin if you like.
[21:27] <james_w> yes please, there might be something.
[21:27] <jsled> http://pastebin.ca/977410
[21:28] <james_w> yeah, that's really helpful isn't it.
[21:28] <james_w> does -Dhpss on the client tell you anything?
[21:28] <jsled> That's from running it as `bzr -Dhpss push` (with a previously-remembered path); the client side is still sitting there.
[21:28] <james_w> ah, -Dhpss only affects the client.
[21:29] <jsled> No; no extra detail ("-Dhpss"?   How should I expand/read that?  Is it a acronym or mnemonic or?)
[21:29] <james_w> what may work is to use BZR_REMOTE_PATH to change the arguments it is invoked with
[21:29] <james_w> however that may just fall over and tell you it can't find "bzr -Dhpss" or something.
[21:33] <jsled> If I do something like `BZR_REMOTE_PATH=/usr/bin/bzr serve -v`, then it ends up running {/usr/bin/bzr serve -v serve --inet […]} on the server, which fails.
[21:33] <jsled> Er.  Something like... `BZR_REMOTE_PATH="/usr/bin/bzr serve -v" bzr break-locks`
[21:34] <james_w> what about "BZR_REMOTE_PATH=/usr/bin/bzr -Dhpss"?
[21:35] <jsled> "return code 0" after 18.386 seconds. :(
[21:35] <jsled> And a client just sittin'.
[21:37]  * jsled tries BZR_REMOTE_PATH="strace bzr"...
[21:41] <james_w> :-)
[21:43] <mwhudson> yikes
[21:45] <jsled> The last things I see are a series (~4) of read(0, "[…]"..., ...) = 16384.  then a "read(0, ", and nothing else.
[21:46] <jsled> On the server side, 0 is stdin (IIRC?)... so it's maybe waiting on reading pushed data from the client side?
[21:46] <james_w> you don't have anything like a ssh proxy in the middle do you?
[21:47] <jsled> Not that I'm aware of.  There is a 15-25% packet loss near the server, but a separate interactive SSH to the same box is fine.
[21:47] <jsled> I thought it might be the EscapeChar, but I updated ~/.ssh/config for that host without change.
[22:04] <jsled> Hmm.  When using bzr+ssh over a vpn rather than public internet, it looks like it's working.
[22:22] <Stavros> hello
[22:22] <Stavros> i have set up a read-only repo and want other people to send me their patches with bzr send
[22:23] <Stavros> what is the best way for them to send me them on a per-feature basis?
[22:23] <Stavros> obviously i'd think that one big send with a few commits for various features wouldn't work, since i want to pick and choose, correct?
[22:24] <beuno> Stavros, that sounds a bit of a workflow problem rather than a setup problem
[22:25] <Stavros> hmm
[22:25] <beuno> how can you restrict users to specific features?
[22:25] <Stavros> not users, programmers
[22:25] <Stavros> i want to screen all new features before committing them in the main repo
[22:25] <beuno> unless, of course, you have a branch per feature, which might be a bit messy depending on what the project looks like
[22:25] <Stavros> hmm, yes
[22:25] <beuno> Stavros, well, you have PQM that might help
[22:25] <beuno> and bundlebuggy, which might be a bit too hard to setup
[22:26] <Stavros> it's not a big project, so i want to avoid setting up complicated stuff if i can :/
[22:26] <Stavros> it's really mostly a matter of "how do i get someone to send me three features separately"
[22:26] <beuno> Stavros, ask them to  :)
[22:26] <beuno> make them setup feature branches
[22:26] <Stavros> ah, feature branches
[22:26] <beuno> work on a feature in each branch
[22:26] <Stavros> and then do "bzr send" from each one?
[22:26] <beuno> yeap
[22:26] <Stavros> good good, that's what i was thinking
[22:27] <beuno> keep a main one updated to compare to
[22:27] <Stavros> and how do i commit these patches when i decide to?
[22:27] <Stavros> yes
[22:27] <beuno> Stavros, bzr merge file.patch
[22:28] <lamalex> Can I undo a bzr merge of a patch?
[22:28] <beuno> lamalex, you can revert to a previous commit with either bzr uncommit, to erase that it ever happened
[22:28] <Stavros> oh, thanks
[22:28] <beuno> or you can do bzr revert -r X
[22:28] <beuno> to revert to a specific revision
[22:29] <beuno> and commit that, which will leave a history of what happened
[22:29] <Stavros> is pqm hard to set up?
[22:29] <beuno> Stavros, AFAIK, yes  :)
[22:29] <Stavros> ah :/
[22:29] <Stavros> is there a working example of it anywhere?
[22:29] <Stavros> or a description of what it is exactly?
[22:29] <beuno> Stavros, lemme look
[22:29] <Stavros> or both? :P
[22:31] <beuno> Stavros, all I can fine is: http://bazaar-vcs.org/IanClatworthy/CoreDeveloperHandbook?#an-overview-of-pqm and https://launchpad.net/pqm
[22:31] <lifeless> beuno: pqm is not relevant here
[22:31] <Stavros> lifeless: where?
[22:31] <lifeless> Stavros: I suggest 1 branch per feature; if you have features that depend on each other, use looms
[22:32] <lifeless> pqm is for enforcing merge policies
[22:32] <Stavros> lifeless: oh, that's what i'll do, i was just asking about pqm out of curiosity... what are looms?
[22:32] <beuno> lifeless, right, I understood this later on in the conversation
[22:32] <lifeless> you want to screen features yourself, so pqm is unrelated
[22:32] <lifeless> Stavros: https://launchpad.net/bzr-loom
[22:33] <Stavros> oh hmm, thanks
[22:33] <beuno> right, bundlebuggy might be more appropriate for that, but I think it doesn't fall under the "easy to setup" category either
[22:33] <Stavros> eh, how hard can it be :P
[22:34] <Stavros> oh
[22:34] <Stavros> quite hard, it seems :p
[22:34] <Stavros> it's ok, i'll do this by hand then, it's just one person anyway
[22:35] <Stavros> pqm looks nice for automated testing etc
[22:35] <Stavros> really handy
[23:03] <lifeless> abentley: ping
[23:03] <lifeless> abentley: I'm changing knit annotation
[23:03] <abentley> lifeless: on a call
[23:04] <lifeless> abentley: ok; I'll just dump here and you can comment when you have a chance
[23:05] <lifeless> Basically I'm adding a iter_annotations to access annotation across multiple things; this seems in line with other changes
[23:05] <lifeless> The top level questions are: do you think this is a good thing to do, and what should the signature/api be. I think that annotations are more likely to be order-sensitive than regular file texts.
[23:08] <lifeless> so I'm planning on iter_annotations(iterable of keys) -> iterable of the annotations in the order of the key iterator
[23:08] <lifeless> the alternative I was considering was
[23:08] <lifeless> iter_annotations(iterable of keys) -> iterable of (key,  annotation) in any order - allowing memory/speed tuning within the memory
[23:09] <lifeless> a third alternative is to just keep the annotate a single text interface
[23:10] <lifeless> opinions solicited
[23:10] <lifeless> an orthogonal question is whether each individual annotation should be a list or an iterator
[23:11] <lifeless> for now I'm intending an iterator because annotate_iter seems to be the preferred api
[23:12] <lifeless> oh, and I think the final thing is whether to yield None, or to raise RevisionNotPresent for absent keys
[23:12] <lifeless> given the ability to hand iterators around, I feel like yielding None
[23:14] <abentley> I think None is usually a better answer for bulk operations.
[23:14] <abentley> I don't see a great need for iterating many files at a time.
[23:15] <abentley> Or even many versions of the same file.
[23:15] <lifeless> so the easier thing to do then is just to deprecate one of annotate/annotate_iter
[23:16] <lifeless> which would you rather keep? (I'm asking you because you've used annotate more than anyone I think)
[23:18] <abentley> I think annotate.  Realistically, the first thing I do with annotate_iter is listify it.
[23:18] <lifeless> ok
[23:18] <lifeless> one annotate_iter deprecation coming right up
[23:20] <abentley> Since annotate is currently a slow operation, it would be nice to have an interface that provided incremental updates.  But that's something for another time, I expect.
[23:33] <lifeless> abentley: done; testing
[23:33] <lifeless> abentley: I'm nearly at the end of trimming the api; yay
[23:34] <abentley> Cool.
[23:37] <lifeless> 6 patches sent to BB yesterday I think
[23:41] <abentley> Yeah, the pending queue is back up to 36
[23:41] <abentley> After we'd gotten it down to 25.
[23:44] <lifeless> mark hammonds document is kinda unweildy to review
[23:49] <Stavros> is there a way to get bzr to output the patch file it would send with "bzr send"? (mail client problems)
[23:49] <beuno> Stavros, bzr send -o file.patch
[23:50] <Stavros> oh, thanks!
[23:51] <Stavros> i can't believe i missed that
[23:51] <lifeless> or -o-
[23:51] <Stavros> is that for stdout?
[23:55] <lifeless> yes
[23:55] <Stavros> ah, thanks
[23:55] <lifeless> you can also use diff -r submit: to see the patch without a bundle at all
[23:56] <Stavros> hmm, i have a patchfile but "bzr merge file.patch" won't do anything
[23:56] <Stavros> well, it does say "Nothing to do."
[23:57] <lifeless> is it a bundle (was it made with send ?))
[23:57] <Stavros> yes
[23:57] <lifeless> then its probably a branch you've already merged :P
[23:58] <Stavros> oh wait
[23:58] <Stavros> the mail client prepended spaces to each line :/
[23:58] <Stavros> but now it tells me "revision 'blah' not present in 'inventory'"