[01:42]  * igc back in a few hours
[03:55] <spm> *** FYI. Launchpad Codehost will be going down shortly for a code update. ~ 5-10 mins before I'll be doing so; ETA of outage < 30 secs, all going well. ***
[04:05] <spm> *** About to restart Launchpad codehost for a code update ***
[04:07] <spm> *** all done ***
[05:40] <TimMiao> hello, I'm a newbie on bzr, I have an issue when I'm going to bzr launchpad-login with my id, it always tells me:
[05:40] <TimMiao> bzr: ERROR: Connection error: curl connection error (error setting certificate verify locations:
[05:40] <TimMiao>   CAfile: /etc/curl/curlCA
[05:40] <TimMiao>   CApath: none
[05:40] <TimMiao> )
[05:40] <TimMiao> on https://launchpad.net/~tim-miao/%2Bsshkeys
[05:40] <TimMiao> I'm sure I've uploaded my public rsa key, what's the problem?
[05:40] <bob2> heh curl
[05:40] <TimMiao> I'm using the bzr on OpenSolaris 2010.03 release
[05:43] <TimMiao> bob2: excuse me?
[05:43] <TimMiao> bob2: would you please give me some clue in detail? thanks! :)
[05:43] <bob2> no, sorry
[05:52] <igc> back
[05:58] <poolie> bob2, that was kind of harsh
[05:58] <bob2> sorry :| I misread it as being from get, so was going to suggest http+urllib
[05:58] <bob2> but then realised I had no idea
[06:00] <bob2> s/get/branch/
[06:01] <poolie> i would guess he was trying to lp-login and it's trying to send xmlrpc over ssl
[06:01] <poolie> and that's failing
[06:04] <poolie> k, sprint stuff sent
[06:56] <vila> hi all !
[07:21] <poolie> hi vila
[07:21] <vila> hey poolie !
[07:24] <vila> poolie: I'll submit a fix shortly for bug #474807 and I did apply for patch piloting this week
[07:27] <vila> poolie: since the active review list is mainly from core, I plan to dig the wip queue and maybe have  a look at the bugs with patches
[07:28] <poolie> hey, that's pretty good
[07:28] <poolie> i barely saw you last week, being away and then having some activities in the evening
[07:29] <vila> I paused a bit on the merge stuff, concentrating on some plugin paths and log bugs, thanks for the past reviews and even more thanks for the coming ones ;-)
[07:29] <poolie> that's ok
[07:30] <poolie> i spent today mostly doing some clerical things, including getting organized for Belgium
[07:30] <poolie> i'm planning to take a holiday in the week after easter
[07:30] <vila> there are two merges (well conflicts really) submissions waiting for review anyway
[07:30] <vila> coll
[07:30] <vila> cool
[07:35] <dcoles> Anyone got an idea why `bzr serve --git` is currently hard coded to localhost?
[07:35] <poolie> in what sense?
[07:37] <dcoles> poolie: The serve_git function in server.py (of the bzr-git plugin) calls "server = TCPGitServer(backend, 'localhost')"
[07:37] <dcoles> (At the very bottom of the file)
[07:37] <dcoles> I'm just checking if trunk is the same
[07:39] <dcoles> Yup. In trunk too
[07:39]  * dcoles opens a bug
[07:45] <vila> gah, there are days....
[07:45] <vila> I read the above 'In trunk too' as '"I'm drunk too" and then 'opens a bug' as 'opens a mug'....
[07:45]  * vila get more coffeee
[07:46] <dcoles> Hahaha
[07:57] <dcoles> bug 543998
[07:58] <dcoles> Looks pretty simple. I might try and write up a patch on the train home.
[08:07]  * igc dinner
[09:35] <bialix> Heya GaryvdM
[09:36] <GaryvdM> Hi bialix
[09:36] <bialix> I'm thinking about starting packaging 0.18.4
[09:36] <GaryvdM> I've just committed some tests for treewidget select all.
[09:37] <GaryvdM> bialix: Cool. Let me know If I can help at all.
[09:38] <GaryvdM> bialix: I'll do 0.19b1 on Wednesday (24th) evening.
[09:39] <bialix> GaryvdM: you can help, yes. Can you confirm I can start 0.18.4 or you have some plans?
[09:40] <GaryvdM> bialix: Yes you can start on 0.18.4.
[09:40] <bialix> GaryvdM: ok, I've let the 0.19b1 for you then
[09:41] <GaryvdM> bialix: I'm working on some stuff for trunk. So I want to leave 0.19b1 for the last minute.
[09:41] <bialix> ok
[09:41] <bialix> in the end it's b1
[09:41] <GaryvdM> Yes :-)
[09:43] <bialix> GaryvdM: I have last revno 1227 in 0.18 branch. (Restore test removed by rev 1225.) That's correct?
[09:43]  * GaryvdM looks
[09:43] <bialix> GaryvdM: can you skim through NEWS?
[09:44] <bialix> GaryvdM: and one more thing: do you have a tree name for this release ;-) ?
[09:44] <dcoles> jelmer: Have you seen bug 543998
[09:44] <bialix> GaryvdM: what about bug #533837?
[09:47] <GaryvdM> bialix: The revision is correct. NEWS has every thing. (Except test improvements, which I don't think should be in NEWS)
[09:48] <bialix> GaryvdM: do you have objections for codename "pussy-willow"?
[09:49] <GaryvdM> Sounds good: http://en.wikipedia.org/wiki/Pussy_willow
[09:50] <bialix> yes, it is
[09:51] <GaryvdM> bialix: I'm looking at bug 533837.
[09:51] <GaryvdM> I did not target that bug btw.
[09:52] <bialix> GaryvdM: it seems igc has assigned it to you and to 0.18.4. I've removed milestone assignment
[09:53] <GaryvdM> bialix: Ok - I'm not going to look at it now. I'm going to stay focused on what I'm doing (treewidget stuff)
[09:53] <bialix> GaryvdM: that's great
[09:58] <vila> bialix, GaryvdM : Hi guys !
[09:58] <bialix> bonjour vila!
[09:59] <vila> GaryvdM: Test improvements in NEWS give *me* a warm feeling of confidence ;-)
[09:59] <GaryvdM> Hi vila
[10:04] <bialix> qbzr 0.18.4 released. w00t!
[10:04] <jelmer> dcoles: yep
[10:05] <jelmer> dcoles: I'd consider that a low-priority bug, we need more testing of the server first
[10:05] <dcoles> Ah. OK.
[10:06] <dcoles> Wasn't quite sure of it's status, though it's been mighty handy of late :)
[10:06] <bialix> it seems vila enjoyed piloting :-)
[10:07] <jelmer> dcoles: so it's working ok for you?
[10:08] <dcoles> jelmer: For a very trivial repository, yes. I might just try something more complex
[10:10] <dcoles> jelmer: Though it appears to be serving the wrong branch...
[10:11]  * bialix finishes the qbzr release
[10:14] <dcoles> jelmer: It seems to be a tad confused in a shared repository. Regardless of how I try and clone, it grabs the first branch I pulled
[10:15] <dcoles> (I have 2 branches in this directory)
[10:16] <jelmer> bialix: \o/
[10:16] <bialix> hi jelmer, thank you!
[10:16] <jelmer> dcoles: how are you cloning from it, git clone ?
[10:16] <dcoles> Yup
[10:18] <jelmer> IIRC it should just grab all branches in that case
[10:19] <dcoles> I tried git clone git://localhost/nonexistantfoo and I still get the same branch
[10:19] <dcoles> This is even if I try and serve from the other branch (rather than the shared repo)
[10:22] <dcoles> Though I notice that `bzr serve --proto=bzr` refuses to branch when it's not run from the shared repo
[10:23] <mobby> Hi, I wonder if anyone would be able to help me please? I'm doing a lightweight checkout of an svn repo and it is failing with an "Unable to find old fileid for..." for a file in the svn repo. Any ideas what would cause this?
[10:24] <vila> fullermd: quick check on FreeBSD8, is /var/crash the right and only place to search for left over dumps after a hard crash ? (One that required running fsck and then some)
[10:25]  * vila shudders, rats, crashing again :(
[10:26] <jelmer> dcoles: hmm, that's probably a bug :-(
[10:27] <dcoles> jelmer: Ok. I'll see if I can reproduce the circumstances and file it
[11:15] <gioele> hello
[11:16] <gioele> is there a public installation of the current trac-bzr?
[11:19] <bialix> gioele: do you mean: to see it in action?
[11:20] <gioele> bialix: yes
[11:21] <bialix> I'm not sure about "current"
[11:21] <bialix> but there was some open-source project using it
[11:22] <bialix> what exactly you want to see?
[11:23] <bialix> jelmer: do you know any existing public server with trac-bzr?
[11:26] <gioele> bialix: I would like to see how it looks like: how branches are managed, whether relationships between branches are shows, how the timeline looks like, etc.
[11:27] <bialix> branches are not managed
[11:27] <bialix> relations between branches is not shown
[11:27] <bialix> I'm using it at my work
[11:27] <bialix> timeline shows revisions on;y for the mainline
[11:27] <bialix> *only
[11:28] <gioele> bialix: "how branches are managed" as in "how multiple branches in the same shared repo are shown"
[11:28] <bialix> gioele: as directories
[11:28] <bialix> lemme show you some images
[11:29] <gioele> bialix: so basically it still looks like http://bugs.bitlbee.org/bitlbee/browser
[11:30] <bialix> gioele: here http://imagebin.ca/view/ZrY9m2.html
[11:30] <bialix> gioele: yes
[11:31] <bialix> gioele: do you know do they're using trac-bzr or ?
[11:32] <gioele> bialix: they = bitlbee? Yes, I think so: that page is linked from the old wiki page of TracBzr
[11:33] <bialix> yes, bitlbee
[11:37] <tenchi> hello
[11:38] <tenchi> I'm using bzr in ubuntu with Bazaar Explorer. is there any way to export my projects log history (in html format)?
[11:39] <bialix> gioele: there is also [[Branches]] macro to use in wiki pages
[11:39] <bialix> tenchi: no, we don't have such feature yet
[11:39] <bialix> tenchi: but there is special plugin to do so
[11:39] <bialix> check htmllog
[11:40] <bialix> also there is xmloutput plugin do support xml output of some commands
[11:40] <tenchi> thx, will google it
[11:41] <tenchi> also: using hungarian characters in the commit text provided some errors
[11:41] <tenchi> are you working on utf8-ing it?
[11:42] <gioele> tenchi: is should be unicode/utf8 clean
[11:42] <gioele> tenchi: what did you use to read the commit log?
[11:42] <bialix> tenchi: I'm working with Russian and it's fine (on Windows)
[11:42] <tenchi> hmmm
[11:42] <bialix> tenchi: make sure you have correct LANG settings
[11:42] <tenchi> just checked it and it works
[11:42] <tenchi> strange
[11:43] <tenchi> will tray again at next commit
[11:43] <tenchi> typed all texts in english because of this
[11:44] <gioele> tenchi: I have been using Italian accents and German vowels for quite a long time and everything seems fine
[11:45] <bialix> tenchi: http://michael.ellerman.id.au/bzr/plugins/htmllog
[11:45] <tenchi> ok, will not whine if it works :-D
[11:45] <tenchi> When I first tried there was some error but I can't remamber what...
[11:45] <bialix> tenchi: ghosts
[11:52] <tenchi> I just tried the gnulog plugin and it works fine for me :-D
[11:54] <bialix> omg
[12:05] <LeoNerd> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572109  <== anyone know if this bzr-svn bug is going to be fixed any time soon?
[12:05] <LeoNerd> I'm sure it can't be that hard, and I'd really appreciate being able to 'bzr shelve' in my svn checkouts again
[12:05] <jelmer> LeoNerd: it's already fixed upstream
[12:05] <LeoNerd> Ah excellent
[12:06] <LeoNerd> Hmm.. if I bzr co a later copy of bzr-svn would that do it?
[12:06] <jelmer> LeoNerd: yeah
[12:06] <LeoNerd> OK thanks
[12:11] <aburch> Is it possible to use "bzr send" (or something else) to send only specific changes?
[12:11] <jelmer> aburch: you can give it a revision range
[12:13] <aburch> jelmer: "bzr send -r 1961..1962" still bundles two revisions (the same with -r 1962..1962, -r 1962) when the remote has rev 1960
[12:15] <LeoNerd> jelmer: Thanks; that fixes it. Have commented on the debian bug to this effect too; hopefully they'll pull it
[12:15] <jelmer> LeoNerd: they == me :-)
[12:15] <LeoNerd> Ah. :)
[12:15] <jelmer> aburch: What are you trying to do exactly ? Sending a bundle without those revisions seems pointless since the remote side won't be able to apply it.
[12:15] <jelmer> s/side/site/
[12:18] <aburch> jelmer: I fixed a bug and used "bzr send" to send the patch, now I fixed something else and wanted to send only the second commit upstream.
[12:20] <aburch> jelmer: Git could do this with "git format-patch -1".  As long as the patches do not depend on each other, upstream should be able to apply them seperately.
[12:21] <jelmer> aburch: bzr bundles in their current form are intended to keep history (e.g. revision ids stay the same), that's not necessarily the case for "git format-patch"
[12:22] <jelmer> aburch: I guess to answer your question: it's not possible at the moment, but please file a bug report about it.
[12:23] <aburch> jelmer: Hmm, ok.  Then I will either look into how Bzr handles branches or just use "bzr diff". (And file the report.)
[16:50] <dvheumen> hey lifeless, got time for a question about the high(er) level lock hooks?
[17:14] <jelmer> dvheumen: I think he's asleep, being in .au
[17:14] <dvheumen> ah right okay
[17:15] <dvheumen> are you up for a (simple) question by any chance?
[17:15] <jelmer> For certain values of "simple", sure :-)
[17:17] <dvheumen> jelmer, maybe you already caught on to that, the idea was that I'd implement a slightly "higher" level of lock hooks. I've been browsing around the code for a good location (or locations) and I think that, for the working trees, I could best implement it in the MutableTree class. But the MutableTree class only "implements" lock_write and lock_tree_write but no lock_read.
[17:18] <dvheumen> So I was wondering, was lock_read just forgotten, or should I take the implementation up to MemoryTree and WorkingTree classes
[17:18] <dvheumen> because lock_write and lock_tree_write only raise NotImplementedException and nothing more
[17:23] <dvheumen> I personally think I could best implement it in MutableTree, but I wanted to wait for some confirmation :)
[17:23] <dvheumen> ow w8, not it's not, it's stupid, because the actual locking implementation isn't there
[17:23] <dvheumen> nevermind
[17:24] <jelmer> dvheumen: MutableTree seems like the best place to me
[17:24] <jelmer> WorkingTree could be thought of as OnDiskMutableTree
[17:25] <dvheumen> jelmer, but then I could only do the implementation partially, right
[17:25] <jelmer> dvheumen: yes, but the interface would be on MutableTree
[17:25] <jelmer> dvheumen: how the subclasses of MutableTree call the hook is up to them
[17:25] <dvheumen> okay, that's exactly what I was thinking. okay tnx
[17:26] <dvheumen> in that case I also know what (approximate) level to choose for the branch and repository hooks :)
[17:52] <dark_soul> how can i use bzr to delete a branch?
[17:54] <mgedmin> is it difficult to define a custom location scheme a la lp:projectname?
[17:54] <mgedmin> it gets tiring to type bzr+ssh://servername/prefix/for/all/my/bzr/repos/ all the time
[17:58] <maxb> No, it's pretty simple, I suggest looking at how the launchpad plugin defines lp:
[17:59] <maxb> (which is slightly complicated only because it goes and hits an xml-rpc server to resolve the name)
[18:00] <jpds> mgedmin: http://pastebin.ubuntu.com/399436/
[18:00] <mgedmin> jpds, thanks, but it's a bit cryptic
[18:00] <mgedmin> is it ~/.bazaar/config?
[18:01] <jpds> mgedmin: ~/.bazaar/locations.conf
[18:02] <mgedmin> and what does it do?  lets be do cd ~/someproject/devell && bzr branch X  where X gets translated to prefix/X ?
[18:02] <jpds> mgedmin: You'll then be able to do: bzr push - from a branch and it will automatically go to lp~you/someproject/branchname
[18:03]  * mgedmin googles for locations.conf
[18:03] <mgedmin> thanks for the pointer
[18:03] <mgedmin> from what I see I'm not sure it's what I want, but I'll read
[18:06] <mgedmin> http://wiki.bazaar-vcs.org/ConfiguringBzr was not useful
[18:07] <mgedmin> no useful matches in wiki search
[18:08] <mgedmin> no matches at all in http://doc.bazaar.canonical.com/latest
[18:08]  * mgedmin searches for appendpath
[18:09] <mgedmin> that works better
[20:00] <beuno> gar
[20:00] <beuno> I have a newbie question  :)
[20:00] <beuno> I have a revno that removed stuff
[20:00] <beuno> I want to revert only those changes
[20:01] <beuno> revert seems to not be what I want
[20:01] <beuno> and merging in that revision, or 111..112 (assuming 112 is the revno I that I want to revert) doesn't work either
[20:02] <james_w> merge -r 156..155 will undo the changes that you see with diff -c 156
[20:03] <beuno> of course, the other way around
[20:03] <beuno> *sigh*
[20:03] <beuno> thank you james_w   :)
[20:17] <NfNitLoop> hehe.
[20:49] <codygman> If I create a branch, then merge the changes, would I be able to revert back to that at any time?
[20:50] <codygman> or should I say... could I create a branch, commit, then revert back to what it was before that, while keeping the branch
[20:51] <GaryvdM> codygman: Yes.
[20:51] <codygman> alright cool
[20:51] <GaryvdM> codygman: You can do bzr uncommit
[20:52] <codygman> well here's what i'm trying to do
[20:52] <codygman> i'm experimenting with different facebook connect solutions on my django site.. and i'd like to keep note of each one
[20:52] <codygman> and be able to revert to the one i like
[20:53] <GaryvdM> codygman: for that, I would make a branch for each solution.
[20:53] <GaryvdM> codygman: And merge the one you want.
[20:53] <codygman> the branches stay until i delete them right?
[20:53] <GaryvdM> codygman: Yes
[20:54] <GaryvdM> codygman: or pull the one you want if you have no other commits in your main branch.
[20:54] <codygman> Thanks!
[20:54] <codygman> I have quite a few other commits lol
[20:58] <poolie> hi jam?
[21:00] <codygman> bzr branch "name of my branch" isn't the right syntax huh
[21:00] <codygman> is their anything similiar to that?
[21:00] <codygman> similar*
[21:00] <poolie> codygman: it's "branch FROM TO"
[21:00] <poolie> what do you want to do?
[21:00] <codygman> I just want to test out different facebook connect solutions on my django website
[21:00] <codygman> then be able to revert to the one I like most
[21:01] <poolie> ok, and they're already in different bzr branches? or you're going to write things in different branches?
[21:01] <codygman> there is currently only the master branch
[21:02] <codygman> basically.. I want to be able to revert to my website without the facebook connect plugins.. code the solution.. then do it for the other 2 possible solutions
[21:02] <codygman> and be able to revert to the one I like best
[21:03] <GaryvdM> codygman: (in the dir above master) bzr branch master solution1
[21:03] <GaryvdM> Hi poolie
[21:05] <codygman> then when I want to test.. I just merge right?
[21:05] <codygman> bzr merge solution1 master ?
[21:07] <GaryvdM> codygman: Run mange.py runserver in the branch
[21:07] <codygman> well.. this is actually on an apache server.. that's why i'm trying to get everything working in that directory
[21:08] <GaryvdM> Ok, 2 options:
[21:09] <GaryvdM> 1. use the bzr-colo plugin
[21:09] <GaryvdM> that allows you to have more than one branch in the same dir.
[21:11] <GaryvdM> 2. step 1: branch apache-dir ~/proj/master
[21:11] <poolie> hi gary
[21:12] <GaryvdM> step 2: edit  apache-dir, commit, push ~/proj/solution1
[21:13] <GaryvdM> step 3: (in apache-dir) bzr pull ~/proj/master
[21:13] <GaryvdM> go back to step 2 repeat
[21:14] <GaryvdM> when you chose, pull master, then merge concision solution.
[21:14] <GaryvdM> codygman: ^
[21:15] <codygman> I'm reading! Thanks for that. I think i'm going to try the bzr-colo plugin
[21:15] <codygman> if i can't do it with that, i'll use option 2
[21:16] <GaryvdM> codygman: I would recomend trying: branch into your home dir, and run with ./manage.py runserver
[21:16] <fullermd> vila: Yes, that's where crashdumps get copied to on boot, unless you change it.
[21:17] <GaryvdM> codygman: I had good mileage with that when I was working with django.
[21:21] <codygman> you mean runserver?
[21:24] <GaryvdM> codygman: Yes, runserver, and working with branches in my home dir.
[21:28] <GaryvdM> night all
[22:00] <humphreybc> hi
[22:00] <humphreybc> we have a pretty big problem
[22:00] <humphreybc> our branch has randomly jumped back about 30 revisions and we're not sure why
[22:00] <humphreybc> we may have lost a crapload of work but not sure
[22:00] <humphreybc> http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/changes
[22:01] <humphreybc> it was on 565, but then we think it got screwed when Sayantan pushed something and merged
[22:01] <humphreybc> no we have people sitting on 554 testing it all over the palce
[22:01] <bob2> pushing can do that
[22:02] <humphreybc> so we've got a tonne of people (hundreds) who are testing an older version, but on a newer revision number
[22:02] <humphreybc> what happens now?
[22:02] <bob2> bzr log -n0
[22:02] <humphreybc> that command gives me 0 - 65
[22:02] <humphreybc> we've got 500+ revisions
[22:03] <bob2> it should give you a long and complicated nested log
[22:03] <humphreybc> i might need to turn up my line count in terminal
[22:04] <bob2> run it through less
[22:04] <humphreybc> it looks like we've lost about 30 revisions, 2 days worth of work
[22:04] <bob2> really?
[22:04] <humphreybc> yes
[22:05] <humphreybc> which isn't particularly cool
[22:05] <humphreybc> do you mind jumping in to #ubuntu-manual ?
[22:05] <bob2> ok, two thinsg: push can change rev order, so look carefully at the output of bzr log -n0
[22:05] <bob2> also, those revs still exist on the computers of whoever committed them, so even if someone broke launchpad, you can recover them
[22:05] <bob2> (msot likely)
[22:06] <bob2> http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/changes/525.1.17 < -s that the work you think is gone?
[22:07] <humphreybc> http://paste.ubuntu.com/399564/
[22:08] <humphreybc> and there is more, under rev 529.xx
[22:08] <humphreybc> but i'm presuming that stuff has been preserved?
[22:10] <humphreybc> http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/changes/525.4.25
[22:10] <humphreybc> that's more stuff that we had
[22:10] <humphreybc> is that stuff preserved, or is it gone?
[22:55] <mrooney> hey all! I've been searching around, is there something like a rebase, but that collapses your commits into just one?
[22:55] <mrooney> such as, I've made a bunch of commits , now I want to push it somewhere else as one
[22:56] <lifeless> bzr merge; bzr revert --forget-merges; bzr commit - that will discard the history of where the changes came from
[22:56] <lifeless> or if you just merge and commit, bzr log will, by default, show it as one change, and keeps the little details available if desired via log -n0
[22:58] <mrooney> lifeless: doesn't a simple merge squash the remote history, not the local history?
[22:59] <mrooney> or do I rebase and then merge, or something interesting
[23:03] <maxb> mrooney: You realize you could just uncommit multiple commits, then commit once?
[23:03] <mrooney> yeah certainly
[23:03] <mrooney> but as a workflow item, that's tedious and annoying
[23:04] <maxb> That's probably because squashing commits isn't a common workflow :-)
[23:04] <maxb> Why do you want to do it anyway?
[23:05] <lifeless> multiple uncommits + commit == merge ; revert --forget-merges, commit
[23:07] <maxb> yes, just depends whether you're already in a branch with the commits to be squashed
[23:14] <mwhudson> jelmer: ayt?
[23:14] <jelmer> mwhudson: otp
[23:15] <mrooney> maxb: I don't really, some people want to wrap our svn workflow and don't want all their local commits to end up as individual commits on the svn end
[23:18] <mwhudson> mkanat: https://bugs.edge.launchpad.net/loggerhead/+bug/513044/comments/6
[23:18] <jelmer> mwhudson: hello
[23:18] <mwhudson> jelmer: well, i have to admit i'm otp now too :)
[23:18] <mrooney> I'm hoping to convince them to just rebase and enjoy all the history being in svn
[23:18] <mwhudson> jelmer: but did you have time/brain energy to talk about incremental bzr-hg imports?
[23:19] <jelmer> mwhudson: I'm always excited to talk about bzr-hg imports!
[23:20] <mwhudson> jelmer: heh heh
[23:20] <mrooney> okay so if I can do a bzr branch of an svn repos
[23:21] <mrooney> and then someone else branches my branch, can they bzr push $SVN_REPOS without issue
[23:21] <mwhudson> jelmer: last time we talked, i think we decided that limiting in findmissing() would be too hard?
[23:21] <jelmer> mrooney: yes.
[23:22] <jelmer> mwhudson: yep
[23:22] <lifeless> yay, my new machine has shipped
[23:22] <mrooney> okay great
[23:23] <mrooney> and a silly question I think but one I've had a hard time googling an answer for
[23:23] <mrooney> if I've got a branch on my machine, what do I need to set up to have someone else be able to branch from it
[23:24] <mwhudson> jelmer: so where can you limit?
[23:24] <mwhudson> i guess i need to figure out what
[23:24] <mwhudson>         cg = self.source._hgrepo.changegroup(missing, 'pull')
[23:24] <mwhudson> is doing
[23:24] <mrooney> we're all on a LAN here, I've never figured out how to push and pull from another LAN machine
[23:24] <jelmer> mwhudson: you can't really limit what the server will send you, but you can limit how much you process
[23:25] <jelmer> mwhudson: cg is a unpacked hg bundle
[23:25] <mwhudson> oh ok, so addchangegroup needs to change?
[23:25] <jelmer> mwhudson: it contains three chunks of data in order - from memory: revisions, inventories and texts. We basically loop over all three and you'd need to limit how much processing you do in the first then skip irrelevant stuff in the second two loops.
[23:27] <mwhudson> jelmer: that sounds about right
[23:27] <mwhudson> i don't know what "skip irrelevant stuff" means in concrete terms
[23:29] <jelmer> mwhudson: inventories (manifests in mercurial jargon) that aren't referenced by any revisions that you're importing should be skipped as well as texts that aren't referenced by any of those manifests.
[23:29] <mwhudson> jelmer: sorry :-p
[23:29] <mwhudson> jelmer: i understood that much
[23:29] <jelmer> mwhudson: the revisions have references to the manifest ids
[23:30] <jelmer> and the manifests have references to the text ids
[23:30] <mwhudson> jelmer: ahh
[23:30] <mwhudson> so i'll need to keep track of some set()s i guess
[23:30] <jelmer> you might be able to leverage the existing datastructures
[23:30] <mwhudson> "referenced manifest ids" and so on
[23:30] <jelmer> since they try to keep track of what manifest is for what revision
[23:31] <RAOF> mrooney: SSH access should be sufficient for people to push/pull to/from you.
[23:31] <jelmer> and what mercurial file rev is for what bzr fileid/revid
[23:32] <mwhudson> jelmer: ok, that should be enough to keep me going until i have some more questions i guess
[23:32] <igc> morning
[23:34] <mrooney> RAOF: but would every user that wants to pull from me need a user on my machine?
[23:34] <jelmer> mwhudson: awesome
[23:34] <mrooney> is there any documentation I can read for this? I'm reading through http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html and such, but I can't find anything that tells you how to actually set up the sharing
[23:34] <jelmer> hi Ian
[23:52] <mrooney> jelmer: okay one more question for you, I can't create a --stacked branch of an svn branch, correct?
[23:52] <mrooney> but what happens if someone branches --stacked my branch, and then tries to push to svn?
[23:52] <jelmer> mrooney: no
[23:53] <jelmer> mrooney: If they --stacked your branch, that would work and they would be able to push
[23:53] <jelmer> you just can't stack on a svn branch
[23:53] <mrooney> okay so I can branch an svn branch, serve it with bzr serve, and people can branch --stacked and push back to svn all they like? that seems good!
[23:54] <mwhudson> jelmer: grar
[23:55] <mwhudson> jelmer: the unpack_chunk_iter makes live a little awkward to do this, maybe
[23:55] <mwhudson> ^ interface