[00:04] hello [00:13] jam: i'm not sure i understand [00:24] mwhudson: this is for stacking? [00:29] lifeless: yeah [00:34] i guess i could only change BranchFormat7.open [00:35] and do most of what bzrdir.open_branch does myself === arjenAU2 is now known as arjenAU [00:52] lifeless: i replied to your mail [01:05] mwhudson: a hook to alter is less disruptive than a signature change which will propogate many levels deep [01:06] indeed [01:07] but conceptually [01:07] if you change open I'd rather see a 'transform_fallback' parameter rather than disable/enable [01:07] with the transform being required to return a url when given a url [01:08] fair enough [01:08] changing open appears to be a can of worms though [01:08] so i'm going to give a hook a go [01:09] lifeless: what do you think the hook should do? [01:09] that is, you can't disable stacking, but you can change the pointer [01:09] take a url, give a url, or take a url, give a repository, or ... ? [01:11] you need something that takes a url beca use you want to get there before url connection is attempted [01:11] indeed [01:11] I think its easier to allow url->url [01:11] because then these transforms can stack [01:11] point [01:17] lifeless: something roughly like this? http://pastebin.ubuntu.com/55463/ [01:18] mwhudson: so will it be acceptable to you that if you can't open the stacked-on branch at all, then you can't deal with the stacked branch at all? [01:19] poolie: yes, i think so [01:19] (i mean, i _guess_ you could just return the url of an empty branch backed on to a memorytransport as from the hook if you really wanted to be evil) [01:19] so i think that means launchpad can't do anything with branches that are stacked on locations not on launchpad? [01:20] i don't think that'd be a good idea [01:20] if launchpad can't open the branch, what can you do? [01:21] poolie: if people do 'bzr push lp:whatever --stacked-on http://somerandomhost.com/trunk i think it's ok *for now* for this to not work [01:21] ok [01:21] * jml agrees with mwh [01:22] i think that's fine, and it's good to be clear about ti [01:22] it8 [01:22] it** [01:22] mwhudson: s/should/must/ [01:22] lifeless: right [01:22] also please check None is not returned or something like that [01:23] lifeless: makes sense [01:23] mwhudson: re that hook, it seems like you should perhaps pass the stacked branch url too [01:23] poolie: yes, probably [01:23] poolie: or the stacked branch itself, maybe [01:23] mwhudson: there's also external documentation of hooks that should be updated [01:24] maybe, probably, though it deserves a warning that it's half-baked [01:24] certainly [01:47] curious... anyone looked at long term memory usage of bzr/api consumers? [01:47] noticed an annoying trend of loggerhead/trac-bzr both developing heavy leaks, wondering if others have seen it for alternative apps [01:51] ferringb: I suspect those are the only long-running consumers that we have. [01:51] Though I don't know how the Eclipse plugin does it, and there is 'bzr shell' in bzrtools. [01:53] ferringb: its likely python memory fragmentation, though it could be a genuine leak [01:54] ferringb: I suspect bzr itself isn't leaking, based on previous tests [02:03] lifeless: I doubt it's memory fragmentation [02:03] actually I know it's not [02:04] have at least one reproducible ~18/20MB leak [02:04] if it were fragmentation, it would level off at some point (very least the growth wouldn't stay linear) [02:04] ferringb: ok [02:04] either way, setting up to heappy it, just wondering if anyone else has seen odd behaviour [02:05] loggerhead on launchpad has trouble from time to time [02:05] much better since the big overhaul [02:05] yeah, upgraded recently, been happy w/ the results for the most part [02:05] lifeless: curious, launchpad allow the misc cralwers to scrape loggerhead pages? [02:07] I think its blocked [02:07] back soon, doofing [02:07] There's the utf8 cache in bzrlib.cache_utf8 that bzrlib.osutils.safe_revision_id uses, if an unbounded number of revision IDs get seen by the process that would grow without bound... [02:09] spiv: rough size of utf8 cache entries? [02:12] # of revisions * (length of an average revision id + 40 bytes) [02:12] (where 40 bytes is a guesstimate of the size of the overhead of a PyString object plus keeping a dict entry or two) [02:13] Hmm, maybe length of a revision id * 2, because I guess the cache keeps the unicode and the str version. [02:13] Basically, 20MB would be a pretty huge number of entries in that cache! [02:18] lifeless, poolie: i just sent a bundle to the list [02:19] with an inappropriate subject, wahoo [02:20] * mwhudson resends [02:21] spiv: by my math with your numbers, it only takes 67K revisions to hit 20MB [02:23] jam: Well, that's not so impossible. But if one process is repeatedly leaking 20MB at a time, that still adds up pretty quickly to an unusually huge number of revisions. [02:23] paths too [02:25] poolie: ? [02:27] jam: your abbreviations are unclear to me [02:27] jam: I didn't reply to your first mail about readahead in btree indices because I read your mail as saying you weren't done [02:27] I'm not, I was asking for comments, though [02:28] markh: hi [02:28] jam: "seems worth investigating" [02:28] jam: though, please consider with gc repositories [02:28] poolie: hi. Can you think of an example of some "doctest-ish mappings" I could use as a kindof "template"? [02:28] jam: which for text reconstruction, have a radically different read pattern [02:28] last I tried gc, performance was pretty abysmal [02:29] at least for the 'fetch' case [02:29] jam: yes, and we know why :P [02:29] and it would have the same structure for "log" [02:29] since those aren't compressed anyway [02:29] yes [02:29] I'm not sure what they would look like exactly. I would have thought normal unittests that use the api would be easier? [02:30] (but I've never quite drank the doctest kool-aid :) [02:30] doctest-- [02:31] "doctest == testable documentation" in my book, and its not clear that is what we are doing [02:31] but - I'm not trying to argue the merits of that, but if doctests are desired a template would help alot. [02:31] markh: whats the context here btw? [02:32] case sensitivity [02:32] blackbox tests? [02:32] that's what I would have thought. Poolie suggested " Maybe a good place to begin would be with a kind of doctest-ish description of what mappings are meant to occur and where." [02:33] markh: I would translate that as write some docs about the problem [02:33] write some docs that have quoted fragments of code [02:33] markh: but yeah, I think chat to poolie at this point [02:34] i don't mean that they should necessarily be executable, because doctest other than as testable documentation has some drawbacks [02:34] did you read alexander's wiki page? [02:35] maybe "black-box doctests"? ie, quote shell commands using bzr rather than code? [02:35] I read the wiki page after sending my initial mail. Its fairly good but a little light on specifics. [02:35] It also fails to address that windows isn't truly case-insentitive generally - its closer to "case retaining" [02:36] case preserving case insensitive is the usual description [02:36] ie, the case of the filename is retained, but any case can be used to access it. [02:36] right - and the wiki doesn't make that distinction. [02:36] so i made that (perhaps too vague) suggestion because i think we need to converge from the somewhat general document on the one hand with actual code on the other [02:36] eg, FAT truly is case-insensitive IIUC [02:37] but i don't know if people genuinely agree where those tests should go [02:37] markh: VFAT isn't, and real FAT can store arbitrary bytes, its up the fs layer on top :P [02:37] lifeless: OK - the FAT FS layer on windows is truly case insensitive IIUC :) [02:37] VFAT is awesomely the worst of both worlds. You can have both File1 and file1 in the same directory, but windows will only see one. :) [02:38] markh: I'm pretty sure that if you put a FAT fs into current windows, it treats it as VFAT just for kicks [02:38] poolie: so a reasonable first step would be docs that demonstrate the problem and identify the preferred solution, but doesn't actually identify code that might need changing? [02:39] those docs could then be turned into regular black-box tests and then the impl can be determined? [02:40] right [02:41] ok cool, thanks. [02:41] i think they could possibly actually be run as doctests [02:41] treating them as "this is a testable document of how we're generally handling case sensitivity" [02:41] I'd be strongly tempted to just write blackbox tests for specific commands [02:42] maybe, but I fear the doctests then get pollued with 'open('foo').close() etc to actually setup the test trees etc, but I haven't looked any many of the existing doctests yet. [02:42] doctests are viciously harsh to work with when you need filesystem support [02:42] you can spend days just getting things to work right [02:42] yeah [02:42] right [02:43] by strongly tempted, I actually mean, you couldn't pay me to write this sort of thing as a doctest [02:43] so, to be clear, i'm suggesting a document that has some code or command examples, even if they're not actually executable [02:43] a pseudocode doctest [02:43] don't worry, you couldn't pay me enough to have me try to make you do it :) [02:43] :P [02:46] hmm, 1.8.1 removes MutableTree.get_file_with_stat() ? [02:46] s/1.8.1/1.8rc1/ [02:47] jelmer, really, i thought it was added? [02:48] I must be too tired to read the traceback right [02:48] yeah, never mind me [02:48] jelmer: thats new, part of commit race closing [02:48] bzr-rebase doesn't provide MapTree.get_file_with_stat() yet [02:49] thats more likely :) [02:49] spiv: seen https://bugs.edge.launchpad.net/bzr/+bug/278673 ? [02:49] Launchpad bug 278673 in launchpad-bazaar "Traceback when uploading to an invalid location" [Undecided,Triaged] [02:50] I'll fix it tomorrow when I'm actually awake... [02:50] spiv: i have the feeling it might be fixed in bzr.dev by now [02:50] g'night [02:52] mwhudson: Actually, I suspect it isn't [02:53] spiv: slacker [02:53] :) [02:53] Nope, I don't think it is. [03:16] spiv: not a process as much as a request via trac-bzr [03:16] spiv: reasonably sure trac-bzr in general has it's own issues, but either way tracing it (finally got my hijacker working again) [03:37] I'm doing a merge and getting a contents conflict on a file [03:37] thing is, the file doesn't exist in the branch being merged into. [03:38] what's the deal?\ [03:38] jml: it used to exist [03:39] jml: left side change -> delete [03:39] jml: right side change -> modify [03:39] lifeless: thanks. [03:39] lifeless: can we turn you into a "bzr explain-conflict" plugin? :) [03:40] spiv: no [03:40] spiv: but you can patch the conflict system to explain itself more [03:42] lifeless: if I try to get the log for the path, I get: bzr: ERROR: Path does not have any revision history [03:44] lifeless: AIUI, this conflicts with your theory. [03:47] * spiv -> lunch [03:48] * jml is perplexed [04:07] jml: deep history is not checked [04:08] jml: try ls -r ancestor:other-branch [04:09] lifeless: it's in the list. [04:09] lifeless: but that doesn't help me learn why it was deleted. [04:10] log -v might [04:10] or log -m '\bbasename\b' === jamesh_ is now known as jamesh [04:12] lifeless: by 'basename', you mean os.path.basename(), right? [04:12] no results. [04:16] shame, they didn't mention the file while commiting its delete [04:18] jml: log -v is probably the key [04:19] jml: one possible thing is 'rm foo; add foo; commit; [04:19] lifeless: log -v doesn't give any results either. [04:19] jml: the file is in the branch? [04:20] lifeless: no. [04:20] jml: is it in trunk ? [04:20] lifeless: yes. [04:20] lifeless: merging trunk into the branch raises the conflict. [04:20] and log -v in the branch doesn't show it being deleted anywhere ? [04:21] lifeless: that's right. 'bzr log -v path/to/file' says bzr: ERROR: Path does not have any revision history [04:21] that command is useless for this [04:21] I mean literally 'log -v' [04:21] log PATH needs PATH to be in the WT, or *the last commit* only. [04:21] 2-commits back and the path won't be found [04:24] can i get someone to look at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48ED5C67.9020408%40canonical.com%3E please? [04:24] lifeless: ok, so log -v and grep? [04:24] jml: yes [04:24] * jml tries [04:24] jml: btw I would have said 'log FILE' if that was what I meant :) [04:25] mwhudson: i'll look [04:25] poolie: thanks [04:26] i set up an rdesktop-accessible windows vm for testing and packgaing [04:26] mwhudson: +1 [04:27] poolie: thanks [04:28] lifeless: is there some way I can do this without generating the log for the entire history of this branch? [04:28] jml: -r -1..ancestor:otherbranch [04:28] jml: but it will take just as long [04:28] jml: so don't interrupt what you are doing [04:30] lifeless: ok. [04:31] jml: (log incrementally generates output, so the time-to-find-first-reference is identical) [04:31] lifeless: incidentally, I think Bazaar could handle this use case better. [04:31] indeed [04:31] I'd like bzr search to index changes better [04:31] and the inventory work I'm doing at the moment should help too [04:32] lifeless: would that make 'bzr log removed_file' do something? [04:32] jml: no more than it does today [04:32] :( [04:32] jml: searching all the way to the dawn of time is what it doesn't do today [04:33] jml: and its hard to justify that it should do that by default, because that will always be somewhat expensive [04:33] jml: however, a search index could do it fast [04:33] lifeless: I'd settle for 'bzr log --deleted FILE' or similar [04:33] and if the search tech advances sufficiently we can make it be part of core [04:34] or something that gave me the revno of when it was deleted. [04:37] learning why a file was deleted seems to be a good thing for a version control to help you do. [04:41] sure === abadger19991 is now known as abadger1999 [05:40] abentley: shelf 2 sounds very cool [05:40] spiv: Thanks. [05:41] abentley: hi [05:42] jam: thanks for the ppa packaging updates and documentation! [05:42] lifeless: Hi. [05:42] abentley: got time to chat about your new tree method? [05:42] i have some queries but i guess you may be gone [05:42] lifeless: A bit. Gotta be up early for a chat with sabdfl. [05:43] abentley: ok. well basically I feel like its making things vis-a-vis inventory less clear, without actually reducing inventory usage; I'd rather see things just using inventory directly than via that method. But - I have context for what drove it etc, and I'd like to understand those reasons. [05:44] s/have context/have no context/ [05:44] lifeless: We haven't officially deprecated inventory, but I hope we'll be able to. [05:45] lifeless: PreviewTree doesn't have one, because I thought it would be a good way to push that process along. [05:46] lifeless: It's somewhat a cheat to get the InventoryEntry without having an Inventory. [05:46] abentley: right, thats why I think its less clear, without being better in any other way [05:47] lifeless: It's better in that I don't have to implement PreviewTree.inventory [05:47] lifeless: We talked about this on the list in just the past week. [05:47] lifeless: jam was especially in favour of it. [05:48] ok [05:48] do you remember the thread name? I should read it and reply I guess [05:48] shelf2 sounds nice [05:48] and I do want you to get this patch in [05:48] also [05:48] woo [05:48] all tests passsing on my split inv format [05:49] lifeless: great stuff. [05:49] lifeless: Thread was: [MERGE] Enable merging into PreviewTree [05:50] lifeless: The other way I can avoid implementing PreviewTree.inventory is to use Tree.iter_entries_by_dir to get single entries. [05:50] lifeless: Would you prefer that? poolie's distaste with that pattern inspired this patch. [05:52] let me read that thread; at this point I would say implementing a trivial inventory subclass (you only need to override __getitem__ and __iter__ probably) is likely clearer and not much more code [05:55] lifeless: Okay, catch you later. [05:56] abentley: I'll reply to the older thread [06:39] poolie: want a chat? [06:39] lifeless: yes, but this time i'm really playing squash at 5 [06:39] :P [06:40] sure whenever then [06:40] markh: if you're still here, are there any docs on building windows installers/packages? [06:40] grab me tomorrow morning if you like [06:40] now's fine, at least briefly [06:40] poolie: in general its usually "setup.py install" [06:40] that's all? [06:40] poolie: ok ringing asap [06:41] that's the theory :) You will need the appropriate MS compiler installed, but you don't even need to make sure its in your environment [06:44] poolie: some packages have extra requirements - eg, bzr-svn needs the apache runtime libs installed somewhere and env vars set to point at it - but setup.py documents that [06:45] (not to mention the svn libs themselves :) [06:50] So, I have a basic question. And I can't find the answer around the interwebs. What's the difference between init and init-repo. What's their interaction when both of them are used? [06:51] Wyverny: try 'bzr help repositories' [06:51] I have that open. [06:51] "By default just running 'bzr init' will create a repository within the new branch but it is possible to create a shared repository which allows multiple branches to share their information in the same location. When a new branch is created it will first look to see if there is a containing shared repository it can use." [06:52] "To create a shared repository use the init-repository command" [06:53] so usually you would create a shared repo in /src/myproject, then use 'bzr init' to create branches *under* /src/myproject [06:53] all the branches would then share the same repo [06:54] I see. I get it. Thanks. I knew it was something simple. [06:59] Can there be only a single .bzrignore? Or can I have one per branch? [06:59] it is only per-branch [06:59] (as a file in the root of each branch) [07:00] Oh, great. [07:02] Simple questions, simple answers. I'd buy you guys a beer if you were around ;) [07:04] in an hour I'll have one for you anyway ;) [07:05] hi all [07:57] hey, I want to setup my own system so that I can have multiple devvies access a bzr repo for push, but want to secure it... [07:57] I don't want to have to setup SSH account for them, and dont want anything that encroaches my security on my system... [07:57] any ideas? (I'm looking for something similar to how svn does users over HTTP preferably) [07:58] Mez: afaik, ssh or ftp are your only options. [07:59] which means setting up new user accounts :9 [07:59] Mez: you can restrict it so that the devs don't get shells on your computer [08:00] jml, I know that... but I don't want to have more UNIX accounts that I have to manage and secure [08:00] Mez: *nod* [08:01] Mez: although, as a non-sysadmin I'm curious, why do you think that UNIX accounts are more difficult to manage than htpasswd and authz files? [08:01] because they're covered in my audits ;) [08:02] Mez: ah hah. [08:02] ciao [08:03] lifeless: cya [08:03] Mez: so, if this is an open source project, you can host the branches on Launchpad for free. [08:03] Mez: but I am filing a bug *right now* about this :) [08:03] jml, yeah, it is, but I don't want to push it out to public till it's code-ready at the moment [08:04] jml, feel free to subscribe my nick to tbe bug [08:05] Mez: done. [08:06] Mez: incidentally, are you aware of Launchpad's +junk feature? I often push branches to ~jml/+junk/whatever when I don't feel they are ready for public consumption. [08:07] (I understand there are different levels of "not read") [08:07] ready, rather. [08:09] Mez: FWIW, there are SSH/SFTP servers that don't use UNIX accounts. They're not necessarily easy to setup, though... [08:10] spiv, exactly [08:12] spiv, names? [08:13] Mez: Some assembly required (i.e. hacking), but you can build such things with Twisted Conch. You could probably do it with paramiko too. [08:13] I wouldn't be surprised if there are others, although I've never looked. [08:14] (I know it's possible with Twisted, because I've done so... that code is now part of what runs bazaar.launchpad.net) [08:17] spiv, i'm not really that good with python [08:18] Mez: "just use +junk branches on Launchpad" is a pretty good answer for branches of experimental open source projects, though. [08:18] I guess I understated when I said "not necessarily easy to setup" :) [08:18] spiv, release a user friendly version of the code for bazaar.launchpad.net ;) [08:19] Mez: working on it. [08:19] jml, ? [08:20] Mez: Launchpad is scheduled to be open sourced in the next year. [08:20] yeah, yeah, I know [08:21] (spiv originally wrote bazaar.launchpad.net, but I've been maintaining it for the last couple of years) [08:22] anyway, it's time for me to leave the computer and enjoy the sunlight. [08:23] jml: good plan [08:24] Hooray, I have usertest reliably running multiple runs of its 'network' suite, including starting & stopping a bzr server. (And as a bonus, using --strict.) [08:25] * spiv runs it with a simulated 500ms latency loopback network device on bzr.dev and 1.7.1 [08:37] spiv, could coh not be used to have br serve work as an ssh server which has a file in the branch that lists the people with access's h keys (like an authorized keys) [09:01] For today's controversial and incorrect suggestion: Dropping support for Python 2.5 :D [09:05] hello [09:05] hey spiv, well done! [09:05] Mez: that would be nice [09:06] not so hard to do, as we already have an ssh server used in testing [09:07] poolie, Id write it if I knew how [09:08] if you'd like to try we can help you [09:08] haha, I can probably get it to the point where it makes a server, and authenticates, but getting it to interact with bzr is the hard part [09:09] so StubSSHServer in tests/blackbox/test_serve.py is probably close to what we need... [09:10] argh [09:10] Im not even going to TRY and do a branch on here [09:11] * Mez wonders if the eeePC would be able to cope and decides to do a lightweight CO instead [09:16] poolie, actually, yeah, it could probably work from that [09:19] poolie... if i could send you this as a script that took a couple of arguments, would you guys be able to integrate it somehow? [09:23] well, send through or post to the pastebin what you come up with, and w'll try to help [09:51] Mez: I would like "bzr serve" to be able to run a simple SSH daemon, I think that would be neat. [09:52] Mez: if you make any progress towards that, please do post it here or send it to the mailing list [09:53] poolie: http://rafb.net/p/flZlui28.html is the summary report with 500ms latency and the 'network' test suite from usertest trunk [09:54] poolie: no surprises (mostly the same, bzr.dev a little bit better in a few cases). [09:54] poolie: oh, and those are the results from running on a bzr.dev repo. [09:55] * spiv -> dinner [09:55] i wonder why the AddTasks ones were so much slower? [09:55] well done though, that's great [09:55] is the patch up for review? [10:05] spiv, but wouldnt that cause issues for people using it in its current state? [10:06] Mez: presumably it would listen for ssh on a different port [10:06] aswell... [10:06] (as the current functionality of bzr serve) [10:08] Mez: there's already talk of having bzr serve --http run a webserver, making the command more of a swiss army knife [10:08] ah, kk [10:09] JOAT functionality ;) [10:12] bzr serve uses the I/O of the socket right, so, if i wired that up to have SSH auth on the front end, then I could hopefully, just pass the stream into that, and make a new protocol name that makes bzr auth with SSH first, and then use the "normal" protocol... right? [10:13] right [10:13] yay :D makes life sooooo much easier then [10:13] it may be easiest to have the serve process spawn off a subprocess connected up over pipes [10:14] argh, confusing, but i think I know what you mean [10:14] but to be fair, doing it that way means I shouldnt have to do too much "fake ssh" and it'd work nicely [10:14] (can use relative paths!) [10:15] hey Mez [10:16] hey james_w :D how're things/ [10:16] good thanks, you? [10:16] tired [10:16] should be asleep by now ;) [10:17] but i always stay awake on my days off ;) [10:21] poolie, though I doubt you'd be happy with me pulling in conch as a dependency ? [10:21] use paramiko, we already depend on it [10:22] * Mez doesnt know how to do it with paramiko though :0 [10:23] more learning :-0 [10:36] gonna sleep, will look at it later [10:59] poolie: Not sure why AddTask is slower, judging from http://benchmark.bazaar-vcs.org/usertest/log/usertest.log it's probably just noise. === mark1 is now known as markh [11:45] thanks spivvo [11:45] night [12:39] abentley: Shelf 2 sounds really cool. :) I've been wanting a git-gui-esque tool for commits, and this should make it much easier. [12:45] hya. i'm getting the following error when trying to push to a (stacked) branch on LP: [12:45] bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://intellectronica@bazaar.launchpad.net/%7Eintellectronica/launchpad/me-too-ui-updates/.bzr/repository/') [12:45] any idea what this might be? [12:46] abentley: ^^^ [12:49] intellectronica: I have a patch to fix that bug [12:49] spiv: is that something that i can apply locally, or something that would need to happen on the server? [12:50] intellectronica: https://bugs.edge.launchpad.net/bzr/+bug/230902, http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081008054310.GC19754%40steerpike.home.puzzling.org%3E [12:50] Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] [12:50] intellectronica: local [12:50] intellectronica: note that fixing that bug won't make things work, exactly. It'll just let us see what the real underlying error is, rather than this secondary error. [12:51] spiv: ok, i'll give it a try. thanks! [12:51] intellectronica: My guess is you'll see an error like the one stub reported in the comments of that bug (i.e. what he saw after applying my fix) [12:52] intellectronica: If so, I don't have any insight into that, but following up with abentley and/or filing a bzr bug would be appropriate. [12:53] b.t.w this only happens if i try to push to the existing branch. pushing to a new branch in the same repository works fine [12:53] intellectronica: a -Dhpss trace *might* give a hint [12:54] * spiv -> bed [12:54] intellectronica: I'd love to hear how it goes, though. [12:54] spiv: sure, i'll update when i have more info [12:54] good night [12:54] intellectronica: thanks! [12:56] lifeless: awake :-\? [13:02] http://code.mumak.net/2008/10/more-bzr-hacking.html --- what are "working trees"? [13:04] intellectronica: It's worth noting that initial push and subsequent pushes use quite different code paths. [13:04] idnar: what SVN calls the working copy, basically. i.e. files on disk that you can look at, edit, and run commands like "commit" and "revert" on. [13:05] abentley: i don't know if this is relevant. i pushed to that branch many times. the last time just a few minutes before it stopped working [13:05] With that patch applied, the real error won't be masked, and we'll have more hope of solving it. [13:05] intellectronica, abentley: random sleepy thought: maybe autopacking in a stacked repo does something funny? [13:05] * spiv -> really sleep! [13:06] spiv: Does autopacking in general still do something funny? [13:06] (if autopacking is occuring, the .bzr.log will say so) [13:06] spiv: how does that differ from a bound branch? [13:06] I know jam had a patch for that. [13:07] idnar: They're completely different concepts. A bound branch does not necessarily have any files that you can edit, commit, etc. [13:08] I guess I'm just confused about terminology [13:09] A working tree is just the collection of files that that you can edit, commit, etc. It may be in the same place as your branch. It may be in a different place. [13:09] okay [13:10]