[00:16] * jelmer waves [00:24] jelmer: hi [00:25] jelmer: will the new bzr-hg improve memory behaviour at all for imports? [00:25] mwhudson: somewhat - fetching in batches will limit the memory usage somewhat [00:26] jelmer: ok, so it'll be worth retrying the python import, for example? [00:26] mwhudson, but we're still keeping the entire bundle we receive from the mercurial server in memory at the moment [00:26] ah [00:27] mwhudson, are there any particular ones for which memory usage is an issue at the moment? [00:27] jelmer: dunno, i just saw a bug report update go by [00:27] https://answers.launchpad.net/launchpad/+question/160305 [00:28] jelmer: you'll be surprised to learn that the OO.org import is reported as having issues [00:28] ah, openoffice [00:28] but also python [00:29] which is a bit less ridiculous i guess [00:30] I hope it'll be better with the rollout [00:53] jelmer, for bug 788219 is what apport has duped it to what you were thinking of? [00:53] Launchpad bug 788219 in bzr (Ubuntu) "bzr crashed with IOError in get_password() (dup-of: 534326)" [Undecided,New] https://launchpad.net/bugs/788219 [00:53] Launchpad bug 534326 in Bazaar GTK+ Frontends "bzr: ERROR: gnomekeyring.IOError:" [Medium,Fix released] https://launchpad.net/bugs/534326 [00:54] mgz, no, those are definitely different issues [00:54] because that's still a bzr-gtk bug and the guy doesn't have bzr-gtk installed [00:54] they're both caused by gnomekeyring, but one is when it's used through launchpadlib and one when it's used through bzr-gtk [00:55] they both have to handle IOError [00:55] mgz, unduped - thanks! [00:55] can you find the launchpadlib bug? I didn't find it when I tried. [01:04] I don't know what to do about bug 791839 [01:04] Launchpad bug 791839 in bzr (Ubuntu) "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte ..ordinal not in range " [Undecided,New] https://launchpad.net/bugs/791839 [01:04] as reported it's a dupe. [01:04] jelmer: i think i've hit that too [01:05] the ioerror [01:05] I don't see what's wrong with Fabien's statement that etckeeper should use git. [01:05] i'm also experiencing lplib corrupting the credentials it stores in the keyring, which is a separate unrelated bug [01:05] bzr plain doesn't work on nix without LANG set and obeyed. [01:06] probably it would be better to assume the filesystem is utf-8 if it's not set [01:07] well, there are a couple of cases here [01:07] - the filename is just not in any valid encoding, or it's inconsistent with other files in the same tree [01:07] he's got random junk cert names. [01:07] which is an inherently hard case for us [01:07] even without the traceback from bzr we won't commit the file. [01:07] the other [01:07] is that the encoding is not set or not set properly [01:08] which is pretty much what you say in https://bugs.launchpad.net/bzr/+bug/715547/comments/7 [01:08] Ubuntu bug 715547 in Bazaar ""bzr add" crashed ERROR: exceptions.UnicodeDecodeError" [Medium,Confirmed] [01:09] mgz: are you sure they're not utf-8? [01:09] if they came from an ubuntu package and they're not utf8, that sounds a bit like a bug in that package [01:09] they could be, but there's no reason to expect all programs writing to /etc to behave [01:10] and having your backup randomly fall over in that case is... a hard behaviour to argue for [01:10] so [01:10] wereas falling over fast is generally the right thing for a manually curated source tree [01:10] i think we should group/dupe the bugs into those two splits [01:11] plus any others for accidental cases where we know the right encoding but just do the wrong thing [01:11] what do you think? [01:12] seems reasonable. we've had various symptom bugs for these problems in the past than have been fixed, regressed, and so on [01:12] i think "assume utf-8" should be feasible to do and by my recollection of the bugs reported it will fix somewhere well over half of them [01:13] like it seems like it will fix this case [01:13] "i want to version names with just random byte strings" might be harder [01:13] hm [01:14] if people really want that they could set their fs encoding to say 8859-1, which will accept anything and send it to equally arbitrary utf-8 [01:14] that's true. [01:15] i wonder how hard it is to persuade python to use an fsenc other than what it originally detected? [01:19] do you want to reorganize them or shall i? [01:23] changing it would be somewhat dodgy, comes from a global variable set during initialise that lots of things depend on [01:23] we// [01:23] ^go ahead, I think we shouldn't have too many open bugs for the same thing, maybe just want a new one for changing the default [01:23] i think at least having a bug saying "we want this behaviour" [01:24] yup. [01:24] then we can see if it's too hacky to actually get it [01:24] as a matter of (fairly) objective fact, the right fs name encoding is utf-8 [01:24] our uses probably, or at least should, all go through osutils anyway? [01:26] either do, or can be made too [01:26] s//to [01:26] possibly we can get around it by always passing byte strings [01:27] in the very worst case we can reimplement some os interfaces === r0bby is now known as robbyoconnor [04:22] o/ spiv [05:44] Hey poolie [06:35] hi spiv === hunger_ is now known as hunger [07:36] spiv, still here? [07:36] i'm trying to fix the lp-propose lazr.restfulclient bug [07:37] for some reason python insists on loading the OS version of that library even though i have another one on my pythonpath... [07:40] oh, maybe because it imports lazr.somethingelse [07:41] Maybe the lazr.* packages have funky .pth files or something? [07:42] ! [07:42] :qa [07:43] heh [07:43] /usr/lib/python2.6/dist-packages/lazr.restfulclient-0.9.20-nspkg.pth [07:43] blah [07:43] import sys,types,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('lazr',)); ie = os.path.exists(os. path.join(p,'__init__.py')); m = not ie and sys.modules.setdefault('lazr',types.ModuleType('lazr')); mp = (m or []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p) [07:43] all on one line [07:44] Hrm. Should bzr really check URL's before filenames? [07:44] fullermd: well, URLs are a strict superset of filenames [07:45] Not when they fail :p [07:45] by which i mean, any filename can be represented as aurl but not vice versa [07:45] but, we can use sensible heuristics if it's bad [07:45] % bzr diff 2001:470:8:7f6 [07:45] bzr: ERROR: Unsupported protocol for url "2001:470:8:7f6" [07:45] right [07:45] ./2001... should fix it [07:46] morning all [07:46] Yeah, it's trivial to workaround. But annoying. [07:46] hey guys ! [07:46] Checking the other way around... well, I guess it would make your life really unpleasant if you had a file called 'lp:bzr' in your tree, but... [07:47] fullermd: i guess we could say "if there's no such scheme, assume it's a file" [07:47] that could work [07:47] File a bug? [07:47] spiv: yes i think that's it: so just having this module installed looks ilke it will always be loaded? [07:50] fullermd wants to break bazaar on alternative data streams in a new and interesting way? [07:50] nice systems don't let people put colons in filenames :) [07:50] Well, I've for sure never advocated breaking things in old and boring ways. I've got style, dangit. [07:50] :) [07:51] I store important data in files called '%s', just to be sure they're not used in format strings. [07:52] ehehe [07:54] wow that's a precious snowflake [07:54] i did not realize you could run arbitrary code from there [07:55] There are more things in heaven and on earth than are hacked apart in your philosophy ;) [07:55] poolie: Regarding lp:~mbp/bzr/220464-stale-locks , is there some pending points you want to address or can it be landed ? [07:56] > Lines starting with import (followed by space or tab) are executed. [07:56] vila, hi [07:56] i haven't fixed the pqm failure yet [07:56] poolie: ISTM this is already landable and the proposal is already > 900 lines [07:56] ha, ok [07:56] poolie, I've got one more change in my copy of the branch, I didn't remove the win32 test skip [07:57] what was the pqm failure? it didn't get pasted to the mp [07:57] poolie: yes, it's a great way to do cool/surprising things :/ [07:57] pth files are evil. [07:58] poolie: also, AIUI, this is now restricted to the same user so you may want to update the news entry [07:58] good point [07:59] okay, pushed, lp:~gz/bzr/220464-stale-locks [07:59] Presumably there's a convention for co-operating nicely with namespace packages like that for when you're developing your own version of a module in that namespace, but I'm not sure what it is. [07:59] hthanks [08:00] poolie: python2.6 ? Aren't you running natty ? [08:00] i am, but that was from a clean maverick chroot [08:00] to see if it's something strange on my main system [08:00] the same problem occurs there [08:01] ha ok [08:04] ok i'll leave this and finish 220464 [08:09] poolie: where do you think you're at with the stale lock thing [08:09] I feel like we've discussed it to exhaustion, without actually reaching consensus [08:11] jam: really ? Did you read the last version on the proposal on lp ? [08:11] vila: did you read the discussions between robert, martin and myself? [08:12] yes [08:12] apart from esoteric things about people using funny network share setups with computers all named the same thing the issues look resolved to me [08:12] if there are still controversial points on these cases then I think tests are better than discussion to break the ties [08:13] mgz: except it doesn't seem all that esoteric ime. Specifically if you install ubuntu from live install, it always calls the machine "ubuntu" [08:13] but would you really mount a filesystem on another such system remotely? [08:14] mgz: sftp:// [08:14] sftp://ubuntu ? [08:14] vila: sftp://bazaar.launchpad.net/my/project/branch [08:14] poolie's proposal breaks *remote* locks that look like they were held by the local machine [08:14] which has some nice bits [08:15] like "bzr push sftp://... ^C bzr push" will work [08:15] rather than warning you about the stale lock from the previous push [08:16] right, my point is that writing tests for that will make the actual and intended behaviors clearer [08:17] mgz: it has some problematic bits that if your machine is configured oddly, you can overwrite critical data. [08:17] I'm trying to weigh the balance in my head [08:17] since as poolie points out, breaking locks by hand can be just as risky [08:17] and since the proposal is already 945 lines long it should either be landed or split or all discussions become more complex and progress harder [08:18] AIUI the only case where we can override/lose data is for the repo lock [08:19] in this case, the .pack ..ix files should still exist and we can think about ways to recover them but this is out of scope for this proposal [08:20] also, this lock is short-lived to just pausing a bit may be enough to detect a stale lock, but I'd rather look at this kind of change in a smaller proposal [08:20] s/to just/so just/ [08:20] vila: we lose data from .conf overrwrites and a branch lock [08:20] we lose master bound branch integrity from branch locks [08:20] we lose a few other things. [08:20] nothing I would say is "super critical", but it *is* data loss [08:21] (my bound branch commit can succeed, and in the end master doesn't point at my revision.) [08:21] vila: so the *critical* case is repo locking, but there are minor cases elsewhere [08:22] then back to tests, if these scenarios are worrying enough, they should be covered no ? [08:22] I'm pretty sure I'm falling on, "this is a net gain so we should land it", but I don't feel it is cut-and-dry [08:22] vila: we can add tests for concurrency issues. However, we have to decide if we care if they fail [08:22] vila: the current proposal will fail under esoteric conditions [08:22] is that ok? [08:23] I certainly can write a test that proves it. [08:23] But does that actually help us. [08:23] Yes it does, it means a better ground for addressing it [08:23] It kills the FUD :) [08:23] vila: except the discussion is tending towards "that failure mode is ok" [08:24] which means, we don't actually need the test [08:24] and actually, we don't *want* the test, because it would fail [08:24] vila: we know from the code and its behavior how it can fail. we are asking "is a this rare enough event that we don't need to worry about it" [08:24] no FUD [08:24] just an open question [08:25] we don't have to always be perfect, and we have to determine the tradeoffs [08:26] I'm not saying you're propagating FUD, I'm saying you're a FUD victim here. To rescue you we should address your fear :) [08:26] or doubts [08:27] vila: I can't test how often in-the-wild the esoteric conditions are met [08:27] which is the fear [08:27] I don't care about the test [08:27] I need to know real-world-how-likely-is-this-to-fail [08:27] I'm thinking it is low enough to go ahead. [08:27] I *know* it fails in a particular way, I *don't* know how likely that way is. [08:28] We've had other cases where we made the tradeoff [08:28] and people got bit by it. [08:28] Like the "inventories during repack" [08:28] I knew it was broken, but that "bzr pack" fixed it. [08:28] People have hit it, and we decided that wasn't enough, so we spent more time to work on it. [08:29] But isn't adding the user in the check enough to reduce the esoterism here ? [08:29] vila: maybe, but the most likely cases for actually running into this is probably stuff like cron scripts [08:30] I'm unlikely to race with myself [08:30] we ran into a lot of bugs from the twisted guys, where they had multiple bots pulling into the same repository. [08:31] hi jam [08:31] hi poolie [08:34] poolie: so I think what I'm leaning towards is: land it, but file a couple bugs about known failure cases. [08:34] To give us points to track if it happens in the wild. [08:34] And especially a way to document known workarounds, etc. [08:38] i think so too [08:38] mm, except i'm against filing vague bugs [08:39] but if we say "will hit trouble if you have two machines with the same hostname" [08:44] you guys ready for a call in a `5m? [08:44] 15* [08:48] jamesh: poolie: FWIW, I would lean towards being conservative; our user base is large enough now that 'minor risk' tends towards 'will happen', I think. [08:48] s/jamesh/jam/ [08:48] mm [08:48] but, I say this from the peanut gallery; the call is yours. [08:49] perhaps we should downgrade it to just warning, and leave it up to the user to decide if they think it's probabyl dead? [08:49] this may be a cop out [08:49] if they get it wrong anyhow [08:50] thats what vim does, and it has a somewhat simpler problem to solve I tihnk [08:50] why simpler? [08:52] no smart server [08:52] just filesystem [08:53] perhaps its equivalent [08:53] I wasn't claiming radically simpler problem [08:53] lifeless: well, their lock is also a WAL, which allows them to "incorporate changes" which we don't provide [08:56] jelmer: time to reboot :) [08:58] WAL? [08:58] write ahead log? [09:00] right [09:00] I don't know that it is strictly that [09:00] but you can say "apply changes from the .swp file" [09:00] before you delete it [09:02] really, "apply", not just loading the whole thing? [09:06] poolie: I don't know the specifics. But I think the idea is that if the text file is really big, Vim doesn't write out the changes to the file all the time. But keeps a small "these are the edits" in the .swp file. I just know that one of the options on load is "delete" and another is "recover" [09:08] spiv, hi? [09:08] i think 'recover' is just 'load it' not 'merge the changes' [09:08] imbw [09:53] Riddell: bug 746822 [09:53] Launchpad bug 746822 in Launchpad itself "fails to build recipe with "bzr: out of memory"" [High,Triaged] https://launchpad.net/bugs/746822 [09:58] anyone know what this might mean, when trying to bzr merge-package: [09:58] NoSuchRevision: CHKInventoryRepository('file:///home/apw/local/bzr/tmpFFe1XH/upstream/.bzr/repository/') has no revision ('james.westby@ubuntu.com-20100820023033-dousm0xjfuraxtd7',) [10:01] apw: merge-package apparently can't find a particular revision but it has a reference to it [10:03] apw: it sounds like it might be a bug in bzr-builddeb or a broken repository [10:03] jelmer, i can bzr checkout the url ok, just not merge it [10:03] apw: does regular merge work? [10:04] Riddell: bug 746822 seems to be the same issue as the recipe build running out of memory you mentioned [10:04] Launchpad bug 746822 in Launchpad itself "fails to build recipe with "bzr: out of memory"" [High,Triaged] https://launchpad.net/bugs/746822 [10:04] jelmer: yep, not much extra information on it though [10:04] jelmer, yet it would be mergable directly [10:10] vila: does 2.3.3 really address just a single bug (failUnless & co cause PendingDeprecationWarning) ? [10:11] if so, that does not seem worth SRUing [10:12] it's true natty has 2.7 and people might run the tests there, but, it's not crucial [10:12] fwiw: 2.3.2 hasn't been SRU yet either and has more bugs (12) [10:12] though I'm surprised that we did a release just for the deprecation warning thing [10:12] ah, that makes more sense [10:13] i think it just squeaked in between 2.3.2 being tagged, and being discarded [10:13] it was cancelled during the release process for some reason that i forget at the moment [10:13] ah, 2.3.2 was *that* release [10:13] poolie: thanks [10:13] wasn't it? [10:13] ah the release page says [10:14] > This release broke the test suite under python-2.7 and the corresponding tarball has never been released. [10:14] yup [10:14] so my fix makes it releasable [10:14] yup and allowed the test suite to run which is part of the SRU AIUI [10:14] well, at least for recent series [10:15] mm [10:15] but would it run against 2.7 on natty? [10:15] yes, it would, since 2.7 is the default [10:15] well that's all good then [10:16] right, 2.3.2 was worth a SRU but couldn't released so I cut 2.3.3 since fixing the tag issue was not practical [10:16] s/released/be released/ [10:23] ok [10:24] so the figurehead should be something from 2.3.2 probably [10:24] 2.3.2 nominally doesn't exist, right? [10:25] right, see above [10:25] and good morning [11:13] poolie: what was the ecryptfs bug? [11:26] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793367 [11:26] Ubuntu bug 793367 in linux (Ubuntu) "ecryptfs corruption during make -j" [Undecided,Fix committed] [11:30] i sent a mail [11:30] ok that's enough for now [11:31] poolie: thanks [11:37] hi [11:37] I'm trying to help with this bug [11:37] https://bugs.launchpad.net/bzr/+bug/680529 [11:37] Ubuntu bug 680529 in Bazaar ""Lock was renamed into place, but now is missing"" [High,Confirmed] [11:37] can someone instruct me where to put sleep? [11:42] hi fritz[] [11:42] hi [11:43] jelmer: that's great, thanks [11:46] fritz[]: basically in lockdir.py, just look for the 'lock was renamed into place' mesasge [11:46] put that in a 'for i in range(5):', try the check, and if it fails, sleep(3) [11:47] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/bzrlib/lockdir.py [11:47] from line [11:47] 251 [11:47] to [11:47] 262 [11:47] put that in for loop? [11:48] i would say only up to line 255 [11:48] then, if it doesn't find it [11:49] obviously you don't want to raise straight away, but only if the data is not found on any attempt [11:49] thanks very much for taclking this! [11:49] it seems to bite many people but it's hard to reproduce- [11:49] sure, no problem [11:49] I'll just take maseratti :) [11:54] jelmer: so with bzr.dev "time bzr branch --stacked -Dmemory ...kde-workspace" only peaks at 150MB [11:54] and takes 2.4min here [11:55] that is http:// explicitly [11:55] jam: which bzr version is that? [11:56] bzr.dev [11:56] I'm checking an older version next [11:56] do you know what is on the builders? [11:56] I think the builders are running 2.2-something [11:56] let me check [12:05] jelmer: using bzr-2.2.2, I get 2m32s, and 188MB peak memory for the same kde-workspace [12:06] not all that different [12:07] note, those numbers might ~double if they are using 64-bit systems [12:07] though why you would run a 64-bit system with only 1GB of ram seems a bit silly. [12:07] jam: virtual process size limit is set to 1 000 000 000 bytes [12:08] given that 64-bit programs are almost universally much bigger in mem because of the extra pointer sizes [12:08] I'm not sure why it uses RLIMIT_AS rather than something else === mrevell is now known as mrevell-lunch [13:41] spiv: with bzrr-2.2.2, 'bzr branch --stacked lp:.../kde-workspace' took 220MB peak, and 5m4s. While http:// took 188MB and 2m30s. [13:41] so bzr+ssh vfs seems a bit weak [13:46] jam: yes, probably because there's double-caching [13:47] jam: e.g. RemoteRepository will keep a get_parent_map cache, then when it falls back to VFS the "real" repository object will probably fetch and cache most of the same info [13:47] (But in a different form, of course) [13:47] I think the primary fix there is "don't use VFS" [13:47] spiv: branch --stacked, so I think most of the 'build-the-working-tree' stuff doesn't use get_parent_map [13:48] I'd be a little interested in if lp:~spiv/bzr/faster-stacked-tree-build goes better (needs to be run on both server and client) [13:49] (It doesn't totally eradicate VFS calls, but it does reduce them) [13:49] spiv: hard to run that on LP :) [13:50] jam: local testing is faster anyway, right? ;) [13:52] spiv: sure, but doesn't compare. Anyway, I do have a -Dhttp -Dhpss log of both, I might grep through it [13:52] in theory, the same calls should be made [13:55] spiv: it is also possible that my machine was more heavily loaded during one of the runs [13:57] spiv: we also read ".bzr/branch-format" 5 times in the http:// version (and branch/format 6 times)... ugh [13:58] jam: I was thinking specifically that you could measure the client's memory consumption with that branch [13:58] jam: I already know it is *much* faster [14:14] Hi spiv, do you have a thought on when bug 793393 might be addressed? [14:14] Launchpad bug 793393 in Ubuntu Distributed Development "Please upgrade jubany's bzr-builddeb" [Undecided,New] https://launchpad.net/bugs/793393 [14:16] spiv: copying the branch locally, 'time bzr branch --stacked bzr://localhost/..." is then 181MB and 1m38s. "time bzr-spive branch --stacked" is 1m26s and 134MB peak memory. [14:18] maxb: oh right. I'll do it first thing tomorrow morning my time unless you convince someone else to do it first :) [14:19] thanks :-) [14:19] jam: hmm, less of a time win on this branch than another test case I have, but not too shabby. (Especially as it has to pay the costs to insert the data into the repo and so validate it where stock bzr doesn't) [14:19] Once that's done, and assuming the importer branch itself is up to date, sysvinit can be requeued, and I hope should work [14:20] jam: And the memory improvement is good news :) [14:20] jam: thanks! [14:34] spiv: this is also over the loopback, so bandwidth type stuff doesn't really matter. [14:35] and you seem to be fairly out of date vs bzr.dve [14:35] you don't have my groupcompress changes, for example [14:35] spiv: And I should note: "transferred" changed from 95MB to 32MB [14:35] so for anything network bound (like most things) this is a massive improvement [14:41] It was mainly roundtrips I wanted to improve, happily that approach seems to help lots of other things too. [14:46] poolie: you still there? [14:48] fritz[]: unlikely at this hour [14:49] sorry, can anyone else help? I'm doing research for one bzr issue and I've modified lockdir.py source [14:49] now trying to recompile my bzr [14:49] (on windows) [14:49] i've done [14:49] python setup.py install --home ~ [14:49] without problems [14:49] but where's my bzr.exe? :) [14:50] I've got \bin directory with bzr and bzr.bat [14:50] :( [14:54] fritz[]: building the windows installer for bzr is a pretty fiddly job [14:54] so I see :( [14:55] fritz[]: as jam could tell you [14:55] fritz[]: but you can run bzr from source, I suspect that's adequate to diagnose your issue [14:55] fritz[]: I would recommend running from source, and just using "py setup.py build_ext -i [14:55] which builds "in-place" [14:55] ok, trying exactly that now .. [14:55] sec [14:56] the .exe is much more complex to build. From what you wrote, you can probably run it from the 'bzr.bat' [14:56] which runs the 'bzr' script using your installed python [14:57] ok, I've done python setup.py build_ext -i without error [14:57] (It *may* be possible to twiddle the library.zip or something of the bzr installed by the official installer, but that will be pretty fiddly and I don't know the exact details) [14:58] ok, so I should use build\scripts-2.7\bzr now? [14:59] grr [14:59] ImportError no module named site [15:03] ignore :) [15:03] got it [16:36] jelmer: hiya, around? === deryck_ is now known as deryck [17:07] workthrick, hi [17:08] jelmer: looking into writing the mapping now [17:14] Hi all, I was looking at this wishlist request: https://bugs.launchpad.net/bzr/+bug/681792 and was curious if something like this has been implemented yet? [17:14] Ubuntu bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [Wishlist,Confirmed] [17:15] jblue, as far as I know nobody has looked into that yet [17:15] what would be be the best practise then, to use --overwrite to sync the tags? [17:18] jblue, there isn't really an easy way at the moment [17:18] jblue, a workaround would be to remember the current revision tip ("bzr log --show-ids --limit 1"), then "bzr pull --overwrite" and then restore the tip [17:18] ("bzr pull -rrevid: .") [17:22] jelmer: in essense, overwriting tags, but not pulling in new revisions [17:22] jblue, that's what the workaround would do [17:22] sounds fair, thanks jelmer [17:22] jblue, sorry there isn't an easier way (yet) [17:25] jelmer: do you see any obvious problems (besides performance impact, of course, but we know it's there already) by mapping revisions with multiple parents to id concatenating all of the parent IDs in the lexicographical order? [17:25] hmm [17:26] jelmer: that would result in files changing their IDs on the merge revision, wouldn't it? [17:27] jelmer: also I see BzrGitMappingExperimental there, doesn't it do what I want already? [17:28] workthrick, mapping in way? Using their lexicographically sorted parent ids to generate their id? [17:28] yes [17:28] what if two revisions (with different contents) in the same repository have the same parents? [17:29]