| poolie | hi mwhudson | 01:48 |
|---|---|---|
| poolie | i'm going to try to fix some outstanding lp branches today | 01:48 |
| poolie | typing very slowly :) | 01:48 |
| poolie | hi vila ? | 06:28 |
| poolie | did you implicitly fix bug 307316, or is that a dupe of something you know about? | 06:28 |
| ubot5 | 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:28 |
| vila | poolie: almost there (~20min), I wasn't subscribed to this one, probably fixed, will check | 06:52 |
| vila | hi all ! | 07:23 |
| fullermd | Oh, it must be time for me to leave... | 07:24 |
| === stewart_ is now known as stewart | ||
| 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 |
| ubot5 | 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 |
| 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:38 |
| vila | bah, I wanted to type tyop.... if I can't even make typos on demand now... | 07:39 |
| spiv | «C'est ne pas une comment» ;) | 07:40 |
| vila | hehe, un commentaire :) Literally 'comment' in French means 'how' :) | 07:41 |
| spiv | vila: merci :) | 07:41 |
| vila | de rien :) | 07:42 |
| peitschie | vila: I was scratchin my head for a little there lol :) | 07:46 |
| poolie | vila, hi | 07:56 |
| === stewart_ is now known as stewart | ||
| mkanat | It seems to me like loggerhead has a lot of stuff that really ought to be in bzrlib. | 10:35 |
| mkanat | poolie: I think that at some point, a worthwhile project would be to de-duplicate loggerhead and bzrlib code. | 10:36 |
| 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:37 |
| mkanat | And making it thread-safe. | 10:38 |
| spiv | mkanat: +1 | 10:38 |
| mkanat | :-) | 10:38 |
| Peng | On horrible old repo formats, bzrlib probably isn't as fast or cachy. | 10:39 |
| 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:40 |
| mkanat | I'd love to eliminate as much as possible of the History object from loggerhead. | 10:41 |
| mkanat | Like, is it still slow to call repository.get_inventory(revid) over and over on the same revid? | 10:43 |
| mkanat | Hmm, I suppose it still is. | 10:46 |
| mkanat | And we're getting a whole inventory just to get a single file's id, or something. | 10:49 |
| 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:50 |
| Peng | haha, os.path! | 10:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| * mkanat looks at bzrlib.repository some more. | 10:55 | |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 | |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:25 |
| spiv | mkanat: bzr stores files as a sequence of bytes, and doesn't know what encoding they are in :( | 11:26 |
| 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:27 | |
| 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:28 | |
| 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:29 |
| mkanat | *has code | 11:30 |
| spiv | hrw: i.e. only the first two revisions are common, and the rest need to be merged. | 11:30 |
| spiv | hrw: it appears these two branches are what we call "parallel imports" | 11:32 |
| 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:33 |
| 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:34 |
| hrw | spiv: sweet dreams then | 11:35 |
| 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:36 |
| hrw | lovely | 11:37 |
| hrw | jelmer: thx a lot | 11:37 |
| hrw | All changes applied successfully. | 11:39 |
| hrw | uf. | 11:39 |
| 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:41 |
| 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:42 |
| hrw | jelmer: for my use of bzr it is enough | 11:43 |
| 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:45 |
| 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:46 |
| hrw | now it is time to recreate another branches ;( | 11:48 |
| 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:49 |
| Kamping_Kaiser | jelmer: ultimately i'm wondering if there is data loss transfering between bzr and git | 11:50 |
| jelmer | Kamping_Kaiser: git -> bzr is lossless, except where submodules are involved, the other way around is lossful. | 11:52 |
| Kamping_Kaiser | jelmer: ok. and the things that get lost are the bits you mentioned above? | 11:53 |
| jelmer | Kamping_Kaiser: yep | 11:54 |
| 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:56 |
| Kamping_Kaiser | right. | 11:58 |
| hrw | jelmer: bzr->git is lossful? what do you lose? | 11:58 |
| jelmer | hrw: see above | 11:58 |
| 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. :-) | 11:59 |
| jelmer | Kamping_Kaiser: ah, there's another one. directories are implicit too, so empty directories (or directories with empty directories) are lost. | 12:01 |
| 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:02 |
| hrw | jelmer: thanks a lot for "bzr git-apply" - you made my live (as git user) much much easier | 12:03 |
| hrw | now if there is a command to request merge review... | 12:04 |
| 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:05 |
| 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:06 |
| awilkins | Anyone have a hand in the Bazaar plugin for Hudson? | 12:18 |
| === seiflotfy_ is now known as seiflotfy | ||
| ambv | hey there | 13:54 |
| ambv | does anyone happen to be involved in configglue development? | 13:54 |
| hrw | have a nice rest of day | 13:55 |
| jelmer | ambv: no, what is configglue? | 13:56 |
| ambv | it's a Canonical project that blends ConfigParser with optparse, adding validation and a consistent API. | 13:57 |
| jelmer | ambv: perhaps ask in the ubuntu one channel, it seems to've come out of ubuntu one. | 13:58 |
| ambv | jelmer: believe it or not, there's #configglue | 13:59 |
| ambv | haha | 14:00 |
| ambv | thanks anyway :) | 14:00 |
| === 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 | ||
| poolie | hi all | 20:32 |
| === glyph_ is now known as glyph | ||
| jam | hi poolie, how's it going? | 21:11 |
| * jelmer waves to poolie, jam | 21:17 | |
| poolie | jam, hi | 21:18 |
| poolie | and jelmer | 21:18 |
| spiv | Good morning. | 21:28 |
| poolie | hi there spiv | 21:35 |
| 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:28 |
| poolie | chx, i don't think so, but it should be fairly easy to add | 22:37 |
| chx | poolie: what should i rtfm? | 22:37 |
| chx | maybe it can be even a shell script? something with return values. maybe. a pluginwould be better. | 22:38 |
| poolie | how about just a shell script or alias that does 'bzr update && bzr commit "$@"' | 22:41 |
| chx | hrm, probably. | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!