[01:48] <poolie> hi mwhudson
[01:48] <poolie> i'm going to try to fix some outstanding lp branches today
[01:48] <poolie> typing very slowly :)
[06:28] <poolie> hi vila ?
[06:28] <poolie> did you implicitly fix bug 307316, or is that a dupe of something you know about?
[06:52] <vila> poolie: almost there (~20min), I wasn't subscribed to this one, probably fixed, will check
[07:23] <vila> hi all !
[07:24] <fullermd> Oh, it must be time for me to leave...
[07:38] <vila> peitschie: so, bug #307316 has not been fixed. I don't have plans to fix it either :-/ There are two main issues here, one is the names switching between THIS and OTHER (but that's just a reflexion on what happens underneath), the other is renaming into .OTHER a versioned file
[07:38] <vila> meh
[07:38] <vila> sorry peitschie, that was for poolie  :-/
[07:38] <vila> fullermd: no comment !
[07:38] <vila> :)
[07:38] <fullermd> Hey!  That was a comment!
[07:38] <vila> first typo of the day...
[07:39] <vila> bah, I wanted to type tyop.... if I can't even make typos on demand now...
[07:40] <spiv> «C'est ne pas une comment»  ;)
[07:41] <vila> hehe, un commentaire :) Literally 'comment' in French means 'how' :)
[07:41] <spiv> vila: merci :)
[07:42] <vila> de rien :)
[07:46] <peitschie> vila: I was scratchin my head for a little there lol :)
[07:56] <poolie> vila, hi
[10:35] <mkanat> It seems to me like loggerhead has a lot of stuff that really ought to be in bzrlib.
[10:36] <mkanat> poolie: I think that at some point, a worthwhile project would be to de-duplicate loggerhead and bzrlib code.
[10:37] <mkanat> A lot of what loggerhead's backend code does is create wrappers around bzrlib objects with caches on them.
[10:37] <mkanat> A lot of that is probably historical, from when bzr was much slower than it is now, and I'd bet that bzr even has these caches itself in some cases, now.
[10:37] <mkanat> So we're probably duplicating bzr's existing memory usage.
[10:38] <mkanat> And making it thread-safe.
[10:38] <spiv> mkanat: +1
[10:38] <mkanat> :-)
[10:39] <Peng> On horrible old repo formats, bzrlib probably isn't as fast or cachy.
[10:40] <mkanat> Yeah, true, but in that case, we'd just say "loggerhead will be painfully slow until you upgrade your repo".
[10:40] <Peng> Yup.
[10:40] <mkanat> It would be way better than, "loggerhead will always consume huge amounts of RAM and probably break". :-)
[10:40] <Peng> Definitely.
[10:41] <mkanat> I'd love to eliminate as much as possible of the History object from loggerhead.
[10:43] <mkanat> Like, is it still slow to call repository.get_inventory(revid) over and over on the same revid?
[10:46] <mkanat> Hmm, I suppose it still is.
[10:49] <mkanat> And we're getting a whole inventory just to get a single file's id, or something.
[10:50] <mkanat> Is this really the fastest and best way to get a file's text? http://pastie.org/1319718
[10:50] <mkanat> And name.
[10:51] <Peng> haha, os.path!
[10:52] <Peng> ...Actually, that probably makes sense...
[10:52] <mkanat> Although actually, I think we don't even need the file name.
[10:52] <mkanat> We just pass it to highlight(), and I don't see what highlight does with it, if anything.
[10:53] <Peng> mkanat: Type detection based on teh file extension.
[10:53] <mkanat> Ohhh.
[10:53] <Peng> Pesumably.
[10:53] <Peng> Presumably*
[10:53] <mkanat> Right, that makes sense.
[10:54] <Peng> Not sure how necessary it is, though, since it analyzes the content too. But I think being able to use the file extension is supposed to make it more efficient or something.
[10:54] <mkanat> Okay.
[10:54]  * Peng shrugs
[10:54]  * Peng doesn't really know how Pygments works
[10:54] <mkanat> Is that really the best way to get the text, though? iter a whole inventory just so that I can get a revision tree, and then get the text from the revision tree?
[10:54]  * Peng is happy that way.
[10:54] <mkanat> Hahahaha.
[10:54] <Peng> Noo idea!
[10:55]  * mkanat looks at bzrlib.repository some more.
[11:14] <spiv> mkanat: Repository.iter_files_bytes is probably a slightly better way to get the contents of a file
[11:14] <mkanat> spiv: Okay, that's the impression I was getting from the bzrlib docs.
[11:15] <spiv> mkanat: and the best way to get a file name is probably inv[file_id].name
[11:15] <mkanat> spiv: Okay. So I do need a whole inventory for that?
[11:15] <spiv> mkanat: where inv is retrieved via Repository.get_inventory or iter_inventories
[11:16] <spiv> mkanat: well, in 2a that won't need to read in the whole inventory
[11:16] <mkanat> All right. We have stuff that does that already.
[11:16] <mkanat> Which should probably be in bzrlib--get_path(revid, file_id)
[11:17] <spiv> 2a fixes a lot of problems we used to have where you couldn't avoid reading the entire inventory
[11:17] <hrw> morning
[11:17] <spiv> So if loggerhead is caching stuff to work around that sort of problem, I'd definitely try removing the cache and seeing how it goes.
[11:18] <mkanat> spiv: Okay.
[11:18] <spiv> mkanat: note that inv[file_id].name is not the full path of the file in the tree
[11:18] <mkanat> spiv: Okay. Just its name? That's actually all I want.
[11:18] <spiv> mkanat: just the file's name in its directory
[11:19] <mkanat> Great.
[11:19] <spiv> Getting the full path is more complex (and so more expensive)
[11:19] <spiv> (I mean, more complex for bzrlib to do, I know there's an equally simple API for it somewhere)
[11:19]  * mkanat nods.
[11:20] <spiv> So if loggerhead is calculating the full path... then it's wasting effort.
[11:20] <mkanat> Yeah. It was doing it because it already had an inventory cache.
[11:22] <spiv> I'd definitely be interested to hear how loggerhead goes if you rip that cache out.
[11:22] <hrw> I have a problem. I have one branch up to r128 and second which is r129-136. during merge it gives me text conflicts. so I decided to check which rev has a problem. "bzr merge -r129 ../merge-1.53" told me that there are text conflicts on debian/control and debian/changelog - but r129 changes only debian/rules ;(
[11:22] <mkanat> spiv: Okay. :-) It's not much work, I suppose I could try it. I just have to learn and locate the proper bzrlib methods.
[11:22] <mkanat> spiv: BTW, iter_file_bytes is not documented in Repository?
[11:23] <spiv> mkanat: iter_files_bytes
[11:23] <hrw> first branch is lp:ubuntu/armel-cross-toolchain-base and second is lp:~hrw/ubuntu/natty/armel-cross-toolchain-base/1.53-rebased/
[11:23] <mkanat> Ahh, thanks. :-)
[11:23] <hrw> can someone take a look at tell me what is wrong?
[11:25] <mkanat> spiv: Also, we're doing this: http://pastie.org/1319780
[11:25] <mkanat> spiv: Is that really necessary, or is there some self-decoding text retriever?
[11:26] <spiv> mkanat: bzr stores files as a sequence of bytes, and doesn't know what encoding they are in :(
[11:27] <mkanat> spiv: Okay. So I'm guessing the internal "annotate" does something like this as well?
[11:27] <spiv> mkanat: so if you want to display them as text you basically just have to guess the encoding :(
[11:27]  * mkanat goes to read bzr cat.
[11:28] <spiv> mkanat: the internal annotate probably just relies on \n always being the line delimiter, and then hoping that the terminal encoding matches the file encoding.
[11:28] <spiv> mkanat: I'm not sure.
[11:28]  * mkanat nods.
[11:29] <spiv> hrw: compare the two branches with e.g. 'bzr qlog branch1 branch2'
[11:29] <hrw> ok
[11:29] <spiv> hrw: you'll see that actually 1.53-rebased appears to have branched off revision 2 of the other one
[11:29] <mkanat> spiv: Okay, yeah, annotate has in it to deal with encoding, too.
[11:30] <mkanat> *has code
[11:30] <spiv> hrw: i.e. only the first two revisions are common, and the rest need to be merged.
[11:32] <spiv> hrw: it appears these two branches are what we call "parallel imports"
[11:33] <hrw> spiv: they are
[11:33] <hrw> spiv: I use git-bzr-ng to import bzr into git, do all work and then 'bzr git-import' + 'bzr push'
[11:34] <Peng> @_@
[11:34] <spiv> hrw: unfortunately it's late here so I'm off to bed.  Hopefully someone else can help you out from here.
[11:34] <Peng> spiv: Good night. :)
[11:35] <hrw> spiv: sweet dreams then
[11:36] <hrw> looks like I need to find out how to emulate "git am" in bzr
[11:36] <jelmer> hrw: There is "bzr git-apply"
[11:36] <jelmer> hrw: It's part of the bzr-git plugin.
[11:36] <hrw> jelmer: cool
[11:37] <hrw> lovely
[11:37] <hrw> jelmer: thx a lot
[11:39] <hrw> All changes applied successfully.
[11:39] <hrw> uf.
[11:41] <jelmer> hrw: np. Please report bugs if you find any; the parser seems to be a bit stricter than "git am" at the moment, and I've only tested it with a small number of files so far (~100)
[11:41] <mkanat> spiv: What's the standard way that I'm supposed to concatenate all of iter_files_bytes to get a single string?
[11:42] <jelmer> It just uses "patch" under the hood at the moment, it should be possible to make it use bzr's merge code at some point.
[11:42] <Kamping_Kaiser> is someone aware of an up to date  comparison of metadata maintained by bzr vs that of git?
[11:43] <hrw> jelmer: for my use of bzr it is enough
[11:45] <hrw> but other thing.. if I do "bzr branch lp:soemthing;cd soemthing;bzr merge lp:other" then 'bzr log' does not shows merged tree even with --include-merges option. why? I have to commit merges?
[11:46] <jelmer> Kamping_Kaiser: bzr has file ids (rename tracking), revision ids, revision properties, ghost parent revisions, git has submodules
[11:46] <jelmer> hrw: yes, merge does not imply a commit
[11:46] <hrw> ok
[11:48] <hrw> now it is time to recreate another branches ;(
[11:49] <Kamping_Kaiser> jelmer: ok. i'll investigate submodiles to find out what they do. thanks
[11:49] <hrw> Kamping_Kaiser: submodules are similar to svn:externals
[11:49] <jelmer> Kamping_Kaiser: they're like nested trees
[11:49] <jelmer> Kamping_Kaiser: what's the background of the question?
[11:50] <Kamping_Kaiser> jelmer: ultimately i'm wondering if there is data loss transfering between bzr and git
[11:52] <jelmer> Kamping_Kaiser: git -> bzr is lossless, except where submodules are involved, the other way around is lossful.
[11:53] <Kamping_Kaiser> jelmer: ok. and the things that get lost are the bits you mentioned above?
[11:54] <jelmer> Kamping_Kaiser: yep
[11:56] <Kamping_Kaiser> jelmer: i'm suppried there is no rename tracking in git. the other parts i don't understand well enough to hae an opinion on
[11:56] <jelmer> Kamping_Kaiser: git infers renames on the fly
[11:56] <Kamping_Kaiser> ah
[11:56] <jelmer> in other words, renames in git are a representation issue
[11:58] <Kamping_Kaiser> right.
[11:58] <hrw> jelmer: bzr->git is lossful? what do you lose?
[11:58] <jelmer> hrw: see above
[11:59] <hrw> ahmm renames
[11:59] <mkanat> Kamping_Kaiser: Part of the basic philosophy of git is that it's not tracking files, just content and a bunch of changes to that content.
[11:59] <mkanat> Kamping_Kaiser: So the fact that files have names is pretty much a strange, incidental fact. :-)
[12:01] <jelmer> Kamping_Kaiser: ah, there's another one. directories are implicit too, so empty directories (or directories with empty directories) are lost.
[12:02] <Kamping_Kaiser> mkanat: hm, i seem to recall hearing that before. hopefully it stays in my brain this time
[12:02] <Kamping_Kaiser> jelmer: hm, ok
[12:03] <hrw> jelmer: thanks a lot for "bzr git-apply" - you made my live (as git user) much much easier
[12:04] <hrw> now if there is a command to request merge review...
[12:05] <jelmer> hrw: glad to hear it's useful. I use it to apply patches from git-using contributors on a project that's maintained in parallel in bzr and git.
[12:05] <jelmer> hrw: I think there's "bzr lp-propose"
[12:05] <hrw> found - lp-propose-merge
[12:06] <mkanat> spiv: I'll have to get you the info on the difference with and without cache on a later day. But I will let you know if I remember, when I'm done switching things around.
[12:18] <awilkins> Anyone have a hand in the Bazaar plugin for Hudson?
[13:54] <ambv> hey there
[13:54] <ambv> does anyone happen to be involved in configglue development?
[13:55] <hrw> have a nice rest of day
[13:56] <jelmer> ambv: no, what is configglue?
[13:57] <ambv> it's a Canonical project that blends ConfigParser with optparse, adding validation and a consistent API.
[13:58] <jelmer> ambv: perhaps ask in the ubuntu one channel, it seems to've come out of ubuntu one.
[13:59] <ambv> jelmer: believe it or not, there's #configglue
[14:00] <ambv> haha
[14:00] <ambv> thanks anyway :)
[20:32] <poolie> hi all
[21:11] <jam> hi poolie, how's it going?
[21:17]  * jelmer waves to poolie, jam
[21:18] <poolie> jam, hi
[21:18] <poolie> and jelmer
[21:28] <spiv> Good morning.
[21:35] <poolie> hi there spiv
[22:28] <chx> Hi. Is there a plugin or something I could deploy that would automatically to try bzr up in case a commit fails on a bound branch ? too often i run a commit , turn to something else because it takes a while to commit over the network and forget that it failed jsut because someone else changed something else at a totally different place
[22:37] <poolie> chx, i don't think so, but it should be fairly easy to add
[22:37] <chx> poolie: what should i rtfm?
[22:38] <chx> maybe it can be even a shell script? something with return values. maybe. a pluginwould be better.
[22:41] <poolie> how about just a shell script or alias that does 'bzr update && bzr commit "$@"'
[22:47] <chx> hrm, probably.