[01:48] hi mwhudson [01:48] i'm going to try to fix some outstanding lp branches today [01:48] typing very slowly :) [06:28] hi vila ? [06:28] did you implicitly fix bug 307316, or is that a dupe of something you know about? [06:28] Launchpad bug 307316 in Bazaar "Contents conflicts in checkouts end up in .OTHER being added to the repository (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/307316 [06:52] poolie: almost there (~20min), I wasn't subscribed to this one, probably fixed, will check [07:23] hi all ! [07:24] Oh, it must be time for me to leave... === stewart_ is now known as stewart [07:38] 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] Launchpad bug 307316 in Bazaar "Contents conflicts in checkouts end up in .OTHER being added to the repository (affected: 1, heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/307316 [07:38] meh [07:38] sorry peitschie, that was for poolie :-/ [07:38] fullermd: no comment ! [07:38] :) [07:38] Hey! That was a comment! [07:38] first typo of the day... [07:39] bah, I wanted to type tyop.... if I can't even make typos on demand now... [07:40] «C'est ne pas une comment» ;) [07:41] hehe, un commentaire :) Literally 'comment' in French means 'how' :) [07:41] vila: merci :) [07:42] de rien :) [07:46] vila: I was scratchin my head for a little there lol :) [07:56] vila, hi === stewart_ is now known as stewart [10:35] It seems to me like loggerhead has a lot of stuff that really ought to be in bzrlib. [10:36] poolie: I think that at some point, a worthwhile project would be to de-duplicate loggerhead and bzrlib code. [10:37] A lot of what loggerhead's backend code does is create wrappers around bzrlib objects with caches on them. [10:37] 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] So we're probably duplicating bzr's existing memory usage. [10:38] And making it thread-safe. [10:38] mkanat: +1 [10:38] :-) [10:39] On horrible old repo formats, bzrlib probably isn't as fast or cachy. [10:40] Yeah, true, but in that case, we'd just say "loggerhead will be painfully slow until you upgrade your repo". [10:40] Yup. [10:40] It would be way better than, "loggerhead will always consume huge amounts of RAM and probably break". :-) [10:40] Definitely. [10:41] I'd love to eliminate as much as possible of the History object from loggerhead. [10:43] Like, is it still slow to call repository.get_inventory(revid) over and over on the same revid? [10:46] Hmm, I suppose it still is. [10:49] And we're getting a whole inventory just to get a single file's id, or something. [10:50] Is this really the fastest and best way to get a file's text? http://pastie.org/1319718 [10:50] And name. [10:51] haha, os.path! [10:52] ...Actually, that probably makes sense... [10:52] Although actually, I think we don't even need the file name. [10:52] We just pass it to highlight(), and I don't see what highlight does with it, if anything. [10:53] mkanat: Type detection based on teh file extension. [10:53] Ohhh. [10:53] Pesumably. [10:53] Presumably* [10:53] Right, that makes sense. [10:54] 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] Okay. [10:54] * Peng shrugs [10:54] * Peng doesn't really know how Pygments works [10:54] 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] Hahahaha. [10:54] Noo idea! [10:55] * mkanat looks at bzrlib.repository some more. [11:14] mkanat: Repository.iter_files_bytes is probably a slightly better way to get the contents of a file [11:14] spiv: Okay, that's the impression I was getting from the bzrlib docs. [11:15] mkanat: and the best way to get a file name is probably inv[file_id].name [11:15] spiv: Okay. So I do need a whole inventory for that? [11:15] mkanat: where inv is retrieved via Repository.get_inventory or iter_inventories [11:16] mkanat: well, in 2a that won't need to read in the whole inventory [11:16] All right. We have stuff that does that already. [11:16] Which should probably be in bzrlib--get_path(revid, file_id) [11:17] 2a fixes a lot of problems we used to have where you couldn't avoid reading the entire inventory [11:17] morning [11:17] 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] spiv: Okay. [11:18] mkanat: note that inv[file_id].name is not the full path of the file in the tree [11:18] spiv: Okay. Just its name? That's actually all I want. [11:18] mkanat: just the file's name in its directory [11:19] Great. [11:19] Getting the full path is more complex (and so more expensive) [11:19] (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] So if loggerhead is calculating the full path... then it's wasting effort. [11:20] Yeah. It was doing it because it already had an inventory cache. [11:22] I'd definitely be interested to hear how loggerhead goes if you rip that cache out. [11:22] 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] 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] spiv: BTW, iter_file_bytes is not documented in Repository? [11:23] mkanat: iter_files_bytes [11:23] 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] Ahh, thanks. :-) [11:23] can someone take a look at tell me what is wrong? [11:25] spiv: Also, we're doing this: http://pastie.org/1319780 [11:25] spiv: Is that really necessary, or is there some self-decoding text retriever? [11:26] mkanat: bzr stores files as a sequence of bytes, and doesn't know what encoding they are in :( [11:27] spiv: Okay. So I'm guessing the internal "annotate" does something like this as well? [11:27] 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] 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] mkanat: I'm not sure. [11:28] * mkanat nods. [11:29] hrw: compare the two branches with e.g. 'bzr qlog branch1 branch2' [11:29] ok [11:29] hrw: you'll see that actually 1.53-rebased appears to have branched off revision 2 of the other one [11:29] spiv: Okay, yeah, annotate has in it to deal with encoding, too. [11:30] *has code [11:30] hrw: i.e. only the first two revisions are common, and the rest need to be merged. [11:32] hrw: it appears these two branches are what we call "parallel imports" [11:33] spiv: they are [11:33] spiv: I use git-bzr-ng to import bzr into git, do all work and then 'bzr git-import' + 'bzr push' [11:34] @_@ [11:34] hrw: unfortunately it's late here so I'm off to bed. Hopefully someone else can help you out from here. [11:34] spiv: Good night. :) [11:35] spiv: sweet dreams then [11:36] looks like I need to find out how to emulate "git am" in bzr [11:36] hrw: There is "bzr git-apply" [11:36] hrw: It's part of the bzr-git plugin. [11:36] jelmer: cool [11:37] lovely [11:37] jelmer: thx a lot [11:39] All changes applied successfully. [11:39] uf. [11:41] 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] spiv: What's the standard way that I'm supposed to concatenate all of iter_files_bytes to get a single string? [11:42] 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] is someone aware of an up to date comparison of metadata maintained by bzr vs that of git? [11:43] jelmer: for my use of bzr it is enough [11:45] 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] Kamping_Kaiser: bzr has file ids (rename tracking), revision ids, revision properties, ghost parent revisions, git has submodules [11:46] hrw: yes, merge does not imply a commit [11:46] ok [11:48] now it is time to recreate another branches ;( [11:49] jelmer: ok. i'll investigate submodiles to find out what they do. thanks [11:49] Kamping_Kaiser: submodules are similar to svn:externals [11:49] Kamping_Kaiser: they're like nested trees [11:49] Kamping_Kaiser: what's the background of the question? [11:50] jelmer: ultimately i'm wondering if there is data loss transfering between bzr and git [11:52] Kamping_Kaiser: git -> bzr is lossless, except where submodules are involved, the other way around is lossful. [11:53] jelmer: ok. and the things that get lost are the bits you mentioned above? [11:54] Kamping_Kaiser: yep [11:56] 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] Kamping_Kaiser: git infers renames on the fly [11:56] ah [11:56] in other words, renames in git are a representation issue [11:58] right. [11:58] jelmer: bzr->git is lossful? what do you lose? [11:58] hrw: see above [11:59] ahmm renames [11:59] 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] Kamping_Kaiser: So the fact that files have names is pretty much a strange, incidental fact. :-) [12:01] Kamping_Kaiser: ah, there's another one. directories are implicit too, so empty directories (or directories with empty directories) are lost. [12:02] mkanat: hm, i seem to recall hearing that before. hopefully it stays in my brain this time [12:02] jelmer: hm, ok [12:03] jelmer: thanks a lot for "bzr git-apply" - you made my live (as git user) much much easier [12:04] now if there is a command to request merge review... [12:05] 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] hrw: I think there's "bzr lp-propose" [12:05] found - lp-propose-merge [12:06] 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] Anyone have a hand in the Bazaar plugin for Hudson? === seiflotfy_ is now known as seiflotfy [13:54] hey there [13:54] does anyone happen to be involved in configglue development? [13:55] have a nice rest of day [13:56] ambv: no, what is configglue? [13:57] it's a Canonical project that blends ConfigParser with optparse, adding validation and a consistent API. [13:58] ambv: perhaps ask in the ubuntu one channel, it seems to've come out of ubuntu one. [13:59] jelmer: believe it or not, there's #configglue [14:00] haha [14:00] thanks anyway :) === beuno is now known as beuno-lunch === Leonidas_ is now known as Leonidas === deryck is now known as deryck[lunch] === rockstar` is now known as rockstar === Vorpal_ is now known as Vorpal === oubiwann is now known as oubiwann-away === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === oubiwann-away is now known as oubiwann === maxb_ is now known as maxb [20:32] hi all === glyph_ is now known as glyph [21:11] hi poolie, how's it going? [21:17] * jelmer waves to poolie, jam [21:18] jam, hi [21:18] and jelmer [21:28] Good morning. [21:35] hi there spiv [22:28] 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] chx, i don't think so, but it should be fairly easy to add [22:37] poolie: what should i rtfm? [22:38] maybe it can be even a shell script? something with return values. maybe. a pluginwould be better. [22:41] how about just a shell script or alias that does 'bzr update && bzr commit "$@"' [22:47] hrm, probably.