[00:00] <hansin> you will see something like "auto lo".  what about "auto eth0" (or eth1, eth2...)?
[00:00] <enaner> yea
[00:00] <hansin> eth0?
[00:00] <enaner> no etho
[00:00] <hansin> just "lo"?
[00:01] <hansin> "auto lo"?
[00:01] <enaner> yea
[00:01] <enaner> lo
[00:01] <enaner> and then auto lo
[00:01] <enaner> actually
[00:01] <enaner> auto lo
[00:02] <hansin> okay.  you have an ethernet cable plugged into your router right? (just makeing sure there is an ethernet card/jack in server)
[00:02] <enaner> yea
[00:03] <enaner> i just unplugged it from the server and then repluged it
[00:03] <enaner> the green and orange light is on
[00:03] <hansin> okay, do this... "cd /etc/network"
[00:04] <hansin> by the way, what user are you logged onto the server as?
[00:04] <enaner> then
[00:04] <enaner> murgi
[00:04] <hansin> okay.  type "ls".  do you see a file called interfaces?
[00:04] <enaner> yea
[00:05] <enaner> itsthe only one thats white
[00:05] <hansin> we are going back it up before editing it.  type "sudo cp interfaces interface.bak"
[00:05] <enaner> rest of the results are blue/purplish
[00:06] <enaner> done
[00:06] <enaner> then?
[00:06] <hansin> type "sudo nano interfaces" (nano is a text editor)
[00:07] <hansin> tell me when it has loaded...
[00:07] <enaner> ok
[00:07] <enaner> then
[00:07] <enaner> its loaded
[00:07] <hansin> down arrow to the botton, below the "auto lo" entry...
[00:07] <enaner> then
[00:08] <hansin> type "# eth0" and press return (this is a comment)
[00:08] <enaner> then
[00:08] <hansin> type "auto eth0" and press return
[00:09] <enaner> then
[00:09] <hansin> type "iface eth0 inet dhcp"
[00:09] <enaner> then
[00:10] <hansin> hit "cntl-x" and nano should then ask you if you want to save/write file.  hit "y" for yes.
[00:10] <enaner> then
[00:11] <hansin> gimme a sec...
[00:11] <hansin> type "cd /etc/init.d"
[00:12] <enaner> then
[00:13] <hansin> cross finger... no, wait, do this...
[00:13] <hansin> type "./networking restart" and pay attention to output messages.
[00:14] <enaner> it says unknown methods
[00:14] <enaner> couldn't read interfaces
[00:15] <enaner> etc/network/interfaces
[00:15] <hansin> boo.. I am wondering if it doesn't recognize eth0.  type "lspci" and see if it repsond with a network card.
[00:16] <enaner> ethernet controller does show up
[00:17] <hansin> also try "dmesg | grep eth0" though probably no entries...
[00:17] <enaner> btw
[00:17] <enaner> the server comp is in another room
[00:17] <enaner> so im runnin bak n forth
[00:17] <enaner> so i dun think this will work
[00:17] <enaner> can i run ubuntu desktop edition
[00:17] <enaner> and still run a irc and http server?
[00:18] <hansin> you have a good pair of shoes??  sorry, didn't know you were running back and forth.  what kind/make/model of PC is the server?
[00:19] <hansin> I would really check "dmesg | grep -i eth" though and see if you get anything.  It could help if it is setting you card as ethX
[00:22] <hansin> on the bright side, hopefully you are learning a bit here.  even if you don't immediately retain all this, you are troubleshooting and developing that as a skill...
[00:22] <enaner> yea
[00:22] <enaner> but i gotta run now
[00:22] <enaner> thankx for all ur help
[00:22] <enaner> :)
[00:22] <hansin> okay, catch later if you want to try more.  need to figure out what you NIC card is registering as...
[00:32] <AtomicSpark> heh. the urge to restart an ubuntu server after updating it is still there. :3 been using windows too long.
[00:44] <Insomnia1ity> kernel update? :P
[00:50] <c1|freaky> ^^
[01:00] <zul> mathiaz: no idea
[01:40] <saltedlight> hi. is there any way to stop icmp replys using ufw? i have used "net/ipv4/icmp_echo_ignore_broadcasts = 1" on /etc/sysctl.conf but this is not working if ufw is enabled.
[02:35] <pubo> Hi
[02:36] <pubo> I'm looking for a wikiwikiweb clone to use in my office... do you know what is the best?
[02:36] <pubo> phpwiki? groupware-wiki? mediawiki?
[02:47] <Arrick> anyone know how to get the video in a Virtual PC 2007 VM to permanently start at vga=771 ?
[02:47] <Arrick> (server install for development)
[02:48] <Arrick> right now the video is way to large to read the login section, so its really hard to do anything on the local machine
[02:50] <qman__> if you edit the boot line during startup and add vga=771, it loads correctly?
[02:51] <qman__> if so, once it's booted, just edit /boot/grub/menu.lst and modify the boot line
[02:51] <qman__> make sure to change it in the commented section too, so the automagic kernel generator will update it with that option
[03:41] <ckad> help
[03:44] <hads> !ask
[04:03] <dbbolton> if the integrity check  on the cd gets 90-some percent through before finding a problem, how risky is it to go ahead with installation?
[04:03] <lukehasnoname> Run it again, if it fails again, trash it
[04:04] <lukehasnoname> unless it's a play server for testing
[04:04] <hads> And you don't care if your test might fail ;)
[04:04] <dbbolton> i checked the md5sum before burning it. is it possible that the disc was bad?
[04:07] <lukehasnoname> I don't know, perhaps
[04:07] <dbbolton> all right. i'm going to check it again. thanks
[04:07] <lukehasnoname> good luck
[04:07] <lukehasnoname> heh
[05:54] <nxvl> zul: ping
[07:39] <macGerhard> how do I set the default shell for a new user to bash?
[07:40] <kees> macGerhard: that should be the defaul.t
[07:40] <kees> check /etc/adduser.conf
[08:11] <ivoks> uvirtbot: relax, it's friday :D
[08:12] <soren> Heh... Yeah, sorry about that. I messued its network settings a few days ago, and I've been traveling so unable to fix it until just now.
[08:13] <soren> I doubt that's the last ones.. :)
[08:13] <ivoks> :)
[08:13] <ivoks> don't worry, we'll just ignore it, as we do will all other bugs :DD
[08:14] <ivoks> s/will/with/
[08:14] <soren> ivoks: :)
[08:18] <soren> Looks like we've got a lot of work to do... :/
[08:29] <ivoks> what?
[08:29] <ivoks> bacula doesn't fail
[08:29] <ivoks> ever.
[08:29] <ivoks> oh, that's the one i triaged already
[09:03] <macGerhard> kees: hey mate, sorry, had to leave
[09:03] <macGerhard> ok, so when I create a new user
[09:03] <macGerhard> although in adduser.conf
[09:03] <macGerhard> the default shell is set to bash
[09:03] <kraut> moin
[09:03] <macGerhard> the user that I have created has sh as the default shell
[09:03] <macGerhard> how can I change this to bash?
[09:04] <macGerhard> Nafallo: hey, you alive and kicking?
[09:05] <macGerhard> anyone? how do I change the default shell for user?
[09:19] <Nafallo> macGerhard: chsh
[09:34] <macGerhard> Nafallo: yep, figured it out eventually
[09:34] <macGerhard> how's the new job treating you?
[09:35] <Nafallo> macGerhard: busy busy
[09:35] <macGerhard> at least it's all ubuntu busy ;)
[09:35] <macGerhard> I got a new VM as well, decided to go with gutsy
[09:35] <macGerhard> hope I won't regret it
[09:35] <macGerhard> it's different from centos
[09:35] <macGerhard> and apache has a different conf
[09:35] <macGerhard> but it's just a new system I suppose
[09:35] <macGerhard> will you be around for tips and tricks :)
[09:36] <macGerhard> Nafallo: I didn't ask, but you do know who I am, don't you?
[09:39] <Nafallo> macGerhard: ya
[09:40] <Nafallo> macGerhard: like in, ya I know who you are.
[09:48] <macGerhard> Nafallo: ok, that's good then ;)
[09:48] <macGerhard> you'll be seeing me in this channel often, asking for help with ubuntu
[09:48] <macGerhard> just until I get my head around it ;)
[09:48] <macGerhard> cheers Nafallo, I must shoot now
[09:48] <macGerhard> catch you later mate ;)
[13:20] <sommer_> morning all
[13:32] <kaloyan> hi can someone tell me what the timestamp in dmesg and the logs represent
[13:42] <zul> hi sommer_
[13:44] <ScottK> soren: Is there a particular reason why network-manager-openvpn can't be updated in Debian and sync'ed?
[13:45] <soren> ScottK: Apart from availability of time, no.
[13:45] <soren> Oh..
[13:45] <soren> Er... That's not entirely true, actually.
[13:46] <soren> I believe Debian has a /etc/init.d/NetworkManager script, while we have a /etc/dbus-blah/blah/NetworkManager script..
[13:47] <ScottK> Yes, but it'd trivial to check for existance and use what exists.
[14:05] <soren> ScottK: Sure.
[14:06] <soren> ScottK: It not complicated at all. It's just a simple gotcha that one should keep in mind.
[14:28] <jjesse> anyone else having problems getting to the dovecot website?
[14:34] <sommer_> jjesse: works fine for me :)
[14:34] <jjesse> seriously?
[14:35] <sommer_> yep, no issues that I can see
[14:35] <jjesse> it times out for me
[14:35] <jjesse> tried it on 3 different boxes
[14:35] <sommer_> hmmm... maybe a dns issue?
[14:35] <jjesse> maybe, but other pages work
[14:35] <jjesse> i bet i'm not suppposed to be looking up other mail servers here :)
[14:36] <jjesse> i'll blame microsoft
[14:37] <sommer_> heh, they're probably out to get you... it happens
[16:11]  * delcoyote hi
[17:03] <Deeps> !webmin
[17:03] <Deeps> !exbox
[17:04] <Deeps> !ebox
[17:53] <Insomnia1ity> http://gb.archive.ubuntu.com/ubuntu/pool/universe/s/samba/
[17:53] <Insomnia1ity> lol
[19:02] <lukehasnoname> hello
[20:31] <drekk1> http://www.expressen.se/nyheter/1.1205194/han-svek-sitt-lofte-till-mig
[20:31] <drekk1> sorry, wrong window :)
[22:00] <mweichert> hello! I use Intel Core 2 Duo processors... should I use the AMD64-bit edition of Ubuntu?
[22:01] <RoAkSoAx> mweichert, ia64 supports amd64 and EM64
[22:02] <mweichert> RoAkSoAx: okay, I just noticed that the ISO image ends with amd64
[22:02] <mweichert> second, is there a 64-bit version of JeOS?
[22:03] <RoAkSoAx> mweichert, it does, but it really is for ia64. And about JeOS i don't know for sure...
[22:14] <infinity> RoAkSoAx: ia64 != amd64.
[22:14] <infinity> RoAkSoAx: Please don't confuse them.
[22:14] <infinity> RoAkSoAx: It confuses others. :)
[22:14] <infinity> RoAkSoAx: ia64 is the Intel Itanium architecture.  amd64 is x86_64, aka "AMD Athlon", and "Intel Core2".
[22:15] <jjesse> there is not a 64 bit version of jeos
[22:17] <mweichert> jjesse: why not? :)
[22:18] <lukehasnoname> mweichert: The theory is that VMs won't use more than 4GB, I guess
[22:18] <lukehasnoname> kinda stupid.
[22:18] <lukehasnoname> Also, you can use standard server iso's for a guest OS
[22:19] <jjesse> i just thought thye hadn't built it yet

[22:20] <mweichert> lukehasnoname: I put my all servers in VMs just for flexibility sake... it's easy to move them around and such
[22:21] <mweichert> lukehasnoname: wouldn't there be a bit of overhead in running x86 though... isn't the x86 instructions emulated on the 64-bit processors?
[22:22] <lukehasnoname> I'm no expert, but I don't think so
[22:23] <lukehasnoname> 64 bit is an extension of x86
[22:29] <infinity> mweichert: x86_64 CPUs run 32-bit code with no penalty.
[22:30] <infinity> (Well, the penalty is access to fewer register, so it's a tiny bit slower than x86_64 code, but that's because x86 sucks, not something that would be improved running in 32-bit mode natively, which would still ignore the extra registers)
[22:30] <infinity> mweichert: The emulation you're thinking of would be ia64 (Itanium) CPUs emulating i386, which is precisely the confusion I was trying to steer RoAkSoAx away from. :)
[22:30] <ScottK> The other penalty is you don't get to experience any 64 bit unique bugs.
[22:30] <infinity> mweichert: x86_64 is just an extension of x86 so, by definition, runs x86 code at native speeds.
[22:31] <infinity> ScottK: Those are part of the fun!
[22:31] <RoAkSoAx> infinity, yeah my bad ;)
[22:33] <infinity> ScottK: And, to be fair, I've been running amd64 Ubuntu on my Core2 for a while now, and things have very much improved since the bad old days.
[22:33] <infinity> ScottK: Heck, we even have cute wrappers for binary-only 32-bit browser plugins and stuff.
[22:35] <mweichert> well thanks for the help guys, that helps a lot
[22:35] <ScottK> And on a server, I'd expect it to be better than on the desktop.
[22:35] <ScottK> Personally I view it as some risk for infintesimal gain, so I don't bother.
[22:36] <mweichert> would jeos serve well as a host?
[22:38] <Brazen> From the way I understand it, JEOS strips out a lot of hardware support because it expects to be run as a vm guest (which has a limited set of virtual hardware)
[22:39] <Brazen> So, unless your physical hardware is the equivalent of the virtual hardware that gets presented to guests, you will probably be out of luck
[22:41] <lukehasnoname> Brazen: awesome
[22:45] <Brazen> lh(n^2): they do that for performance improvements :D
[22:46] <lukehasnoname> so how do I check if php is running from console?
[22:47] <lukehasnoname> hm actually I bet I should reboot
[22:48] <thenewguy> leo
[22:48] <thenewguy> he and moving stuff
[22:55] <nxvl> soren: around?
[23:19] <Brazen> nxvl: more of an oblong
[23:20] <Brazen> lukehasnoname: don't reboot, just do a "sudo apachectl reload-config" or something like that, so there's no downtime
[23:21]  * Brazen leaves
[23:54] <mweichert> anyone here use VmWare?
[23:54] <RoAkSoAx> mweichert, i do
[23:55] <mweichert> RoAkSoAx: do you create virtual disks or allocate real partitions?
[23:55] <RoAkSoAx> mweichert, virtual Disks
[23:56] <mweichert> RoAkSoAx: hmm, and you don't have any performance issues?
[23:57] <RoAkSoAx> mweichert, haven't test that but i run from 4 to 6 VM's on my Desktop and work just fine


[00:01] <ivazquez|laptop> Okay, branch..revision_id_to_revno() worked for that one. But it fails for files like README.
[00:01] <lifeless> dotted revnos aren't handled by that api; I think there is another newer api
[00:02] <lifeless> there has been some stuff on the list recently too, about this
[00:02] <ivazquez|laptop> I'll take a look there then, thanks.
[00:04] <enigma42> jelmer: Can I use the 0.6.0 release of subvertpy with bzr-svn 0.5-trunk?
[00:04] <jelmer> enigma42, yes
[00:04] <enigma42> jelmer: OK.
[00:05] <enigma42> jelmer: Where do I install subvertpy?
[00:05] <jelmer> enigma42, somewhere in your python path (./setup.py install usually does the right thing)
[00:05] <enigma42> OK.
[00:07] <enigma42> jelmer: Is there a way to install it unprivileged?
[00:07] <enigma42> jelmer: LIke in "~/.python" or something like that?
[00:07] <jelmer> enigma42, yeah, you can specify a different directory using the --root option
[00:07] <jelmer> enigma42, but you'll have to set PYTHONPATH appropriately to use bzr-svn then
[00:07] <enigma42> Oh, OK.
[00:09] <lifeless> --homedir isn't it?
[00:14] <enigma42> jelmer: OK. I use "checkinstall" to create a deb and installed it that way.
[00:17] <Jc2k> lifeless: bzr + ssh, more specifically its SSHSuprocess objects. do you know why os.read(stdin.fileno()...) was preferred over sdin.read(.. ?
[00:20] <Jc2k> lifeless: i have some questions about hooks too when you have some spare cycles
[00:21] <lifeless> Jc2k: just ask
[00:21] <lifeless> I'm at LCA, but will do my best
[00:21] <lifeless> dunno wh we use os.read there, annotate may help?
[00:22] <ivazquez|laptop> Aha, branch.get_revision_id_to_revno_map()[inv.revision].
[00:22] <Jc2k> ah ok. os.read seems to return something, but maybe not as much as you asked for. in that regard stdin.read is nicer.
[00:23] <Jc2k> lifeless: my question was about a plugin i threw together as "bzr-hookless-email reloaded"
[00:24] <Jc2k> lifeless: i replied to a post on bazaar ml about bzr-hookless-email with my thoughts, it might be easier to look at that
[00:25] <Jc2k> lifeless: basically im reusing Branch.hooks in a different context, and thats slightly evil of me but means that i have a way to make something like bzr-cia "just work" with a bzr-hookless-email type arrangement
[00:25] <Jc2k> (out of process hooks)
[00:27] <enigma42> jelmer: Great! The latest 0.5-trunk pushed and pulled just fine.
[00:27] <jelmer> Great :-)
[00:27] <enigma42> jelmer: Thanks for your help.
[00:29] <ivazquez|laptop> Excellent. 4 down, 1 to go.
[00:30] <enigma42> jelmer: OK. Same problem about branches diverging again.
[00:30] <jelmer> enigma42, what is the error there exactly?
[00:31] <jelmer> and what does e.g. "bzr missing" say?
[00:31] <enigma42> Here's the symptom. Before I clear the cache, I can do a "push" or "pull" and there will be not changes.
[00:31] <enigma42> Then I clear the cache.
[00:31] <enigma42> Then it says they diverge.
[00:32] <enigma42> It says I'm missing 40 revisions.
[00:32] <enigma42> Basically, everything that has been committed since I first pulled down the branch.
[00:32] <enigma42> So, SVN has all the revisions.
[00:33] <enigma42> And the bzr branch has all the same revisions.
[00:33] <enigma42> But the revision IDs don't match.
[00:33] <enigma42> The IDs I'm getting from SVN are now different than the IDs in bzr.
[00:33] <jelmer> enigma42: But it doesn't report that you have 40 *extra* revisions as well?
[00:34] <enigma42> Yes.
[00:34] <enigma42> I'm missing 40 and I have 40 extra.
[00:34] <enigma42> Example:
[00:34] <enigma42> From bzr:
[00:34] <enigma42> revno: 73
[00:34] <enigma42> revision-id: bhatpr@pbhat1-20090122095933-d3cmuadsx8jepmna
[00:34] <enigma42> parent: bhatpr@pbhat1-20090122094625-kq5y49s9uqagx459
[00:34] <enigma42> And from SVN:
[00:34] <enigma42> revno: 73
[00:34] <enigma42> revision-id: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:9671
[00:34] <enigma42> parent: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:9670
[00:35] <enigma42> So, somehow the ID got lost.
[00:35] <enigma42> The branch format is: Standalone branch (format: rich-root-pack)
[00:35] <enigma42> Does it need to be something like 1-9-rich-root?
[00:35] <jelmer> no, that shouldn't matter
[00:36] <jelmer> what subversion version is the server running?
[00:36] <enigma42> It's svn 1.4 via collabnet
[00:36] <jelmer> not recently downgraded or anything?
[00:36] <enigma42> No.
[00:37] <enigma42> It's about to be upgraded to 1.5 this weekend.
[00:37] <jelmer> so bzr-svn uses svn file properties?
[00:37] <enigma42> I'm thinking so.
[00:38] <jelmer> enigma42: The repository is not public I assume?
[00:38] <enigma42> Unfortunately, no.
[00:38] <jelmer> enigma42: If you run e.g. "svn diff -c <last-svn-revnum> <url>", do you see any bzr-svn properties?
[00:38] <enigma42> OK. Let me try.
[00:40] <enigma42> No, I don't see any bzr-svn properties.
[00:40] <enigma42> I'm going to try putting the old cache back in place real quick to see what happens.
[00:41] <enigma42> Yeah. With the restored cache, it's happy again.
[00:42] <jelmer> enigma42, if you run "svn log --xml --with-all-revprops" on the last revision, do you see any bzr properties?
[00:42] <enigma42> Let me try.
[00:43] <enigma42> Yeah.
[00:43] <enigma42> They are showing up as revprops.
[00:43] <enigma42> But bzr-svn thinks it's a 1.4 server because it complains about needing to upgrade to 1.5
[00:45] <enigma42> jelmer: I tried using the ubuntu pastbin, but it's complaining about the xml.
[00:46] <enigma42> jelmer: Want an email?
[00:47] <jelmer> enigma42: No, thanks - I'm pretty sure this is related to the 1.4/1.5 logic
[00:47] <enigma42> Oh, OK.
[00:47] <enigma42> Let me know if you want more information.
[00:48] <jelmer> enigma42, since when have you been using 0.5 ?
[00:48] <enigma42> Well...the version I was using previously was checked out Dec 27.
[00:48] <enigma42> But, I've used a variety of versions in the last several months.
[00:49] <enigma42> Basically, I've been using bzr-svn since April.
[00:49] <enigma42> I can't remember the first version I used.
[00:49] <enigma42> It may have been 0.3.x...but I can't remember.
[00:49] <jelmer> enigma42, and when was the first of these 20 revisions that are now out of sync?
[00:50] <enigma42> Every revision commited to the branch since I checked out the branch on Jan 9
[00:51] <enigma42> Using the version from Dec 27
[00:51] <jelmer> enigma42, is there a bzr:see-revprops file property set on the branch root ?
[00:52] <enigma42> Let me check.
[00:53] <enigma42> Yes.
[00:53] <enigma42> There is a bzr:see-revprops file property there now.
[00:53] <enigma42> Is it possible to do a bzr log on a file property?
[00:53] <enigma42> Ack.
[00:53] <enigma42> I mean an "svn log" on a file property.
[00:54] <jelmer> enigma42: no, I don't think that's possible
[00:54] <enigma42> OK.
[00:54] <jelmer> what are the contents of that property ? It should be a svn revno
[00:54] <enigma42> It is: 9576
[00:55] <enigma42> The lastest rev in subversion is: 9725
[00:55] <enigma42> Little more info..
[00:55] <enigma42> This project used to be in /trunk/backoffice/sys-data-analyzer
[00:56] <enigma42> Then, as part of our transition to using bzr as a team, I did an "svn copy /trunk/backoffice/sys-data-analyzer /sys-data-analyzer/trunk"
[00:56] <enigma42> Then, I did a branch on "/sys-data-analyzer/trunk" to build the bzr branch the rest of the team uses.
[00:57] <enigma42> And I run a script to push changes back into svn for corporate compliance. ;-)
[00:57] <jelmer> ah :-)
[00:57] <enigma42> So, it's a branch has been moved in subversion. That branch had not previously been touched with bzr-svn until after I moved it.
[00:58] <enigma42> And it has only been touched wtih the bzr-svn version from Dec 27
[00:58] <jelmer> So what it seems to come down to is that bzr-svn should be looking at that bzr:see-revprops property (since this is svn 1.4)
[00:58] <jelmer> and that property has the correct value
[00:58] <jelmer> but it's not reading it for some reason
[00:59] <enigma42> Is there some logging I can turn on?
[00:59] <enigma42> Other than the transport stuff?
[01:01] <jelmer> no, but this patch should add some:
[01:02] <jelmer> http://samba.org/~jelmer/tmp/bzr-svn-revprop-mutter.diff
[01:02] <enigma42> OK. Let me apply it.
[01:04] <enigma42> OK.
[01:04] <enigma42> It's patched....
[01:04] <enigma42> Do you want me to move the cache out of the way?
[01:04] <enigma42> Start with an empty cache?
[01:05] <jelmer> yeah, please
[01:06] <enigma42> OK....doing a bzr missing
[01:08] <enigma42> OK...where should I look for the log?
[01:09] <enigma42> It says I'm missing 43 revisions and I have 43 extra revisions.
[01:09] <jelmer> check ~/.bzr.log
[01:09] <enigma42> OK
[01:09] <jelmer> that should give some extra data
[01:09] <enigma42> Want me to pastbin it?
[01:09] <jelmer> please do
[01:11] <enigma42> OK...just a minute....I'll post it....
[01:13] <enigma42> http://pastebin.ubuntu.com/108427/
[01:14] <enigma42> OK...I'm going to put my old svn-cache back for now.
[01:14] <enigma42> I've got to run....I'll be back on IRC tomorrow.
[01:14] <jelmer> ah, I think I've got it
[01:15] <enigma42> Cool!
[01:15] <enigma42> I'll leave it logged in....
[01:15] <enigma42> If you post a fix, I'll pull it down and try it out in a couple of hours.
[01:16] <jelmer> enigma42, http://samba.org/~jelmer/tmp/fix-changes-root.diff
[01:16] <enigma42> OK....let me try.
[01:16] <jelmer> you'll need to revert the patch I posted earlier
[01:16] <enigma42> OK.
[01:16] <enigma42> I'll re-export from trunk.
[01:17] <enigma42> OK...here goes....
[01:17] <enigma42> REbuilding the cache....
[01:18] <enigma42> Nice!
[01:18] <enigma42> Branches are up to date!
[01:18] <enigma42> Woohoo!  I'm happy I could help out. :-D
[01:19] <enigma42> I'll do a full sync of all the different repos later and make sure all is well.
[01:19] <enigma42> Thanks again.
[01:19] <enigma42> I've been really pleased with 0.5
[01:20] <jelmer> np
[01:20] <enigma42> Following copies is great!
[01:20] <enigma42> Well...I'm off for now....bye....
[01:45] <thumper> is there a short cut to go to the bottom thread of a loom from the top thread?
[01:48] <thumper> nm, found it
[01:48] <thumper> down-thread [thread-name]
[03:36]  * thumper has found a weirdness
[03:36] <thumper> in locations.conf I have a default push location set with append path
[03:37] <thumper> for one of my branches, I wanted this slightly different
[03:37] <thumper> so `bzr push --remember xyz`
[03:37] <thumper> however bzr tells me that value xyz is masked by locations.conf
[03:37] <thumper> surely if I say --remember, it should override a default???
[03:39] <mwhudson> thumper: --remember sets stuff in branch.conf and locations.conf wins over branch.conf
[03:39] <mwhudson> there was a thread about this on the mailing list a few months back
[03:39] <thumper> poos
[03:39] <mwhudson> (i don't understand the reasoning)
[04:15] <lifeless> interesting...
[04:15] <lifeless> http://paste.ubuntu.com/108451/
[04:15] <lifeless> jelmer: ^ may interest you. Thats invoking git-cat-file per object
[04:18] <lifeless> morning kiko
[04:24] <lifeless> jelmer: how are we meant to access the dulwich that is in bzr-git?
[04:24] <lifeless> jelmer: b.p.git.dulwich ?
[04:30]  * igc out for a few hours
[05:16] <j^> why does the ppa repository for hardy remove bzrtools?
[05:32] <rockstar> j^, once the updated bzrtools gets installed, then it won't remove them.
[06:54] <vila> hi all
[08:30] <mcfletch> PPA for Intrepid seems to have been broken (bzrtools is 1.10, bzr is 1.11).
[08:32] <AfC> mcfletch: are you actively using something from bzrtools? If not, then you could un-install it [for now] and get around the problem\
[08:32]  * AfC is using bzr 1.11 from PPA but didn't see your problem as I don't have bzrtools installed
[08:37] <mcfletch> Hmm, interesting, aptitude was telling me it was "broken"... I actually switched back to 1.6 to commit the changes... will try again...
[08:41] <mcfletch> Ah, I was reading the "recommended" as "required" and the second confirmation as a "you can't do that, choose something else"... guess I shouldn't updates software at 3am.
[08:41] <mcfletch> thanks for the clue-stick.
[09:26] <wgrant> jelmer: Using a fresh checkout with bzr-svn 0.5.0~rc1+bzr does work, unlike 0.4.16, and all that fails is a reconcile (check works fine, which is odd). I can then branch that existing local branch locally, and it will work fine. But then checking it out once it's pushed to LP fails with a 'No such file'. I'm very confused.
[12:44] <Lo-lan-do> Hi all
[12:45] <james_w> hi Lo-lan-do
[12:46] <Lo-lan-do> We're debating the ol' git-vs-bzr debate for starting a new project, and I wondered how functional the bzr-git plugin was (or was expected to get soonish)
[12:46] <james_w> Lo-lan-do: guess who's working on it :-)
[12:47] <Lo-lan-do> jelmer?  Well, he'll be happy to get rid of me for bzr-svn, but maybe I'll switch to pester him on bzr-git :-)
[12:47] <james_w> heh
[12:50] <james_w> Lo-lan-do: it's kind-of functional now, and improving quickly
[12:50] <james_w> Lo-lan-do: I'm not sure how differences in bzr and git limit it though
[12:50] <Lo-lan-do> Does it work both ways?
[12:50] <Lo-lan-do> ie, commit to git from bzr and vice-versa?
[12:51] <james_w> not sure
[12:51] <james_w> I imagine it will work like bzr-svn does
[12:58] <fullermd> But with less svn-induced wonkiness, I should think.
[12:58] <fullermd> The bzr and git data models are fundamentally so similar that there should be a lot fewer impedance mismatches.
[12:59] <Lo-lan-do> I'll give it a try, I guess.  We've agreed to have both so far until we can test how interoperable they are.
[13:22] <jonnydee> I've got a question regarding 'bzr join': after joining a tree, is the sub-tree fully contained in the parent branch? I mean can I remove the .bzr-directory of the joined tree?
[13:27] <sjokkis> hi. i've made a branch of my project, and i want the branch to become the new trunk. what's the best way to do this?
[13:27] <sjokkis> (the branch was made to port the project from c++ to c, so i don't think merging is viable)
[13:28] <luks> 'trunk' in really unrelevant in bzr
[13:28] <sjokkis> so just delete trunk and copy the branch so it's a new trunk?
[13:29] <luks> what trunk?
[13:29] <sjokkis> :(
[13:29] <luks> it depends on your setup
[13:29] <sjokkis> they're all just branches with different names, eh?
[13:29] <luks> yes
[13:29] <fullermd> Merging could still be viable.  Or you could mv away the old trunk and stick it in its place.  Or you could pull or push it over the existing trunk.  Or just advertise that the trunk is a different place now.  Or...
[13:30] <sjokkis> fullermd: well the files have new names now that they're in c and not cpp
[13:30] <luks> that doesn't really matter to bzr
[13:30] <fullermd> Well, but you branched off that to start with, right?
[13:31] <fullermd> So the only difference between merging and switching is that in one case, the bighugechange happens in one mainline rev, and in the other it's spread over N mainline revs.
[13:33] <fullermd> (which isn't to say that you necessary _want_ to do it via merge; but it's just as viable an option, depending on details, as the others)
[13:34] <jelmer> wgrant, you need the 0.5 branch, rather than the rc
[13:34] <jonnydee> I tried to 'join' a tree but I get an error: "bzr:ERROR: Cannot join FooBar.  Trees have the same root". What am I doing wrong?
[13:45] <poolie> we're chatting about the bzr home page; some notes are in gobby.ubuntu.com if anyone's interested
[13:45] <sjokkis> what's the common way of creating tags in bzr? i'm used to copying to project/tags from svn, but it seems bzr just gives the current (or a specified) revision a name. is this how it's supposed to be done?
[13:46] <wgrant> jelmer: I'm running r2355 at the moment; do I need later?
[13:47] <jelmer> wgrant, no, I think that should be sufficient
[13:47] <jelmer> wgrant, what's the error you're getting exactly
[13:49] <wgrant> jelmer: On the checkout from LP:
[13:49] <wgrant> bzr: ERROR: No such file: ('1123@2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:ivle%2Futil.py', 'svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132')
[13:49] <jelmer> and the backtrace?
[13:49] <wgrant> The checkout doesn't give one.
[13:50] <wgrant> The reconcile on the original local copy does; do you want that?
[13:50] <jelmer> ah, ok
[13:50] <jelmer> wgrant, I'll try that here locally
[13:50] <wgrant> jelmer: Thanks.
[13:51] <bob2> sjokkis: with the tags command
[13:56] <jelmer> wgrant, reconcile passes successfully here
[13:56] <wgrant> jelmer: Huh. I'll try checking out again on another box.
[14:05] <bond`> how can i export a revision with the original file dates?
[14:07] <bob2> bzr doesn't version ctime/atime/mtime
[14:09] <bond`> is this a planned feature?
[14:09] <LeoNerd> I doubt it, for the complexities of making it work cross-platform
[14:10] <Jc2k> it would probably confuse build systems, too
[14:10] <bond`> so i have no possibility to see the original file time?
[14:10] <bob2> what do you mean by 'original'?
[14:11] <fullermd> Well, the time of commit is known.  So theoretically, export could set file mtimes to the time of last change.
[14:11] <bond`> bob2: the time the file was changed
[14:11] <fullermd> Of course, in any but very carefully crafted cases, the time of commit would be different from the mtime of the file when it was committed, and I'm pretty sure that isn't stored.  But do you really care about the difference?
[14:11] <bob2> bond`: bzr log filename
[14:12] <jam> vila: ping
[14:12] <vila> jam: pong
[14:13] <bond`> bob2: thats ok, i'd like to see something which 'svn export' or 'hg archive' does
[14:16]  * fullermd points at bug 262261
[14:22] <bond`> fullermd: that's what i mean
[14:34] <wgrant> jelmer: http://pastebin.com/d3e21e522 is what I get when reconciling a fresh checkout from svn trunk. It really works fine for you?
[14:35] <jelmer> wgrant, a clean branch created from http://ivle.googlecode.com/svn/trunk/ using bzr-svn reconciles fine for me
[14:35] <jelmer> wgrant, can you perhaps try a clean import, after removing ~/.bazaar/svn-cache ?
[14:35] <wgrant> But... but...
[14:35] <wgrant> jelmer: That's what I tried.
[14:35] <jelmer> wgrant, and if you try with a newer bzr-svn?
[14:36] <jelmer> I don't think there's actually any fixes recently that could affect this though..
[14:36] <wgrant> jelmer: I looked at stuff post-2355, and it doesn't look relevant...
[14:36]  * wgrant removes stuff from subversion.conf.
[14:37] <jelmer> wgrant, I'm just trying to eliminate things that could cause it to work for me but not for you
[14:38] <wgrant> jelmer: You're running bzr 1.11, or bzr.dev?
[14:38] <jelmer> wgrant, bzr.dev
[14:58] <wgrant> jelmer: OK, removing all svn-related config didn't work; trying with latest bzr-svn trunk now...
[15:09] <sjokkis> hi, how do i go undo all changes i've done since the last commit?
[15:09] <jelmer> sjokkis, "bzr revert"
[15:13] <sjokkis> oh. that was simple. thanks
[15:15] <wgrant> jelmer: It still doesn't work... Do we blame bzr 1.11?
[15:15]  * wgrant should go to bed ~now.
[15:15] <jelmer> wgrant, not sure :-( Is there any chance you can try with bzr.dev ?
[15:16] <wgrant> jelmer: I'll hopefully try tomorrow (I'm gone for a week after that).
[15:16] <wgrant> Thanks for your help!
[15:16] <jelmer> k
[15:16] <jelmer> np
[15:26] <jdobrien> I had some trouble with my bzr installation and I can't figure out how to fix it
[15:27] <jdobrien> sudo apt-get install bzr .... seems to work
[15:27] <jdobrien> but then:  bzr
[15:27] <jdobrien> bash: /home/john/bin/bzr: No such file or directory
[15:29] <jelmer> looks like you have a dangling symlink there
[15:29] <jdobrien> yeah i removed it
[15:29] <jelmer> and you still get that error?
[15:32] <jdobrien> yeah...im hunting for the symlink...it has to be somewhere
[15:33] <jdobrien> found it
[15:33] <jdobrien> :-)
[15:33] <jdobrien> argh
[15:34] <LarstiQ> hey jdobrien
[15:34] <poolie> hi guys
[15:34] <jdobrien> hi LarstiQ
[15:34] <poolie> jdobrien: you may need to type 'rehash'
[15:35] <jdobrien> hash -r?
[15:36] <jelmer> hi LarstiQ, poolie
[15:36] <LarstiQ> hey jelmer :)
[15:36] <jdobrien> LarstiQ: thanks
[15:37] <jdobrien> The following packages have unmet dependencies:
[15:37] <jdobrien>   bzrtools: Depends: bzr (< 1.11~) but 1.11-1~bazaar1~intrepid1 is to be installed
[15:37] <jdobrien> E: Broken packages
[15:38] <jdobrien> hi poolie
[15:41] <jdobrien> john@Monolith:/usr$ bzr version
[15:41] <jdobrien> Bazaar (bzr) 1.11
[15:49] <jelmer> kfogel, hi
[15:50] <kfogel> jelmer: just responding to the web site summary mail
[16:00] <jelmer> kfogel, Actually, I had a Subversion question
[16:01] <jelmer> kfogel, I've been pulling my hair out trying to use svn_wc_process_committed()
[16:01] <jelmer> kfogel, it seems to require that the files it's called on are already marked unchanged. Is that correct?
[16:09] <kfogel> jelmer: can you ask me in #svn?  (and rephrase -- I confess I didn't quite understand the question :-) )
[16:09] <kfogel> thx
[16:09] <jelmer> kfogel, yeah, np
[16:41] <jrwren> ERROR: selected file commit of merges is not supported yet.
[16:41] <jrwren> Is that true?
[16:41] <jrwren> just trying to bzr commit -x PathToExclude
[16:45] <jelmer> jrwren, yes, that's correct - cherrypick merges are not yet supported
[16:46] <jrwren> this is really hurting me now :(
[16:46] <jrwren> plus its something my svn loving, bzr hating coworkers can hang over my head :(
[17:01] <kfogel> https://savannah.gnu.org/support/index.php?106612  ("Preparation for switching Emacs from CVS to bzr on Savannah.")
[17:01] <kfogel> thought people here might be interested
[17:04] <Kobaz> ooooo
[17:04] <Kobaz> people still use cvs?
[17:05] <Lo-lan-do> They could have switched to GNU Arch...
[17:05] <jelmer> kfogel: Nice!
[17:06] <jelmer> kfogel: I've been wondering about the bzr support on Savannah, e.g. it would be nice if they could run loggerhead
[17:07] <kfogel> jelmer: I think they do, but it's in beta
[17:07] <kfogel> that's part of what I'm asking in that issue
[17:09] <Lo-lan-do> A new loggerhead release with some of the proposed patches merged in would help, in that regard *hint* *hint*
[17:11] <Lo-lan-do> (I'm probably going to become more and more annoying about loggerhead in the near future :-)
[17:12]  * jelmer is eagerly waiting for the first non-start-loggerhead release..
[17:32] <jelmer> kfogel:  Are you still looking for an editor for the scenarios on the wiki ? (Sorry, just catching up with list email)
[17:33] <kfogel> yes!
[17:33] <jelmer> kfogel, I'm happy to edit some of the scenarios about topics I'm familiar with
[17:33] <kfogel> jelmer: an aggressive editor -- that is, one who can not only edit scenarios, but take out / add scenarios based on list discussion.
[17:33] <kfogel> My initial list of scenarios is *not* to be treated as gospel.  quite the opposite.
[17:34] <kfogel> jelmer: it sounds like when you say "edit" you mean what I think of as "write"
[17:34] <kfogel> ?
[17:35] <jelmer> kfogel: Yes, sorry
[17:37] <kfogel> please do!
[17:37] <kfogel> jelmer: the reason is that the other purpose (perhaps the real purpose?) of the scenarios is to help us figure out what stories bzr doesn't know how to tell yet.
[17:38] <kfogel> For example, just trying to write the one-off bugfix scenario has exposed that we don't, actually, *have* a recommended way to go about this that everyone agrees on.
[17:38] <kfogel> It's important to find that out.
[17:38] <jelmer> kfogel: Ah, right
[17:39] <kfogel> jelmer: so, you write the scenarios you feel comfortable with.  Then we see if people say "Wait, that's not how I'd do it!"
[17:40] <jelmer> will do :-) I actually already see two existing scenarios I would object to..
[17:45] <jelmer> I've added http://bazaar-vcs.org/Scenarios/ConvertFromSVN
[18:03] <Peng_> How does one fix conflicting tags? Delete it and pull again?
[18:06] <enigma42> Peng_: I just ran across that too.
[18:06] <enigma42> I got a "conflicting tag" message when using bzr-svn.
[18:07] <enigma42> I delete the tag from the repo, deleted it from svn, retagged the repo and then pushed.
[18:07] <enigma42> It seemed fine until the second push.
[18:07] <enigma42> When I got the message again.
[18:09] <Peng_> I went ahead and deleted them. Blah.
[18:09] <enigma42> jelmer: Any idea on how I could track down the "conflicting tag" error?
[18:09]  * Peng_ does it to another copy of the branch too.
[18:09] <enigma42> jelmer: How do I see what rev svn thinks the tag is pointing to?
[18:10] <jelmer> enigma42, bzr tags --show-ids
[18:13] <enigma42> So, I get this: 0.11                 svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:frame-broker/trunk:9425
[18:14] <enigma42> SVN thinks the tag is set to 9425?
[18:14] <enigma42> Is there a way to ask SVN to see revision project/tags/0.11 is pointing to?
[18:17] <elmo> oh hai
[18:17] <enigma42> jelmer: Oh...I think my issues is related to the bad id problem we found yesterday.
[18:17] <elmo> # bzr ci -m "wut" alternatives/abort.7.gz
[18:17] <elmo> bzr: ERROR: Not a branch: "/usr/share/postgresql/8.3/man/man7/abort.7.gz/".
[18:17] <elmo> has anyone seen that?  i can't reproduce it locally
[18:18] <enigma42> It looks like the revision id in svn is different than the revision ID in the bzr branch.
[18:18] <jelmer> elmo, I think I've seen that
[18:18] <jelmer> elmo, And caused by some plugin I had installed
[18:18] <jelmer> elmo, What plugins are installed on the host where you get that error?
[18:18] <jelmer> enigma42, Ah, that would explain it
[18:19] <elmo> jelmer: just bzr tools
[18:19] <elmo> ah, actually I can reproduce it locally
[18:19] <elmo> let me try with bzr 1.11
[18:20] <enigma42> jelmer: I'm re-branching off SVN...I'll see what happens...
[18:22] <enigma42> jelmer: OK...Now I have a new issue: bzr: ERROR: The branch svn+https://sequoia.csd200a.com/svn/sequoia/frame-broker/trunk has no revision None.
[18:23] <enigma42> So, it's refusing to make a branch.
[18:23] <Peng_> ...
[18:23] <jelmer> enigma42: That's most likely fallout from the problem we fixed yesterday (a tag referring to a nonexisting revision?)
[18:24] <enigma42> So, I should be able to fixup the svn reprop?
[18:24] <jelmer> enigma42, Any chance you can comment out the bit in bzrlib/builtins.py where it prints that message by catching NoSuchRevision?
[18:24] <enigma42> jelmer: OK...let me try.
[18:25] <Peng_> jelmer: I just hit bug 308353 again, with the latest trunk (more or less). :\
[18:25] <enigma42> jelmer: Grabbing a source copy of bzr so I can comment it out.
[18:25] <elmo> le sigh
[18:25] <jelmer> Peng, which URL?
[18:25] <elmo> jelmer: it's https://bugs.launchpad.net/bzr/+bug/128562, FWIW
[18:25] <elmo> (and is still broken in bzr 1.11)
[18:26] <jelmer> elmo, ahh
[18:26] <Peng_> jelmer: Same URL (lighttpd-1.4.x)
[18:26] <jelmer> Peng_, just doing a clean branch?
[18:27] <Peng_> jelmer: No, "bzr pull".
[18:28] <Peng_> Err, wait a minute. I hit *something*, but I'm not sure it's the same something.
[18:28] <enigma42> jelmer: Do you want me to comment out the whole "except" block?
[18:29] <enigma42> jelmer: It looks like it deletes the tree, prints the message, and raises a different error.
[18:29] <Peng_> jelmer: Sorry, my mistake. It was just the bzr-search error I get. I forgot that it indexes the branch on "pull", and most of the traceback went off my screen.
[18:29] <poolie> hello all
[18:30] <poolie> abentley, if you're here -  http://bazaar-vcs.org/WritingPlugins used to advise people to merge their plugins into bzrtools
[18:30] <poolie> i removed it
[18:30] <poolie> it's an option but i don't think we want it to be a catch-all
[18:30] <jelmer> enigma42, yes, please
[18:30] <jelmer> enigma42, that should make it show the proper traceback
[18:31] <jelmer> Peng_, Ah, so this is the same problem you reported a bug for earlier?
[18:31] <abentley> poolie: Okay
[18:31] <Peng_> jelmer: Yeah, it's nothing new. I just forgot that bzr-search kicks in on "pull".
[18:33] <abentley> poolie: The desire was for bzrtools to become a collection of utilities so that people didn't have to spend forever installing new plugins.
[18:33] <enigma42> jelmer: OK...I'll pastbin the traceback....
[18:33] <abentley> poolie: shelf and heads have worked out that way, but few others.
[18:33] <jelmer> Peng_, which reminds me, do you have a link to that bug?
[18:34] <enigma42> jelmer: http://pastebin.ubuntu.com/108674/
[18:34] <jelmer> enigma42, that looks like a problem in what you changed in builtins.py
[18:34] <Peng_> jelmer: https://bugs.launchpad.net/bzr-search/+bug/318935
[18:39] <enigma42> jelmer: Oh..I see it...the exception was thrown before "branch" was assigned....
[18:40] <jelmer> Peng_, Thanks
[18:41]  * enigma42 is commenting out more stuff...
[18:49] <enigma42> jelmer: Well that's strange...I cleared the cache and now I don't get an error.
[18:49] <enigma42> jelmer: Must have been one of those bad ids stuck in the cache.
[18:50] <enigma42> Oh wait...hold on...
[18:50] <enigma42> I must have commented out too much stuff.
[18:51]  * apw wonders if there is a command to bzr command line to show both the summary message and the diff for a commit in one go
[18:51]  * enigma42 is changing the commenting again...
[18:56] <enigma42> Ah ha! I figured it out....my python is a bit rusty... :-P
[18:57] <enigma42> jelmer: OK...let me get this backtrace into the pastebin....
[18:58] <Peng_> Oh, I just hit a bunch of conflicting tags in bzr-svn too.
[18:59]  * mgedmin actually also wants what apw wants
[18:59] <Peng_> jelmer: With the very latest bzr.dev, there are warnings about your "determining changes" progress bar.
[18:59] <Peng_> One for every revision, in fact. :D
[19:00] <mgedmin> so, can bzr do what 'git log -p' does, i.e. show the diff for every log revision?
[19:01]  * Peng_ looks at apw and mgedmin.
[19:01] <enigma42> http://pastebin.ubuntu.com/108697/
[19:01] <jelmer> enigma42, thx
[19:02] <poolie> mgedmin: iirc there's a patch to add that up now
[19:02] <jelmer> mgedmin, not yet, but there's a patch waiting for inclusion
[19:02] <mgedmin> nice
[19:02] <poolie> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4972A474.3060303%40internode.on.net%3E
[19:02] <poolie> you can test it!
[19:13] <jelmer> poolie, After pulling bzr.dev I'm now getting the following error:
[19:13] <jelmer> /home/jelmer/bzr/bzr.dev/bzrlib/ui/text.py:96: UserWarning: ProgressTask(1165/2000, msg='determining changes') is not the top progress task ProgressTask(1164/2372, msg='analyzing repository layout')
[19:13] <jelmer> what does this mean exactly ?
[19:14] <enigma42> jelmer: I'm looking at the revprops...in the svn repo.....It looks like the "base-revision" is not the same as the "rev-id" of the parent.
[19:14] <jelmer> enigma42, the uuid is different?
[19:14] <enigma42> Yeah....
[19:14]  * davidstrauss is waiting for one of the 500 people in #git to not ignore him so he can write a balanced blog post comparing a git workflow to bazaar's.
[19:14] <enigma42> name="bzr:base-revision">svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:frame-broker/trunk:9425
[19:14] <jelmer> enigma42, Did the svn repository recently change its UUID ?
[19:15] <enigma42><EMAIL_ADDRESS>[19:15] <enigma42> So, the revision ID isn't using the svn UUID at all.
[19:16] <enigma42> Since the revision was pushed into SVN from bzr, I presume...
[19:16] <jelmer> enigma42, yeah, but it refers to its parent revision
[19:17] <enigma42> jelmer: How much of that log did you get? I tried to /msg it to you.
[19:17] <jelmer> I saw some of it
[19:18] <enigma42> Let me try little chunks....
[19:18] <jelmer> enigma42: But the problem appears to be that the Subversion repository UUID has changed since that bzr-svn revision was committed
[19:18] <jelmer> Could that be correct?
[19:18] <jelmer> are you perhaps working on a svnsynced copy of the repo?
[19:19] <jelmer> 'morning Ian
[19:20] <jelmer> enigma1, did you see my messages here?
[19:20] <enigma1> jelmer: The only thing that has changed is that I delete my svn-cache....and you fixed that bug around the ids.
[19:21] <enigma42> jelmer: How do I find the SVN UUID?
[19:21] <jelmer> enigma42: "svn info <repos-url>"
[19:21] <enigma42> OK
[19:22] <enigma42> jelmer: No...it looks like the subversion ID is the same.
[19:22] <enigma42> jelmer: This is my guess...
[19:23] <enigma42> What I saw yesterday before the bugfix was that bzr-svn was inventing rev-ids instead of using the ones that were stored in the revision properties.
[19:23] <enigma42> So, somehow, when I tagged, the rev-id that had been invented was used instead of the rev-id that was stored in the SVN revision property.
[19:23] <jelmer> enigma42, see privmsg
[19:25] <poolie> jelmer:  the warnings mean there is probably a missing pb.finish() on the progress bar with those messages
[19:25] <poolie> or, as in one other case, the finally is wrapped around an iterator, so it's firing asynchronously to the operation actually finishing
[19:25] <poolie> i'm open to either fixing them up or silencing the warning
[19:26] <poolie> we should do one or another before releasing
[19:34] <jelmer> poolie, yeah, it's two progress bars working at once
[19:34] <jelmer> A function that iterates over a set of revisions by calling a generator
[19:34] <jelmer> that function has a progress bar
[19:34] <jelmer> and the generator also has a progress bar
[19:38] <enigma42> jelmer: OK...I fixed up the rev-id....trying to branch again....
[19:39] <poolie> jelmer: ok, that's good to know
[19:39] <poolie> because i was wondering whether we needed to support two of them updating at the same time
[19:39] <poolie> the api is a bit unclear about whether it's meant to be a stack or not
[19:39] <jelmer> poolie: it does make sense to only have one in this situation I guess
[19:40] <poolie> jelmer: so is one of them nested inside the other?
[19:40] <poolie> or, are they unsynchronized?
[19:40] <poolie> and if so, how would you like them drawn in the text ui?
[19:40] <phinze> okay, bazaar is confusing me today.  i have a local branch of a shared project branch i was working on (last pulled at 2117).  i made a commit (2118) locally and attempted to push, but the branches had diverged and bzr tells me to merge.
[19:40] <jelmer> phinze, what does "bzr missing" report?
[19:41] <phinze> so i merge with the project branch which pulls down three revisions that had made it in while i was working
[19:41] <jelmer> poolie, I need to check
[19:41] <phinze> then i commit the merge 'merged with project branch', (2119)
[19:41] <phinze> and i push
[19:41] <poolie> jelmer: just let me know
[19:41] <enigma42> jelmer: Woohoo! Branched just fine. Going to try a push and pull for good measure....
[19:41] <phinze> but now the three revisions i pulled down (from someone elses work) show up as sub-revisions from my commit
[19:41] <phinze> 2117.1.1-3
[19:43] <enigma42> jelmer: Great! It's working fine. The tags are now in-sync between the bzr branch and the svn repo. :-D
[19:43] <enigma42> jelmer: Thanks again for your help. And thanks for showing me the "svn log --xml --revprops -r ___" trick.
[19:44] <jelmer> enigma42, Np, thanks for helping get this bug fixed before 0.5.0!
[19:44] <jelmer> phinze, yes, this is intentional behaviour of "bzr merge"
[19:45] <Peng_> What determines whether bzr-svn will spend a bunch of time "determining changes" when pulling or not?
[19:45] <enigma42> jelmer: I'm happy to help. Thanks for making bzr-svn! It lets some of us use a *real* VCS in a heavily centralized corporate environment!
[19:48] <jelmer> Peng_, "determining changes" means it's walking history, that can be triggered by various things
[19:48] <phinze> jelmer: okay, but say i didn't work that gets commited while i'm working to show up as a sub-revision when i merge... how would i change my workflow?
[19:48] <phinze> *didn't want work
[19:51] <phinze> perhaps i need to add to my workflow a mirror branch rather than just maintaining one local branch that i sync with the shared project branch...?
[19:54] <phinze> or perhaps the best answer is, "don't worry about other commits showing up as sub-commits from your merge... get over it!" :)
[19:56] <jelmer> phinze: Yeah, I think that summarizes it up well
[19:56] <jelmer> Peng_, I fixed that bug
[19:59] <Peng_> jelmer: Which bug?
[19:59] <jelmer> Peng_, 318935
[19:59] <jelmer> Peng_, bug 318935 I mean
[20:00] <davidstrauss> Is there a way to automate bzr-search indexing on a server?
[20:00] <davidstrauss> I mean, other than crontab.
[20:00] <Peng_> jelmer: Oh. It was a bzr-svn bug?
[20:00] <jelmer> Peng_, yep
[20:01] <jelmer> Peng_, bug in the bugfix for that other bug :-)
[20:01] <Peng_> jelmer: Heh, nice. Have you pushed it yet? Do I need to do anything, like delete the cache or recreate the branches?
[20:02] <jelmer> Peng_, Yeah, it's been pushed. You need to recreate the branch and delete the cache.
[20:02] <Peng_> Both? Awesome! :D
[20:02] <Peng_> Thanks for fixing it.
[20:03] <jelmer> poolie, I've fixed the progress bar issues
[20:03] <poolie> ok
[20:03] <jelmer> poolie, Simply by not using the inner progress bar, it wasn't adding much useful information anyway
[20:04] <poolie> i'm totally open to changing or fixing the api if you need something richer
[20:04] <poolie> ok
[20:06] <jelmer> poolie, I think it needs to be richer, but I'm not entirely sure how :-)
[20:06] <poolie> (:
[20:07] <jelmer> poolie: I think at least it's important for progress bars that each step takes an equal amount of time
[20:07] <poolie> or as near to it as you can get, allowing for environmental variations
[20:07] <jelmer> poolie, the "Fetch phase X" thing where there's 4 phases that all take arbitrary amounts of time is very uninformative
[20:08] <poolie> like obviously if you're doing disk io and network io the relative speeds will be unpredictable
[20:08] <poolie> jelmer, i agree
[20:08] <poolie> i think the "phase" thing is questionable
[20:08] <poolie> the basic idea there is that we want the progress bar to appear just once for each command and fill monotonically from left to right
[20:09] <poolie> rather than one bar for fetching and then another for building the tree
[20:09] <jelmer> oh, ok
[20:09] <poolie> so it's not a bad thing to want
[20:09] <poolie> but i don't think the result is very satisfying
[20:09] <poolie> this patch improved a couple of things: you see all the stacked tasks, so usually more than just "fetch 1/4"
[20:09] <jelmer> I think I prefer separate bars but having bzr print a new line with what it's completed
[20:10] <poolie> and also, (currently only for sftp) you get an indication of network io
[20:10] <poolie> separate bars would be good
[20:10] <jelmer> poolie, Yeah, I agree the new progress bar is an improvement
[20:12] <Peng_> jelmer: Yay, it works. :)
[20:12] <poolie> yay
[20:12] <poolie> 'bzr serve --http' does what it should
[20:12] <Peng_> bzr+http or Loggerhead?
[20:12] <jelmer> or both ? :-)
[20:13] <Peng_> Oh, thank goodness, those pb-related warnings don't go in .bzr.log.
[20:13] <jelmer> Peng_, they're fixed in 2379
[20:14] <Peng_> jelmer: Okay, thanks.
[20:15] <poolie> Peng_: actually loggerhead, but beuno and jml are making loggerhead serve bzr+http
[20:15] <poolie> so, this afternoon, hopefully both
[20:16] <jml> just http to start with
[20:16] <jelmer> that's a *really* neat thing to have
[20:20] <poolie> and loggerhead will be (optionally) a plugin
[20:21] <poolie> optionally meaning you can use it in the same way as before
[20:34] <Peng_> #I'm being lazy here, but what was the summary of enigma42's tag conflict problem? I'm experiencing conflicts in some (but not all) tags, but I don't think
[20:34] <Peng_> Peng is an idiot.
[20:35] <Peng_> I didn't mean to send that. :)
[20:35] <Peng_> Although it's true, but anyway, I was going to investigate it more first.
[20:37] <jelmer> Peng_, It was related to a strange corner case bug caused by svn 1.4 on the server and bzr-svn not always looking at revision properties
[20:37] <Peng_> Oh, I think it's because some are using "svn-v3" revids and some are using "svn-v4".
[20:37] <jelmer> that primarily caused diverging branches
[20:37] <Peng_> Oddly, the copy made 5 minutes ago is using more "svn-v3" ids.
[20:42] <jelmer> Peng_: Can you please file a bug?
[20:44] <Peng_> I wasn't using a 100% new repo; I "bzr branched" two (non-corrupt) branches into it.
[20:45] <Peng_> Oh, "bzr log" shows a lot of svn-v3 ids too.
[20:46] <DBO> you know what would rock?  If bzr could figure out when you move a file without having to use bzr mv
[20:46] <DBO> mmhmmm mhmmm =)
[20:46] <Peng_> I've kind of confused the situation by swithing out the repos too. Hmm.
[20:49] <jelmer> Peng_, Yeah, it's correct there are svn-v3 ids there
[20:49] <jelmer> Peng_, that's because there are revisions created with older versions of bzr-svn
[20:49] <Peng_> jelmer: What do you mean? My branch is (almost) completely new.
[20:49] <Peng_> You mean revisions in the svn repo pushed by older versions of bzr-svn?
[20:50] <jelmer> Peng_, yes
[20:50] <Peng_> It looks like it's all "svn-v3" except for the very newest revision.
[20:50] <jelmer> Peng_, yeah, everything since the last revision pushed with bzr-svn 0.4.x will be a svn-v3 revision
[20:51] <jelmer> Peng_, That bit seems to work fine
[20:51] <Peng_> Okay.
[20:51] <jelmer> except bzr-svn gets confused about what mapping to use for those tags apparently
[20:51] <Peng_> Well, the more recent branch gets it right much more often.
[20:51] <jelmer> more often is not good enough :-)
[20:53] <Peng_> The new branch has: 22 tags (1 svn-v4, 1 bzr, 20 svn-v3), 20 of which it can map the revid to a revno, 2 of which show "?".
[20:53] <jelmer> so for what tags do you get conflicts?
[20:54] <Peng_> I've been doing lots of things to this repo today, so I don't even remember.
[20:54] <Peng_> I think I got the conflicts on about 6 tags with the old branch and old repo.
[20:58] <Peng_> jelmer: FWIW, pastebin of "bzr tags" on both branches: http://paste.pocoo.org/show/BIEg11uNyMGQ4Fr1phem/
[21:01] <jelmer> Peng_, thanks
[21:01] <jelmer> lifeless, ping
[21:04]  * jml submits the branch for review.
[21:04] <vila> jam: ping
[21:09] <nxsryan> hi.. i'm trying to do brz branch lp:trac-bzr but i think i have an older version of bazaar that doesnt convert "lp
[21:09] <nxsryan> oops
[21:09] <nxsryan> hi.. i'm trying to do brz branch lp:trac-bzr but i think i have an older version of bazaar that doesnt convert "lp" into a URI
[21:10] <nxsryan> can someone tell me what URI 'lp' stands for?
[21:10] <vila> launchpad
[21:10] <Peng_> nxsryan: You should upgrade bzr. You'd have to be on a really old version.
[21:10] <nxsryan> sure but.. that's not a complete URI
[21:10] <Peng_> nxsryan: What command did you run and what error message did you get?
[21:10] <nxsryan> Peng_: i know i should but that's not an option at the moment
[21:10] <Peng_> nxsryan: Bazaar does a bit of magic to turn it into a real URL.
[21:11] <vila> what do 'bzr version' and 'bzr plugins' say ?
[21:11] <nxsryan> # bzr branch lp:trac-bzr
[21:11] <Peng_> nxsryan: lp:trac-bzr points to http://bazaar.launchpad.net/%7Etrac-bzr-team/trac-bzr/trunk/ or bzr+ssh://bazaar.launchpad.net/%7Etrac-bzr-team/trac-bzr/trunk/
[21:11] <nxsryan> bzr: ERROR: Not a branch: /root/trac-bzr/lp:trac-bzr/
[21:11] <nxsryan> Peng_: ah, nice, thank you
[21:12] <Peng_> /root? *cough*
[21:17] <Peng_> ...The Launchpad plugin has been around *forever*.
[21:18] <nxsryan> hrm, bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 6 (bzr 0.15)\n'
[21:19] <vila> nxsryan: what do 'bzr version' and 'bzr plugins' say ?
[21:20] <nxsryan> i'm using 0.14
[21:20] <vila> then, you need to upgrade to at least 0.15 at the message is hinting
[21:21] <vila> but since 1.11 is out, please, just upgrade to that instead :)
[21:21] <Peng_> Huh, lp: URIs are newer than 0.14?
[21:22] <Peng_> Hmm, I think it was added in revision 2275.
[21:22] <dereine> hi is it possible to update a certain branch without ssh access, just ftp
[21:23] <vila> Peng_: I dont't know I have all releases available from 1.0 but not earlier
[21:23] <vila> dereine: It should
[21:23] <dereine> vila: i pushed to files onto the server
[21:23] <dereine> then i tryed to use update
[21:24] <dereine> but it didn't wokred
[21:24] <Peng_> Yeah, it was added in revision 2275. Apparently it wasn't found NEWSworthy though.
[21:24] <Peng_> But that would've been around 0.15 or 0.16.
[21:24] <Peng_> Yeah, 0.15.
[21:25] <vila> dereine: update updates your working tree from the branch, do you want pull instead ?
[21:26] <poolie> jam, nice work on the locking patch
[21:26] <dereine> vila: does pull changes the files itself?
[21:26] <jam> vila: pong
[21:26] <vila> dereine: pull updates your working tree yes
[21:26] <jam> poolie: thanks. I don't really *like* doing it that way, but since we have been waiting a long time to actually do it the right way
[21:26] <dereine> i will have a try thx
[21:26] <jam> I figured we may as well do *something*
[21:59] <poolie> beuno: if __name__ == 'bzrlib.plugins.loggerhead':
[22:04] <jml> poolie: that won't work :(
[22:04] <jml> try: from bzrlib.plugins import loggerhead; except ImportError: pass; else: ...
[22:07] <jml> hmm. actually, that would work
[22:07] <jml> silly me
[22:08] <beuno> Peng_, loggerhead trunk needs you
[22:10] <Peng_> Heh.
[22:18] <Peng_> Oh, it just serves them as static files so far?
[22:18] <jml> mwhudson: good morning. :)
[22:19] <beuno> Peng_, yeap
[22:19] <beuno> no smart server involved yet
[22:23] <Peng_> Hmm, this conflicts with my setup. I have the branches available (with hpss) at /bzr, with LH at /loggerhead.
[22:24] <beuno> Peng_, and how does this overlap?
[22:24] <jml> Peng_: you mean the URLs that loggerhead gives are the static LH urls, not the smart /bzr ones?
[22:24] <jml> because they should both quietly mind their own business wrt serving branches.
[22:26] <Peng_> beuno: Loggerhead suggests branching it from /loggerhead.
[22:26] <Peng_> I already handle this with redirects, but it's messy.
[22:26] <beuno> Peng_, ah!
[22:26] <beuno> so it should be configurable
[22:26] <beuno> -ish
[22:28] <Peng_> Well, I could do some ugly monkeypatch in serve-branches, so it already is "-ish". :D
[22:29] <beuno> :)
[22:31] <Peng_> Or I could just edit branch.py itself, of course, but that seems wrong.
[22:33] <Peng_> Oh wow, monkeypatching actually works easily.
[22:35] <beuno> well, it *is* loggerhead
[22:36] <beuno> igc, ping
[22:36] <Peng_> I was expecting the property bits to make it difficult to monkeypatch.
[22:42] <Peng_> Yay, my evil monkeypatch worked.
[22:44] <Peng_> beuno: Anyway, I haven't experienced any problems.
[22:45] <beuno> Peng_, awesome
[22:45] <beuno> and if you file a bug about maybe not exposing the URLs to branch from
[22:45] <beuno> we'll get it done
[22:45] <beuno> just for you
[22:46] <Peng_> But I only tested /changes, /revision, and /annotate; not the other pages, or the .bzr serving itself.
[22:46] <igc> hi beuno
[22:46] <beuno> hiya igc. How are you?
[22:47] <igc> not too bad
[22:48] <beuno> I've been playing for quite a while with your plugin
[22:48] <beuno> revnocache
[22:48] <beuno> igc, are you up to explaining some concepts/code?   I'd like to pitch in a little bit if I can
[22:49] <igc> sure
[22:49] <beuno> you're using repository._old_get_graph
[22:49] <beuno> to get the graph
[22:49] <igc> I'm about to hack on it right now btw :-)
[22:49] <beuno> awesome then!~
[22:49] <igc> I'm doing whatever Branch.get_revision_id_to_revno_map() uses now
[22:50] <beuno> I'm curious about you using that bit, since bzrlib has a big comment: """DO NOT USE. That is all. I'm serious."""
[22:50] <igc> 'cause I'm monkeypatching it
[22:50] <igc> Right
[22:50] <igc> beuno: the current code is very short term hopefully
[22:51] <igc> I have a patch up to Branch giving it a new method: iter_merge_sorted_revisions()
[22:51] <igc> as soon as that lands, I'll look against it rather than the revo lookup hack
[22:51] <igc> s/revo/revno/
[22:51] <Peng_> beuno: Wait, what do you want me to file a bug about?
[22:52] <igc> s/look/hook/
[22:52] <beuno> Peng_, maybe hiding the branch URL?
[22:52] <beuno> igc, so there's not other (good) way of doing this without patching bzrlib?
[22:53] <Peng_> beuno: I like having to branch URL shown, I just want it to be different. :)
[22:53] <beuno> Peng_, fair enough. What could we do to address your use case?  Use hpss by default?
[22:53] <igc> beuno: not sure
[22:53] <igc> but the right direction is caching the graph ...
[22:54] <beuno> igc, absolutely
[22:54] <igc> because then revno lookup, log, missing and friends can all "go fast"
[22:54] <Peng_> beuno: I'm not sure what you could do to address my use case. :P
[22:54] <beuno> igc, I'm trying to understand it in depth, so I can make it play nic with loggerhead
[22:54] <igc> right now, it's only the first of these
[22:54] <beuno> igc, in LH, to get the revision graph I do something like: http://paste.ubuntu.com/108777/
[22:55] <igc> beuno: see I think you want iter_merge_sorted_revisions() as soon as it exists
[22:56] <beuno> igc, I do!
[22:56] <beuno> I'm stalking the ML waiting for that to land
[22:56] <igc> beuno: I just posted an updated version a hour or so ago
[22:56] <beuno> igc, I saw. Waiting for jam to be happy and approve  :)
[22:56] <igc> beuno: please check that it's API is useful to you know that I've extended it as jam requested
[22:57] <igc> s/know/now/
[22:57] <beuno> igc, I'll go through the code now and add a comment
[22:57] <igc> beuno: cool. If poolie is near-by, bug him to look at it too :-)
[22:58] <beuno> igc, he's across the table from me. Not very awake, but here. I'll poke
[22:59] <poolie> hello
[22:59] <igc> poolie: ignore that poke if you're tired. I understand the value of sleep :-)
[23:01] <beuno> igc, so this patch lets you limit the range of the graph you generate?
[23:01] <beuno> IIUC
[23:01] <beuno> by using revids?
[23:01] <igc> beuno: yes
[23:01] <beuno> igc, unless I request revnos?
[23:01] <beuno> +        # Note: depth and revno values are in the context of the branch so
[23:01] <beuno> +        # we need the full graph to get stable numbers, regardless of the
[23:01] <beuno> +        # start_revision_id.
[23:03] <igc> beuno: my goal is that, once loggerhead uses iter_merge_sorted_revisions(), it needs to do nothing else and it will get faster if revnocache is installed as well
[23:03] <poolie> igc: i bet
[23:04] <igc> beuno: so my patch now generates and caches (in memory) the full branch graph
[23:04] <beuno> igc, I see. We currently cache the revision graphs in LH as well, using LRUCache
[23:04] <igc> revnocache will complement that by saving/restoring the full graph, eliminating the calculation stage (except after a tip move)
[23:05] <beuno> aha!  that's where it gets interesting
[23:05] <beuno> we would load the graph from disk instead of re-generating it
[23:05] <igc> yes - revnocache does not now
[23:06] <igc> (with the right CACHING_STRATEGY configured)
[23:06] <beuno> igc, I still get around 7sec to do 'bzr log -r X.Y.Z' on mysql-server
[23:06] <beuno> with mergegraph strategy
[23:06] <igc> right, because log is regenerating the graph!
[23:06] <beuno> and a bit less with revno strategy
[23:06] <beuno> ah!
[23:06] <beuno> hence the patch
[23:06] <igc> precisely
[23:06] <igc> (and a follow-up refactor of log to call the new API)
[23:07] <beuno> igc, ok, so for LH to take advantage of this, this patch has to land, and I have to switch LH over to using iter_merge_sorted_revisions
[23:08] <igc> beuno: yes
[23:08] <beuno> perfect
[23:08] <beuno> just perfect
[23:08] <igc> beuno: so my coming revnocache hacks are ...
[23:08] <igc> 1. change the graph cache to drop the seqnum
[23:08] <igc> 2. support chaining
[23:09] <igc> The latter will let us store just the graph since the parent
[23:09] <igc> and point to the parent cache if it's local
[23:09] <igc> perfect for the usual mirror+feature-branches setup
[23:09] <beuno> cool, so it'll be less expensive when the branch gets updated
[23:09] <beuno> as long as it hasn't done merges?
[23:10] <igc> right, and much less storage
[23:10]  * poolie goes to look
[23:10] <igc> beuno: tip moves aren't optimised yet, merges or otherwise
[23:10] <beuno> igc, I do wonder why your patch still uses repository._old_get_graph
[23:11] <beuno> igc, right, that was one of the things I thought I'd try to poke at, as soon as I figured out all of this. But you're already on it  :)
[23:11] <igc> beuno: only because I wanted to ensure my monkeypatch was bug-for-bug compatible
[23:12] <igc> beuno: actually, I've love it if you could optimise the tip move bit
[23:12] <igc> (it's not high on my list yet)
[23:13] <enigma42> jelmer: Ping
[23:13] <jelmer> enigma42, pong
[23:13] <igc> beuno: but you may want to wait a few hours until my next round of hacks ...
[23:13] <enigma42> This has got to be the strangest error I've seen yet.
[23:13] <beuno> igc, I could very well give it a try. It's past 9pm here, so not sure *when*, but it will be high in my list  :)
[23:13] <enigma42> jelmer: bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack
[23:13] <poolie> igc, you're refering to iter_merge_sorted_revisions?
[23:13] <enigma42> Let me pastebin it.
[23:13] <jelmer> enigma42, full backtrace?
[23:13] <igc> poolie: yes
[23:14] <igc> beuno: I'll put comments in the code and/or fire you an email about how to do it
[23:14] <beuno> igc, FWIW, I changed LH from _old_get_graph to get_graph() without any consecuences  :)
[23:14] <beuno> igc, that would be awesome
[23:14] <enigma42> jelmer: http://pastebin.ubuntu.com/108782/
[23:15] <igc> beuno: ok, it's saturday morning here so my time is limited
[23:16] <igc> better get on with this hacking or it won't happen for a few days (long weekend here) :-)
[23:16] <beuno> igc, oh, please don't feel imposed. I'll give it a quick whack and see if I can send a patch to your patch  :)
[23:16] <enigma42> jelmer: This is bzr-svn 0.5 revno 2372
[23:16] <poolie> the good thing about having an intense sprint in argentina is that people (and restaurants) _expect_ to eat dinner at 11pm :)
[23:16] <jelmer> enigma42, when does this happen?
[23:17] <igc> poolie: :-)
[23:17] <enigma42> So, this is an svn repo that has been used by bzr-svn 0.4.x for a while.
[23:17] <enigma42> This happens when branching.
[23:17] <enigma42> This is the first time I've tried 0.5 on it.
[23:17] <jelmer> enigma42, so it's a different repository
[23:17] <jelmer> ?
[23:17] <enigma42> Right. Not the one from before.
[23:17] <enigma42> This is a new repo I haven't posted about before.
[23:18] <enigma42> Coworker of mine was using bzr-svn 0.4 on it.
[23:18] <enigma42> First symptom was...
[23:18] <enigma42> Could pull down a branch just fine, but then could not make a local branch.
[23:18] <enigma42> (with 0.4.x)
[23:19] <enigma42> When trying to make the local branch, it complains about missing revisions.
[23:19] <enigma42> So, I thought I would give it a try with 0.5-trunk to see what happens.
[23:19] <enigma42> And that's the backtrace I posted.
[23:19] <jelmer> enigma42: So this is an error trying to parse one of the bzr-svn file properties
[23:19] <enigma42> OK.
[23:19] <enigma42> jelmer: That doesn't sound very fixable...is it?
[23:20] <enigma42> I guess what I mean is the file property is probably messed up....
[23:20] <enigma42> Let me check to see if there are any revprops on this svn repo....
[23:21] <jelmer> enigma42, it's not a revprop that is invalid, it's a fileprop
[23:22] <enigma42> OK.
[23:24] <enigma42> hughesw: This is your repo...when did you start having the problem?
[23:24] <hughesw> monday. after updating to bzr 1.10 and bzr-svn 0.4.16 from the package on the bazaar site.
[23:26] <hughesw> whoops
[23:26] <jelmer> any chance you can try with a patch that shows a bit more information?
[23:26] <enigma42> I'm happy to.
[23:26] <enigma42> Send me the patch. :-)
[23:27] <enigma42> (this patch would be against 0.5, right?)
[23:27] <jelmer> yes
[23:28] <jelmer> http://samba.org/~jelmer/tmp/fileid-fileprop.diff
[23:28] <enigma42> OK....patching....
[23:29] <enigma42> jelmer: Should I zap the cache?
[23:29] <jelmer> enigma42, no
[23:29] <enigma42> OK
[23:32] <enigma42> jelmer: branching....there are some big files in this repo so it takes a while....
[23:32] <hughesw> yeah the trunk of that repo is 52 MB...
[23:34] <beuno> igc, maybe something like this: http://paste.ubuntu.com/108789/
[23:37] <enigma42> jelmer: http://pastebin.ubuntu.com/108793/
[23:38] <jelmer> Are you sure that's with the patch applied? it doesn't seem to trigger the exception handling
[23:38] <poolie> (back to reading igc's patch thread)
[23:39] <enigma42> jelmer: I'll double check to be sure. But I'm pretty sure...
[23:40] <jelmer> enigma42, alternatively, can you run with BZR_PDB=1 as environment variable set?
[23:40] <enigma42> Yup. I just double checked...it has the patch for sure.
[23:40] <enigma42> OK.
[23:41] <jelmer> enigma42, ah, sorry
[23:41] <jelmer> enigma42, what did it print on the screen?
[23:41] <jelmer> enigma42, rather than to .bzr.log ?
[23:45] <enigma42> Just pasting.....
[23:45] <enigma42> http://pastebin.ubuntu.com/108796/
[23:45] <enigma42> Should I type anything at the Pdb prompt?
[23:45] <hughesw> hey that looks remarkably similar to the error it was giving me when I tried to branch on my home machine with 0.4.16
[23:47] <beuno> jml, http://people.samba.org/bzr/jelmer/bzr-gtk/trunk/
[23:49] <poolie> igc, done
[23:50] <igc> poolie: thanks
[23:51] <poolie> jml: http://groups.google.com/group/fp-syd?hl=en
[23:57] <enigma42> jelmer: Just let me know if you want me to send you more info.