| poolie | hello | 00:04 |
|---|---|---|
| mwhudson | jam: i'm not sure i understand | 00:13 |
| lifeless | mwhudson: this is for stacking? | 00:24 |
| mwhudson | lifeless: yeah | 00:29 |
| mwhudson | i guess i could only change BranchFormat7.open | 00:34 |
| mwhudson | and do most of what bzrdir.open_branch does myself | 00:35 |
| === arjenAU2 is now known as arjenAU | ||
| mwhudson | lifeless: i replied to your mail | 00:52 |
| lifeless | mwhudson: a hook to alter is less disruptive than a signature change which will propogate many levels deep | 01:05 |
| mwhudson | indeed | 01:06 |
| lifeless | but conceptually | 01:07 |
| lifeless | if you change open I'd rather see a 'transform_fallback' parameter rather than disable/enable | 01:07 |
| lifeless | with the transform being required to return a url when given a url | 01:07 |
| mwhudson | fair enough | 01:08 |
| mwhudson | changing open appears to be a can of worms though | 01:08 |
| mwhudson | so i'm going to give a hook a go | 01:08 |
| mwhudson | lifeless: what do you think the hook should do? | 01:09 |
| lifeless | that is, you can't disable stacking, but you can change the pointer | 01:09 |
| mwhudson | take a url, give a url, or take a url, give a repository, or ... ? | 01:09 |
| lifeless | you need something that takes a url beca use you want to get there before url connection is attempted | 01:11 |
| mwhudson | indeed | 01:11 |
| lifeless | I think its easier to allow url->url | 01:11 |
| lifeless | because then these transforms can stack | 01:11 |
| mwhudson | point | 01:11 |
| mwhudson | lifeless: something roughly like this? http://pastebin.ubuntu.com/55463/ | 01:17 |
| poolie | 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:18 |
| mwhudson | poolie: yes, i think so | 01:19 |
| mwhudson | (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 |
| poolie | so i think that means launchpad can't do anything with branches that are stacked on locations not on launchpad? | 01:19 |
| poolie | i don't think that'd be a good idea | 01:20 |
| mwhudson | if launchpad can't open the branch, what can you do? | 01:20 |
| mwhudson | 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 |
| poolie | ok | 01:21 |
| * jml agrees with mwh | 01:21 | |
| poolie | i think that's fine, and it's good to be clear about ti | 01:22 |
| poolie | it8 | 01:22 |
| poolie | it** | 01:22 |
| lifeless | mwhudson: s/should/must/ | 01:22 |
| mwhudson | lifeless: right | 01:22 |
| lifeless | also please check None is not returned or something like that | 01:22 |
| mwhudson | lifeless: makes sense | 01:23 |
| poolie | mwhudson: re that hook, it seems like you should perhaps pass the stacked branch url too | 01:23 |
| mwhudson | poolie: yes, probably | 01:23 |
| mwhudson | poolie: or the stacked branch itself, maybe | 01:23 |
| poolie | mwhudson: there's also external documentation of hooks that should be updated | 01:23 |
| poolie | maybe, probably, though it deserves a warning that it's half-baked | 01:24 |
| mwhudson | certainly | 01:24 |
| ferringb | curious... anyone looked at long term memory usage of bzr/api consumers? | 01:47 |
| ferringb | noticed an annoying trend of loggerhead/trac-bzr both developing heavy leaks, wondering if others have seen it for alternative apps | 01:47 |
| Odd_Bloke | ferringb: I suspect those are the only long-running consumers that we have. | 01:51 |
| Odd_Bloke | Though I don't know how the Eclipse plugin does it, and there is 'bzr shell' in bzrtools. | 01:51 |
| lifeless | ferringb: its likely python memory fragmentation, though it could be a genuine leak | 01:53 |
| lifeless | ferringb: I suspect bzr itself isn't leaking, based on previous tests | 01:54 |
| ferringb | lifeless: I doubt it's memory fragmentation | 02:03 |
| ferringb | actually I know it's not | 02:03 |
| ferringb | have at least one reproducible ~18/20MB leak | 02:04 |
| ferringb | if it were fragmentation, it would level off at some point (very least the growth wouldn't stay linear) | 02:04 |
| lifeless | ferringb: ok | 02:04 |
| ferringb | either way, setting up to heappy it, just wondering if anyone else has seen odd behaviour | 02:04 |
| lifeless | loggerhead on launchpad has trouble from time to time | 02:05 |
| lifeless | much better since the big overhaul | 02:05 |
| ferringb | yeah, upgraded recently, been happy w/ the results for the most part | 02:05 |
| ferringb | lifeless: curious, launchpad allow the misc cralwers to scrape loggerhead pages? | 02:05 |
| lifeless | I think its blocked | 02:07 |
| lifeless | back soon, doofing | 02:07 |
| spiv | 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:07 |
| ferringb | spiv: rough size of utf8 cache entries? | 02:09 |
| spiv | # of revisions * (length of an average revision id + 40 bytes) | 02:12 |
| spiv | (where 40 bytes is a guesstimate of the size of the overhead of a PyString object plus keeping a dict entry or two) | 02:12 |
| spiv | Hmm, maybe length of a revision id * 2, because I guess the cache keeps the unicode and the str version. | 02:13 |
| spiv | Basically, 20MB would be a pretty huge number of entries in that cache! | 02:13 |
| mwhudson | lifeless, poolie: i just sent a bundle to the list | 02:18 |
| mwhudson | with an inappropriate subject, wahoo | 02:19 |
| * mwhudson resends | 02:20 | |
| jam | spiv: by my math with your numbers, it only takes 67K revisions to hit 20MB | 02:21 |
| spiv | 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 |
| lifeless | paths too | 02:23 |
| markh | poolie: ? | 02:25 |
| lifeless | jam: your abbreviations are unclear to me | 02:27 |
| lifeless | 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 |
| jam | I'm not, I was asking for comments, though | 02:27 |
| poolie | markh: hi | 02:28 |
| lifeless | jam: "seems worth investigating" | 02:28 |
| lifeless | jam: though, please consider with gc repositories | 02:28 |
| markh | poolie: hi. Can you think of an example of some "doctest-ish mappings" I could use as a kindof "template"? | 02:28 |
| lifeless | jam: which for text reconstruction, have a radically different read pattern | 02:28 |
| jam | last I tried gc, performance was pretty abysmal | 02:28 |
| jam | at least for the 'fetch' case | 02:29 |
| lifeless | jam: yes, and we know why :P | 02:29 |
| jam | and it would have the same structure for "log" | 02:29 |
| jam | since those aren't compressed anyway | 02:29 |
| lifeless | yes | 02:29 |
| markh | I'm not sure what they would look like exactly. I would have thought normal unittests that use the api would be easier? | 02:29 |
| markh | (but I've never quite drank the doctest kool-aid :) | 02:30 |
| lifeless | doctest-- | 02:30 |
| markh | "doctest == testable documentation" in my book, and its not clear that is what we are doing | 02:31 |
| markh | but - I'm not trying to argue the merits of that, but if doctests are desired a template would help alot. | 02:31 |
| lifeless | markh: whats the context here btw? | 02:31 |
| markh | case sensitivity | 02:32 |
| lifeless | blackbox tests? | 02:32 |
| markh | 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:32 |
| lifeless | markh: I would translate that as write some docs about the problem | 02:33 |
| poolie | write some docs that have quoted fragments of code | 02:33 |
| lifeless | markh: but yeah, I think chat to poolie at this point | 02:33 |
| poolie | i don't mean that they should necessarily be executable, because doctest other than as testable documentation has some drawbacks | 02:34 |
| poolie | did you read alexander's wiki page? | 02:34 |
| markh | maybe "black-box doctests"? ie, quote shell commands using bzr rather than code? | 02:35 |
| markh | I read the wiki page after sending my initial mail. Its fairly good but a little light on specifics. | 02:35 |
| markh | It also fails to address that windows isn't truly case-insentitive generally - its closer to "case retaining" | 02:35 |
| lifeless | case preserving case insensitive is the usual description | 02:36 |
| markh | ie, the case of the filename is retained, but any case can be used to access it. | 02:36 |
| markh | right - and the wiki doesn't make that distinction. | 02:36 |
| poolie | 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 |
| markh | eg, FAT truly is case-insensitive IIUC | 02:36 |
| poolie | but i don't know if people genuinely agree where those tests should go | 02:37 |
| lifeless | markh: VFAT isn't, and real FAT can store arbitrary bytes, its up the fs layer on top :P | 02:37 |
| markh | lifeless: OK - the FAT FS layer on windows is truly case insensitive IIUC :) | 02:37 |
| RAOF | 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:37 |
| lifeless | 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 |
| markh | 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:38 |
| markh | those docs could then be turned into regular black-box tests and then the impl can be determined? | 02:39 |
| poolie | right | 02:40 |
| markh | ok cool, thanks. | 02:41 |
| poolie | i think they could possibly actually be run as doctests | 02:41 |
| poolie | treating them as "this is a testable document of how we're generally handling case sensitivity" | 02:41 |
| lifeless | I'd be strongly tempted to just write blackbox tests for specific commands | 02:41 |
| markh | 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 |
| lifeless | doctests are viciously harsh to work with when you need filesystem support | 02:42 |
| lifeless | you can spend days just getting things to work right | 02:42 |
| markh | yeah | 02:42 |
| poolie | right | 02:42 |
| lifeless | by strongly tempted, I actually mean, you couldn't pay me to write this sort of thing as a doctest | 02:43 |
| poolie | 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 |
| poolie | a pseudocode doctest | 02:43 |
| poolie | don't worry, you couldn't pay me enough to have me try to make you do it :) | 02:43 |
| lifeless | :P | 02:43 |
| jelmer | hmm, 1.8.1 removes MutableTree.get_file_with_stat() ? | 02:46 |
| jelmer | s/1.8.1/1.8rc1/ | 02:46 |
| poolie | jelmer, really, i thought it was added? | 02:47 |
| jelmer | I must be too tired to read the traceback right | 02:48 |
| jelmer | yeah, never mind me | 02:48 |
| lifeless | jelmer: thats new, part of commit race closing | 02:48 |
| jelmer | bzr-rebase doesn't provide MapTree.get_file_with_stat() yet | 02:48 |
| lifeless | thats more likely :) | 02:49 |
| mwhudson | spiv: seen https://bugs.edge.launchpad.net/bzr/+bug/278673 ? | 02:49 |
| ubottu | Launchpad bug 278673 in launchpad-bazaar "Traceback when uploading to an invalid location" [Undecided,Triaged] | 02:49 |
| jelmer | I'll fix it tomorrow when I'm actually awake... | 02:50 |
| mwhudson | spiv: i have the feeling it might be fixed in bzr.dev by now | 02:50 |
| jelmer | g'night | 02:50 |
| spiv | mwhudson: Actually, I suspect it isn't | 02:52 |
| mwhudson | spiv: slacker | 02:53 |
| mwhudson | :) | 02:53 |
| spiv | Nope, I don't think it is. | 02:53 |
| ferringb | spiv: not a process as much as a request via trac-bzr | 03:16 |
| ferringb | spiv: reasonably sure trac-bzr in general has it's own issues, but either way tracing it (finally got my hijacker working again) | 03:16 |
| jml | I'm doing a merge and getting a contents conflict on a file | 03:37 |
| jml | thing is, the file doesn't exist in the branch being merged into. | 03:37 |
| jml | what's the deal?\ | 03:38 |
| lifeless | jml: it used to exist | 03:38 |
| lifeless | jml: left side change -> delete | 03:39 |
| lifeless | jml: right side change -> modify | 03:39 |
| jml | lifeless: thanks. | 03:39 |
| spiv | lifeless: can we turn you into a "bzr explain-conflict" plugin? :) | 03:39 |
| lifeless | spiv: no | 03:40 |
| lifeless | spiv: but you can patch the conflict system to explain itself more | 03:40 |
| jml | lifeless: if I try to get the log for the path, I get: bzr: ERROR: Path does not have any revision history | 03:42 |
| jml | lifeless: AIUI, this conflicts with your theory. | 03:44 |
| * spiv -> lunch | 03:47 | |
| * jml is perplexed | 03:48 | |
| lifeless | jml: deep history is not checked | 04:07 |
| lifeless | jml: try ls -r ancestor:other-branch | 04:08 |
| jml | lifeless: it's in the list. | 04:09 |
| jml | lifeless: but that doesn't help me learn why it was deleted. | 04:09 |
| lifeless | log -v might | 04:10 |
| lifeless | or log -m '\bbasename\b' | 04:10 |
| === jamesh_ is now known as jamesh | ||
| jml | lifeless: by 'basename', you mean os.path.basename(), right? | 04:12 |
| jml | no results. | 04:12 |
| lifeless | shame, they didn't mention the file while commiting its delete | 04:16 |
| lifeless | jml: log -v is probably the key | 04:18 |
| lifeless | jml: one possible thing is 'rm foo; add foo; commit; | 04:19 |
| jml | lifeless: log -v doesn't give any results either. | 04:19 |
| lifeless | jml: the file is in the branch? | 04:19 |
| jml | lifeless: no. | 04:20 |
| lifeless | jml: is it in trunk ? | 04:20 |
| jml | lifeless: yes. | 04:20 |
| jml | lifeless: merging trunk into the branch raises the conflict. | 04:20 |
| lifeless | and log -v in the branch doesn't show it being deleted anywhere ? | 04:20 |
| jml | lifeless: that's right. 'bzr log -v path/to/file' says bzr: ERROR: Path does not have any revision history | 04:21 |
| lifeless | that command is useless for this | 04:21 |
| lifeless | I mean literally 'log -v' | 04:21 |
| lifeless | log PATH needs PATH to be in the WT, or *the last commit* only. | 04:21 |
| lifeless | 2-commits back and the path won't be found | 04:21 |
| mwhudson | can i get someone to look at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48ED5C67.9020408%40canonical.com%3E please? | 04:24 |
| jml | lifeless: ok, so log -v and grep? | 04:24 |
| lifeless | jml: yes | 04:24 |
| * jml tries | 04:24 | |
| lifeless | jml: btw I would have said 'log FILE' if that was what I meant :) | 04:24 |
| poolie | mwhudson: i'll look | 04:25 |
| mwhudson | poolie: thanks | 04:25 |
| poolie | i set up an rdesktop-accessible windows vm for testing and packgaing | 04:26 |
| poolie | mwhudson: +1 | 04:26 |
| mwhudson | poolie: thanks | 04:27 |
| jml | lifeless: is there some way I can do this without generating the log for the entire history of this branch? | 04:28 |
| lifeless | jml: -r -1..ancestor:otherbranch | 04:28 |
| lifeless | jml: but it will take just as long | 04:28 |
| lifeless | jml: so don't interrupt what you are doing | 04:28 |
| jml | lifeless: ok. | 04:30 |
| lifeless | jml: (log incrementally generates output, so the time-to-find-first-reference is identical) | 04:31 |
| jml | lifeless: incidentally, I think Bazaar could handle this use case better. | 04:31 |
| lifeless | indeed | 04:31 |
| lifeless | I'd like bzr search to index changes better | 04:31 |
| lifeless | and the inventory work I'm doing at the moment should help too | 04:31 |
| jml | lifeless: would that make 'bzr log removed_file' do something? | 04:32 |
| lifeless | jml: no more than it does today | 04:32 |
| jml | :( | 04:32 |
| lifeless | jml: searching all the way to the dawn of time is what it doesn't do today | 04:32 |
| lifeless | jml: and its hard to justify that it should do that by default, because that will always be somewhat expensive | 04:33 |
| lifeless | jml: however, a search index could do it fast | 04:33 |
| jml | lifeless: I'd settle for 'bzr log --deleted FILE' or similar | 04:33 |
| lifeless | and if the search tech advances sufficiently we can make it be part of core | 04:33 |
| jml | or something that gave me the revno of when it was deleted. | 04:34 |
| jml | learning why a file was deleted seems to be a good thing for a version control to help you do. | 04:37 |
| lifeless | sure | 04:41 |
| === abadger19991 is now known as abadger1999 | ||
| spiv | abentley: shelf 2 sounds very cool | 05:40 |
| abentley | spiv: Thanks. | 05:40 |
| lifeless | abentley: hi | 05:41 |
| poolie | jam: thanks for the ppa packaging updates and documentation! | 05:42 |
| abentley | lifeless: Hi. | 05:42 |
| lifeless | abentley: got time to chat about your new tree method? | 05:42 |
| poolie | i have some queries but i guess you may be gone | 05:42 |
| abentley | lifeless: A bit. Gotta be up early for a chat with sabdfl. | 05:42 |
| lifeless | 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:43 |
| lifeless | s/have context/have no context/ | 05:44 |
| abentley | lifeless: We haven't officially deprecated inventory, but I hope we'll be able to. | 05:44 |
| abentley | lifeless: PreviewTree doesn't have one, because I thought it would be a good way to push that process along. | 05:45 |
| abentley | lifeless: It's somewhat a cheat to get the InventoryEntry without having an Inventory. | 05:46 |
| lifeless | abentley: right, thats why I think its less clear, without being better in any other way | 05:46 |
| abentley | lifeless: It's better in that I don't have to implement PreviewTree.inventory | 05:47 |
| abentley | lifeless: We talked about this on the list in just the past week. | 05:47 |
| abentley | lifeless: jam was especially in favour of it. | 05:47 |
| lifeless | ok | 05:48 |
| lifeless | do you remember the thread name? I should read it and reply I guess | 05:48 |
| lifeless | shelf2 sounds nice | 05:48 |
| lifeless | and I do want you to get this patch in | 05:48 |
| lifeless | also | 05:48 |
| lifeless | woo | 05:48 |
| lifeless | all tests passsing on my split inv format | 05:48 |
| abentley | lifeless: great stuff. | 05:49 |
| abentley | lifeless: Thread was: [MERGE] Enable merging into PreviewTree | 05:49 |
| abentley | lifeless: The other way I can avoid implementing PreviewTree.inventory is to use Tree.iter_entries_by_dir to get single entries. | 05:50 |
| abentley | lifeless: Would you prefer that? poolie's distaste with that pattern inspired this patch. | 05:50 |
| lifeless | 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:52 |
| abentley | lifeless: Okay, catch you later. | 05:55 |
| lifeless | abentley: I'll reply to the older thread | 05:56 |
| lifeless | poolie: want a chat? | 06:39 |
| poolie | lifeless: yes, but this time i'm really playing squash at 5 | 06:39 |
| lifeless | :P | 06:39 |
| lifeless | sure whenever then | 06:40 |
| poolie | markh: if you're still here, are there any docs on building windows installers/packages? | 06:40 |
| lifeless | grab me tomorrow morning if you like | 06:40 |
| poolie | now's fine, at least briefly | 06:40 |
| markh | poolie: in general its usually "setup.py install" | 06:40 |
| poolie | that's all? | 06:40 |
| lifeless | poolie: ok ringing asap | 06:40 |
| markh | 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:41 |
| markh | 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:44 |
| markh | (not to mention the svn libs themselves :) | 06:45 |
| Wyverny | 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:50 |
| markh | Wyverny: try 'bzr help repositories' | 06:51 |
| Wyverny | I have that open. | 06:51 |
| markh | "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:51 |
| markh | "To create a shared repository use the init-repository command" | 06:52 |
| markh | so usually you would create a shared repo in /src/myproject, then use 'bzr init' to create branches *under* /src/myproject | 06:53 |
| markh | all the branches would then share the same repo | 06:53 |
| Wyverny | I see. I get it. Thanks. I knew it was something simple. | 06:54 |
| Wyverny | Can there be only a single .bzrignore? Or can I have one per branch? | 06:59 |
| bob2 | it is only per-branch | 06:59 |
| bob2 | (as a file in the root of each branch) | 06:59 |
| Wyverny | Oh, great. | 07:00 |
| Wyverny | Simple questions, simple answers. I'd buy you guys a beer if you were around ;) | 07:02 |
| markh | in an hour I'll have one for you anyway ;) | 07:04 |
| vila | hi all | 07:05 |
| Mez | 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 |
| Mez | 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 |
| Mez | any ideas? (I'm looking for something similar to how svn does users over HTTP preferably) | 07:57 |
| jml | Mez: afaik, ssh or ftp are your only options. | 07:58 |
| Mez | which means setting up new user accounts :9 | 07:59 |
| jml | Mez: you can restrict it so that the devs don't get shells on your computer | 07:59 |
| Mez | jml, I know that... but I don't want to have more UNIX accounts that I have to manage and secure | 08:00 |
| jml | Mez: *nod* | 08:00 |
| jml | 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 |
| Mez | because they're covered in my audits ;) | 08:01 |
| jml | Mez: ah hah. | 08:02 |
| lifeless | ciao | 08:02 |
| jml | lifeless: cya | 08:03 |
| jml | Mez: so, if this is an open source project, you can host the branches on Launchpad for free. | 08:03 |
| jml | Mez: but I am filing a bug *right now* about this :) | 08:03 |
| Mez | jml, yeah, it is, but I don't want to push it out to public till it's code-ready at the moment | 08:03 |
| Mez | jml, feel free to subscribe my nick to tbe bug | 08:04 |
| jml | Mez: done. | 08:05 |
| jml | 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:06 |
| jml | (I understand there are different levels of "not read") | 08:07 |
| jml | ready, rather. | 08:07 |
| spiv | Mez: FWIW, there are SSH/SFTP servers that don't use UNIX accounts. They're not necessarily easy to setup, though... | 08:09 |
| Mez | spiv, exactly | 08:10 |
| Mez | spiv, names? | 08:12 |
| spiv | 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 |
| spiv | I wouldn't be surprised if there are others, although I've never looked. | 08:13 |
| spiv | (I know it's possible with Twisted, because I've done so... that code is now part of what runs bazaar.launchpad.net) | 08:14 |
| Mez | spiv, i'm not really that good with python | 08:17 |
| spiv | Mez: "just use +junk branches on Launchpad" is a pretty good answer for branches of experimental open source projects, though. | 08:18 |
| spiv | I guess I understated when I said "not necessarily easy to setup" :) | 08:18 |
| Mez | spiv, release a user friendly version of the code for bazaar.launchpad.net ;) | 08:18 |
| jml | Mez: working on it. | 08:19 |
| Mez | jml, ? | 08:19 |
| jml | Mez: Launchpad is scheduled to be open sourced in the next year. | 08:20 |
| Mez | yeah, yeah, I know | 08:20 |
| jml | (spiv originally wrote bazaar.launchpad.net, but I've been maintaining it for the last couple of years) | 08:21 |
| jml | anyway, it's time for me to leave the computer and enjoy the sunlight. | 08:22 |
| spiv | jml: good plan | 08:23 |
| spiv | 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:24 |
| * spiv runs it with a simulated 500ms latency loopback network device on bzr.dev and 1.7.1 | 08:25 | |
| Mez | 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) | 08:37 |
| Odd_Bloke | For today's controversial and incorrect suggestion: Dropping support for Python 2.5 :D | 09:01 |
| poolie | hello | 09:05 |
| poolie | hey spiv, well done! | 09:05 |
| poolie | Mez: that would be nice | 09:05 |
| poolie | not so hard to do, as we already have an ssh server used in testing | 09:06 |
| Mez | poolie, Id write it if I knew how | 09:07 |
| poolie | if you'd like to try we can help you | 09:08 |
| Mez | 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:08 |
| poolie | so StubSSHServer in tests/blackbox/test_serve.py is probably close to what we need... | 09:09 |
| Mez | argh | 09:10 |
| Mez | Im not even going to TRY and do a branch on here | 09:10 |
| * Mez wonders if the eeePC would be able to cope and decides to do a lightweight CO instead | 09:11 | |
| Mez | poolie, actually, yeah, it could probably work from that | 09:16 |
| Mez | 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:19 |
| poolie | well, send through or post to the pastebin what you come up with, and w'll try to help | 09:23 |
| spiv | Mez: I would like "bzr serve" to be able to run a simple SSH daemon, I think that would be neat. | 09:51 |
| spiv | Mez: if you make any progress towards that, please do post it here or send it to the mailing list | 09:52 |
| spiv | poolie: http://rafb.net/p/flZlui28.html is the summary report with 500ms latency and the 'network' test suite from usertest trunk | 09:53 |
| spiv | poolie: no surprises (mostly the same, bzr.dev a little bit better in a few cases). | 09:54 |
| spiv | poolie: oh, and those are the results from running on a bzr.dev repo. | 09:54 |
| * spiv -> dinner | 09:55 | |
| poolie | i wonder why the AddTasks ones were so much slower? | 09:55 |
| poolie | well done though, that's great | 09:55 |
| poolie | is the patch up for review? | 09:55 |
| Mez | spiv, but wouldnt that cause issues for people using it in its current state? | 10:05 |
| poolie | Mez: presumably it would listen for ssh on a different port | 10:06 |
| Mez | aswell... | 10:06 |
| Mez | (as the current functionality of bzr serve) | 10:06 |
| jml | Mez: there's already talk of having bzr serve --http run a webserver, making the command more of a swiss army knife | 10:08 |
| Mez | ah, kk | 10:08 |
| Mez | JOAT functionality ;) | 10:09 |
| Mez | 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:12 |
| poolie | right | 10:13 |
| Mez | yay :D makes life sooooo much easier then | 10:13 |
| poolie | it may be easiest to have the serve process spawn off a subprocess connected up over pipes | 10:13 |
| Mez | argh, confusing, but i think I know what you mean | 10:14 |
| Mez | 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 |
| Mez | (can use relative paths!) | 10:14 |
| james_w | hey Mez | 10:15 |
| Mez | hey james_w :D how're things/ | 10:16 |
| james_w | good thanks, you? | 10:16 |
| Mez | tired | 10:16 |
| Mez | should be asleep by now ;) | 10:16 |
| Mez | but i always stay awake on my days off ;) | 10:17 |
| Mez | poolie, though I doubt you'd be happy with me pulling in conch as a dependency ? | 10:21 |
| poolie | use paramiko, we already depend on it | 10:21 |
| * Mez doesnt know how to do it with paramiko though :0 | 10:22 | |
| Mez | more learning :-0 | 10:23 |
| Mez | gonna sleep, will look at it later | 10:36 |
| spiv | poolie: Not sure why AddTask is slower, judging from http://benchmark.bazaar-vcs.org/usertest/log/usertest.log it's probably just noise. | 10:59 |
| === mark1 is now known as markh | ||
| poolie | thanks spivvo | 11:45 |
| poolie | night | 11:45 |
| Odd_Bloke | 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:39 |
| intellectronica | hya. i'm getting the following error when trying to push to a (stacked) branch on LP: | 12:45 |
| intellectronica | 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 |
| intellectronica | any idea what this might be? | 12:45 |
| intellectronica | abentley: ^^^ | 12:46 |
| spiv | intellectronica: I have a patch to fix that bug | 12:49 |
| intellectronica | spiv: is that something that i can apply locally, or something that would need to happen on the server? | 12:49 |
| spiv | 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 |
| ubottu | Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] | 12:50 |
| spiv | intellectronica: local | 12:50 |
| spiv | 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:50 |
| intellectronica | spiv: ok, i'll give it a try. thanks! | 12:51 |
| spiv | 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:51 |
| spiv | 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:52 |
| intellectronica | 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 |
| spiv | intellectronica: a -Dhpss trace *might* give a hint | 12:53 |
| * spiv -> bed | 12:54 | |
| spiv | intellectronica: I'd love to hear how it goes, though. | 12:54 |
| intellectronica | spiv: sure, i'll update when i have more info | 12:54 |
| intellectronica | good night | 12:54 |
| spiv | intellectronica: thanks! | 12:54 |
| Jc2k | lifeless: awake :-\? | 12:56 |
| idnar | http://code.mumak.net/2008/10/more-bzr-hacking.html --- what are "working trees"? | 13:02 |
| abentley | intellectronica: It's worth noting that initial push and subsequent pushes use quite different code paths. | 13:04 |
| spiv | 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:04 |
| intellectronica | 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 |
| abentley | With that patch applied, the real error won't be masked, and we'll have more hope of solving it. | 13:05 |
| spiv | intellectronica, abentley: random sleepy thought: maybe autopacking in a stacked repo does something funny? | 13:05 |
| * spiv -> really sleep! | 13:05 | |
| abentley | spiv: Does autopacking in general still do something funny? | 13:06 |
| spiv | (if autopacking is occuring, the .bzr.log will say so) | 13:06 |
| idnar | spiv: how does that differ from a bound branch? | 13:06 |
| abentley | I know jam had a patch for that. | 13:06 |
| abentley | idnar: They're completely different concepts. A bound branch does not necessarily have any files that you can edit, commit, etc. | 13:07 |
| idnar | I guess I'm just confused about terminology | 13:08 |
| abentley | 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 |
| idnar | okay | 13:09 |
| idnar | and how do "repositories" work? | 13:10 |
| idnar | man | 13:15 |
| idnar | maybe it would be easier if I forgot everything I thought I already knew about bzr and started again | 13:15 |
| idnar | I'm reading some docs now, and nothing seems familiar :P | 13:15 |
| awilkins | idnar: I've admined SVN repos for years, and it took me a few days to get a handle on DVCS | 14:17 |
| idnar | awilkins: I'm familiar with half a dozen DVCS tools, and I use them on a regular basis | 14:18 |
| idnar | it's just that bzr has changed so much since I last used it | 14:19 |
| awilkins | Ah, yes, the pace doth quicken most fleetly | 14:19 |
| awilkins | I started around 0.9, I think it's jsut got better rather than scarier since then :-) | 14:19 |
| idnar | last time I used bzr, it didn't even work at all on win32 due to assumptions about path delimiters | 14:20 |
| awilkins | Since about 1.6 it's even been quite nippy on windows | 14:20 |
| awilkins | Although it still makes you green when you bzr st the same tree on Linux and get the rsponse back in less than a second | 14:20 |
| awilkins | OTOH, Mercurial still doesn't work for my project on windows because of the escaping-caps-with-underscores-in-long-paths thing | 14:27 |
| idnar | I'm a darcs user most of the time | 14:27 |
| awilkins | I tend to stick with things that work well on win32, alas. | 14:28 |
| awilkins | Does darcs? | 14:28 |
| idnar | I haven't run into any issues | 14:28 |
| idnar | it can be a bit tricky to get ssh working, but that's not really darcs's fault | 14:29 |
| awilkins | I've had success with bzr+ssh on windows | 14:29 |
| awilkins | Also with bzr+http over IIS | 14:29 |
| awilkins | You're right about SSH being a PITA though | 14:29 |
| idnar | anyhow, to be candid, I prefer hg to bzr in situations where darcs isn't appropriate | 14:30 |
| idnar | but then, bzr has launchpad integration | 14:31 |
| awilkins | Fair enough ; I never used it long enough to try it for the aforementioned reason | 14:31 |
| idnar | which is cheating, but it's pretty darn convenient | 14:31 |
| awilkins | I had a project that needed good, easy merges | 14:31 |
| idnar | and of course, there are plenty of projects where I don't get to choose the VCS tool | 14:31 |
| awilkins | SVN wouldn't cut it, and was too slow | 14:31 |
| idnar | so I need to know how to use pretty much everything :P | 14:31 |
| awilkins | Hg I tried next, but epic fail oin long paths with lots of caps in | 14:32 |
| idnar | honestly, part of my preference for hg is probably just that my mental image of bzr is still circa 0.6 or whatever where everything sucked | 14:32 |
| Peng_ | There's work on long paths in hg. | 14:32 |
| awilkins | git was too immature at the time (on win32) | 14:32 |
| idnar | (like, horrifically awful network performance) | 14:32 |
| awilkins | And still is, IMHO | 14:32 |
| awilkins | (git, immature on win32, that is) | 14:33 |
| idnar | man, git | 14:33 |
| awilkins | I have no opinion on the horrible network performance of bzr | 14:33 |
| idnar | I didn't think it would be possible to come up with a more confusing tool than tla | 14:33 |
| idnar | and then I tried git out | 14:33 |
| idnar | bzr's network performance got fixed ages ago | 14:33 |
| Arjen | idnar: When was that? | 14:33 |
| awilkins | My main problem with bzr and network performance is unrelated to the network protocols ; it's more to do with it considering network shares on Windows to be local filesystems | 14:33 |
| idnar | uhm, 0.7? 0.8? something like that, I think | 14:34 |
| Peng_ | ...Bzr's network performance used to be horrific, and now it's fast? It's still pretty bad, so wow, it must've been *terrible*. | 14:34 |
| awilkins | My problem is that unpacking is probably faster than, copying files over an SMB share on a VPN | 14:34 |
| idnar | well, I checked in about 100MB of repository | 14:34 |
| idnar | then I checked in a one-line change to a single file | 14:34 |
| idnar | and pushed that over the network | 14:34 |
| awilkins | but bzr will copy files if it can.. regardless of network speed, if you are using filesystem urls | 14:35 |
| idnar | and watched bzr transfer something like 200MB of data before it completed | 14:35 |
| fullermd | Oh, it was. Weave-era network access was unbelievably painful. | 14:35 |
| idnar | that was one of the reasons I gave up on bzr at the time | 14:35 |
| Peng_ | Hahaha, that's awesome. | 14:35 |
| idnar | so I dunno if it's great now or whatever | 14:35 |
| fullermd | It's still not overly pleasant, but at least now it's "Jeez, that's slow" rather than "Hey, where'd T Rex go?" | 14:36 |
| idnar | but I haven't run into any "okay, this is just impossible" situations yet | 14:36 |
| awilkins | And it still knocks the likes of SVN out of the parlk | 14:36 |
| awilkins | *park | 14:36 |
| idnar | I probalby need to sit down and do an in-depth side-by-side comparison of hg and bzr, just to get rid of my flawed mental image of bzr | 14:37 |
| awilkins | SVN over DAV is painful in it's own special way | 14:37 |
| idnar | SVN is really awful for me, because most SVN repositories are on the other side of a 400ms latency link for me | 14:37 |
| idnar | so any DVCS basically wins automatically | 14:38 |
| idnar | because I can commit locally etc. | 14:38 |
| Arjen | idnar: wait, you mean git 0.8? | 14:41 |
| idnar | Arjen: no, bzr | 14:42 |
| idnar | I guess you were asking about git, not bzr | 14:42 |
| Arjen | I was | 14:42 |
| idnar | git hasn't ever really changed in the "oh my god complicated" department | 14:43 |
| idnar | as far as I can tell | 14:43 |
| Arjen | Not even in 1.5 and 1.6? | 14:43 |
| idnar | did they remove commands in 1.5 and 1.6? :P | 14:44 |
| Arjen | ALl the low-level commands where moved to a separate directory, out of your PATH | 14:44 |
| awilkins | You could technically add a bzr-stylee porcelain to git, I suppose | 14:44 |
| idnar | anyhow, it still takes me half an hour just to figure out how to fetch a copy of a project's source code from git | 14:44 |
| Peng_ | "git clone"? | 14:45 |
| Arjen | Indeed | 14:45 |
| Peng_ | I have no idea what to do after that to pull new changes or branch or commit or anything, but I do know "clone". | 14:45 |
| idnar | when it works, it's fine | 14:45 |
| * Peng_ doesn't use git much | 14:45 | |
| idnar | but when you get an error message, it's nearly impossible to tell what you did wrong | 14:45 |
| Arjen | Peng_: git branch, git fetch, git merge | 14:45 |
| Arjen | idnar: True, in a number of cases | 14:46 |
| idnar | if I was familiar with git concepts in-depth, I'd probably have no problems interpreting the error message | 14:46 |
| Arjen | I've been playing with bzr lately, but I can't seem to do basic stuff. Like, getting it to tell me when a file was deleted, even if I know the file-id | 14:47 |
| idnar | but I don't, so all I know is that the URL someone gave me isn't something I can "git clone", with no idea of what to do next | 14:47 |
| Arjen | Or basic grepping in the source at a revision | 14:47 |
| awilkins | Arjen: The "when did my file get deleted" one is tricky at the moment because of the way inventories are stored | 14:48 |
| awilkins | Arjen: You have to compare inventories from each revision to work it out. | 14:49 |
| Arjen | awilkins: then 'git log --diff-filter=D -- $file' is a viable alternative ;-) | 14:49 |
| awilkins | Delta-storage for inventories would probably make that work a lot easier - anyone working on that? | 14:49 |
| LarstiQ | ehm | 14:50 |
| LarstiQ | awilkins: I'm reasonably sure that is the case | 14:50 |
| LarstiQ | awilkins: and what Arjen mentioned would work the same way? | 14:50 |
| awilkins | LarstiQ: That it's being worked on or that it already so? I was working under the impression that each revision stores the inventory in-toto | 14:51 |
| awilkins | I think the point is that you cant tell when a file is deleted from doing a log on just the file because it's deletion is not one of the log entries it participates in | 14:51 |
| awilkins | It just one day isn't there... rather than an entry which explicitly says "delete this file-id" | 14:52 |
| LarstiQ | awilkins: afaik it's inventory deltas for ages | 14:52 |
| awilkins | LarstiQ: Is it "we store the inventory" and that's delta compressed, or "we store what changed in the inventory for each revision" ? | 14:53 |
| LarstiQ | awilkins: but regardless of storage, doing the same operation as git log --diff-filter=D should be possible right now | 14:53 |
| LarstiQ | awilkins: I don't really see a big difference between the two | 14:54 |
| awilkins | It's been asked in here more than once and I've not seen a quick, concise way of doing it that didn't involve running the whole log | 14:54 |
| awilkins | LarstiQ: The former has no way of telling when the file was deleted just from reading inventories containing the file-id | 14:54 |
| awilkins | LarstiQ: You also then have to check all the children of inventories with that file-id to see if it becomes absent | 14:55 |
| awilkins | LarstiQ: Which is not very nice to have to index | 14:55 |
| LarstiQ | awilkins: right, but I'm under the impression the git log does it brute force as well | 14:55 |
| Arjen | It does | 14:55 |
| awilkins | I have no idea, but it seems a waste both way | 14:55 |
| awilkins | And i've yet to see a cheap and easy way of finding deletion revisions for a single file in bzr | 14:56 |
| awilkins | An inventory entry that said "deleted this file" would probably help a lot | 14:57 |
| Arjen | renames should be easier, I think? | 14:57 |
| awilkins | renames should be very easy, the file retains it's id | 14:57 |
| Arjen | But there's no command-line method to do that? | 14:58 |
| awilkins | Arjen: I wrote a log-on-fileid option into it once in about 5 minutes | 14:59 |
| awilkins | Arjen: So it's not hard... it just didn't solve the problem it was aimed at (finding deletions) | 14:59 |
| awilkins | Arjen: Very small hackage on log command required | 14:59 |
| awilkins | Arjen: It uses file-id internally anyway for "log foo" | 15:00 |
| LarstiQ | Arjen: log would be what I'd use | 15:01 |
| Arjen | And script it | 15:01 |
| Arjen | Which is of course a valid method, but requires work ;-) | 15:03 |
| awilkins | List a revision where you know the file is, grab the file-id, hack log --file-id in | 15:03 |
| Arjen | Uhm, hack log.py, you mean? | 15:05 |
| james_w | what, no jelmer? Unheard of. | 15:11 |
| Peng_ | Is it safe to use a relative path as a branch's parent? | 15:50 |
| LarstiQ | Peng_: safe as in? If you then move the branch or it's parent around it won't be able to find the parent | 15:51 |
| Peng_ | LarstiQ: Well sure, but will random commands fail? What if Launchpad mirrors the branch? | 15:52 |
| LarstiQ | Peng_: but it's ideal for when your branches are available via http and /srv/bzr wouldn't really help someone who mirrors | 15:52 |
| LarstiQ | Peng_: no, no problems there | 15:52 |
| Peng_ | Heh, that's exactly why I'm asking. I just did "bzr missing" on a branch in /srv/bzr whose parent is right next to it, and it contacted the HTTP server since that's what I'd set the parent to. | 15:54 |
| LarstiQ | Peng_: this was also the exact usecase for it :) | 15:54 |
| Peng_ | :) | 15:54 |
| * Peng_ goes off to edit some branch.conf files. | 15:55 | |
| awilkins | james_w: jelmers client had an excess flood earlier | 15:56 |
| james_w | jelmer: hey | 15:57 |
| james_w | jelmer: I was just looking at https://bugs.launchpad.net/bugs/132191 and can't really work out what's going on any more | 15:58 |
| ubottu | Launchpad bug 132191 in bzr-gtk "installs unuseable desktop file to bzr commit-notify" [Medium,Triaged] | 15:58 |
| james_w | jelmer: the "bzr commit-notify" command still doesn't work on Ubuntu, but I can't find anything disabling it. There seems to be a bzr-notify script in bzr-gtk, is this intended to be used now? | 15:59 |
| LarstiQ | doesn't work in what way? | 16:00 |
| LarstiQ | james_w: you might want `bzr lan-notify` from bzr-dbus | 16:00 |
| james_w | hey LarstiQ | 16:01 |
| james_w | "bzr commit-notify" gives unknown command | 16:01 |
| abadger1999 | Hey all, I was experimenting with 1.6.1-rich-root format on one of my branches. | 16:17 |
| LarstiQ | abadger1999: and? :) | 16:18 |
| abadger1999 | but it seems I can't push from that to a branch with the default format. | 16:18 |
| abadger1999 | How do I convert the branch back to default? | 16:18 |
| abadger1999 | (I actually converted a shared repository so losing and recreating all the revisions would be painful.) | 16:18 |
| LarstiQ | abadger1999: default being pack-0.92? | 16:19 |
| abadger1999 | Yeah. | 16:19 |
| abadger1999 | LarstiQ: bzr upgrade --default | 16:20 |
| Peng_ | Rich roots store extra metadata. You kind of can't downgrade. | 16:20 |
| Peng_ | It's possible to bzr init && bzr pull. | 16:20 |
| Peng_ | (to downgrade) | 16:20 |
| Peng_ | But bzr upgrade won't do it. | 16:21 |
| abadger1999 | Peng_: pull as opposed to branch? I'll try that. | 16:21 |
| LarstiQ | maybe we should have a bzr downgrade | 16:21 |
| Peng_ | Just hava it print "Hahaha, nice try." | 16:21 |
| LarstiQ | Peng_: ooh, I can make that | 16:22 |
| abadger1999 | Peng_: Nope. That didn't work. | 16:23 |
| abadger1999 | bzr: ERROR: KnitPackRepository('file:///home/badger/pkgdb/.bzr/repository/') is not compatible with | 16:23 |
| abadger1999 | KnitPackRepository('file:///home/badger/programming/.bzr/repository/') different rich-root support | 16:23 |
| Peng_ | ....Really? | 16:24 |
| abadger1999 | Same error as I get when I tried to bzr branch from the richroot repository to a non-richroot shared repository. | 16:24 |
| abadger1999 | Really. | 16:24 |
| Peng_ | Huh. | 16:24 |
| abadger1999 | bzr-1.7rc2 | 16:24 |
| abadger1999 | bzr init 0.3.x ; cd 0.3.x ; bzr pull ~/programming/0.3.x | 16:25 |
| abadger1999 | There's shared repositories on both sides of that. | 16:25 |
| * abadger1999 tries without shared repo | 16:26 | |
| LarstiQ | Peng_: bzr get http://richtlijn.be/~larstiq/downgrade | 16:26 |
| abadger1999 | LarstiQ: Does that have a test case? :-) | 16:27 |
| LarstiQ | abadger1999: I don't have a good answer | 16:27 |
| LarstiQ | abadger1999: doh! | 16:27 |
| LarstiQ | abadger1999: I'll add it right away | 16:27 |
| abadger1999 | :-( | 16:27 |
| abadger1999 | heh | 16:27 |
| jelmer | james_w, yes, bzr-notify should be used now | 16:28 |
| abadger1999 | Well, gorramit. This sucks. | 16:28 |
| * abadger1999 figures out least time consuming method of recreating all the changes | 16:28 | |
| jelmer | james_w, Still there? | 16:29 |
| Peng_ | LarstiQ: :D | 16:30 |
| james_w | jelmer: yeah. | 16:30 |
| james_w | jelmer: The .desktop is out of date in this version then. I presume it's fixed in experimental? | 16:31 |
| jelmer | james_w, It's not yet fixed in experimental, though it should be trivial | 16:31 |
| james_w | jelmer: ok, I've uploaded a fixed desktop file to Ubuntu. Would you like me to make the change for experimental? | 16:55 |
| jelmer | james_w, I hope to fix it upstream in a couple of days, not sure if it's important enough to fix in experimental before then | 16:56 |
| james_w | oh, it's fixed upstream I think | 16:57 |
| james_w | 603 Exec=bzr-notify | 16:57 |
| james_w | there is one more change here that passed me by though, changing the icon names in the .desktop files | 16:58 |
| fullermd | "There are some issues we would like to address and I'm looking to talk to some people with Subversion internals experience that can help us optimize the Subversion experience for our users." | 17:13 |
| fullermd | Your solution; I has it. | 17:13 |
| awilkins | Kittens? | 17:16 |
| fullermd | Well, given the choice between handing my code to kittens or subversion... | 17:17 |
| awilkins | Well, only if "kittens" is the codename for VSS around here | 17:17 |
| awilkins | I would say that VSS is only marginally better than "big network share" if only it didn't waste so much of your time | 17:18 |
| metajack | Anyone know why trac-bzr is showing revision names with %2F and %3A? | 17:33 |
| fullermd | Double encoding I presume. | 17:33 |
| jfroy|work | ack, bzr-svn just died on me :| | 17:40 |
| jelmer | hi jfroy|work | 17:40 |
| jfroy|work | Tried to branch a svn branch (previously used with bzr), and the command died with bzrlib.errors.KnitCorrupt: Knit _KnitGraphIndex(CombinedGraphIndex(GraphIndex | 17:40 |
| jfroy|work | jelmer: hello, and help! :p | 17:40 |
| jfroy|work | Does that error ring any bells? | 17:41 |
| === beuno is now known as beuno-lunch | ||
| jelmer | jfroy|work, please file a bug | 17:45 |
| jfroy|work | Will do. | 17:46 |
| visik7 | jfroy|work: works here using bzr.1.7 | 17:46 |
| visik7 | not with bzr-dev | 17:46 |
| jfroy|work | Any way to make bzr-svn happy again? | 17:46 |
| jfroy|work | I'm using 1.7.1 and 0.4.13 | 17:46 |
| rockstar | jelmer, hi | 17:46 |
| jelmer | rockstar, hi | 17:47 |
| visik7 | jfroy|work: bzr branch 1.7 and bzr-svn trunk | 17:47 |
| jelmer | jfroy|work, I'd need to look into it | 17:47 |
| rockstar | jelmer, someone in my dent feed would like an updated trac-bzr release. | 17:47 |
| rockstar | Looks like you're the team owner. | 17:48 |
| jfroy|work | I think this is happening only for a subset of a large svn repository. | 17:48 |
| jfroy|work | I have a checkout of another unrelated svn branch hosted in the same repository working fine. | 17:48 |
| jelmer | jfroy|work, yeah, this sort of error would be related to a specific branch | 17:49 |
| jelmer | rockstar, I am, though pretty much by default | 17:49 |
| jelmer | rockstar, trac-bzr needs to be fixed to work with bzr >= 1.6 | 17:49 |
| rockstar | jelmer, well, this user says he's got all his bugs fixed with bzr 1.6 in trunk. | 17:50 |
| jelmer | rockstar, if he does, he hasn't published his branch on launchpad | 17:51 |
| aruiz | lifeless: ping | 17:51 |
| rockstar | He was going to use svn, because he thought trac-bzr was broken, but then he said all the bugs were fixed in trunk, so he used that. | 17:51 |
| jelmer | rockstar, I'm aware of at least one bug remaining in trunk | 17:52 |
| jelmer | since it uses _get_weave() which was removed in bzr 1.6 | 17:52 |
| jelmer | rockstar, is there a particular reason he wants a release rather than just using trunk as is? | 17:52 |
| flacoste | i created a repository with --no-trees, is it possible to add a tree to branch in the repository afterwards? | 17:55 |
| luks | bzr checkout . should do it | 17:55 |
| metajack | jelmer: are revision names in trac supposed to show with %2F? | 17:56 |
| jelmer | metajack, in URLs, yes, other than that, no | 17:57 |
| metajack | jelmer: also, revision 44 of lp:trac-bzr does not seem to fix the %3A problem for 'current:' | 17:57 |
| flacoste | luks: ok, thanks, i'll try that | 17:57 |
| metajack | jelmer: they show up everywhere with escaping for me. | 17:57 |
| metajack | (running interpid latest bzr and trac, and trac-bzr from lp:trac-bzr trunk) | 17:57 |
| metajack | jelmer: I'm the user rockstar was talking about btw :) | 17:59 |
| jfroy|work | jelmer: is there any way to fix the issue, say by resetting the bzr svn props on all the files or some flag to bzr? | 17:59 |
| jfroy|work | the bug is https://bugs.launchpad.net/bzr-svn/+bug/280850, btw | 17:59 |
| ubottu | Launchpad bug 280850 in bzr-svn "bzrlib.errors.KnitCorrupt raised while checking out or branching a specific Subversion branch" [Undecided,New] | 17:59 |
| jelmer | jfroy|work, not really without knowing what's actually happening | 17:59 |
| jelmer | jfroy|work, I'll see if I can have a look at it later tonight | 17:59 |
| jfroy|work | No rush, I can fallback to svn in the meantime. | 18:00 |
| lexrupy | hello all | 18:01 |
| lexrupy | I got here a new (to me) behavior of bazaar checkouts | 18:01 |
| lexrupy | when I was out of network, I performed a bzr commit, and "automagically" the commit behaves as I had "bzr commit --local" | 18:02 |
| lexrupy | is that natural? | 18:02 |
| jelmer | metajack, are you sure you're running trunk? | 18:02 |
| jelmer | (it passes the tests) | 18:03 |
| metajack | jelmer: Pretty sure. I see the revision 49 change in backend.py on the machine. | 18:03 |
| jelmer | metajack, trac-bzr is pretty much unmaintained at this point | 18:11 |
| jelmer | I've been fixing things that I hit since I had an instance of it running | 18:12 |
| metajack | I assume you must not be using bzr 1.6+ on that instance. | 18:12 |
| metajack | I think all the 1.6 bugs are fixed now, and it's just down to this double quoting issue. | 18:13 |
| jelmer | menesis, trunk still uses _get_weave() and that's gone in 1.6 | 18:14 |
| jelmer | menesis, so I'm sure there's at least some code paths that break with 1.6 | 18:14 |
| metajack | There is a patch for that in the tracker, and it works. | 18:15 |
| metajack | I assumed that had made it to trunk since the other part of that patch was in revision 49. | 18:15 |
| jelmer | I didn't merge that patch because it's very inefficient | 18:17 |
| metajack | Better inefficient than completely broken, no? | 18:17 |
| === beuno-lunch is now known as beuno | ||
| jelmer | metajack, In my case, the two would be the same since trac has already taken the system down a couple of times | 18:18 |
| jelmer | metajack, Anyway, I'm happy to hand over the trac-bzr-team maintainance to somebody else if they're interested | 18:19 |
| jelmer | but I have no interest in continuing to work on it myself | 18:19 |
| metajack | Sigh. | 18:20 |
| metajack | This has pretty much been the only thing preventing me from using bzr. I'm sad to see it abandoned. | 18:21 |
| metajack | I will spend another little while trying to fix it. If I'm successful perhaps I will take you up on the maintainer offer. | 18:23 |
| jelmer | Thanks - it needs somebody who can spend more time on it then the occasional ad-hoc fix I have been doing. | 18:24 |
| lexrupy | anyone can confirm this to me? | 18:53 |
| lexrupy | please | 18:53 |
| jam | lexrupy: I haven't seen that behavior before | 19:18 |
| jam | Though I thought there was something with bzr-gtk that would detect your network connection | 19:18 |
| jam | jelmer do you remember that? | 19:18 |
| === abentle1 is now known as abentley | ||
| lexrupy | ... I also not before this version | 19:31 |
| fullermd | Does info still show it as a checkout? | 19:31 |
| lexrupy | yes | 19:32 |
| lexrupy | now I am using version that comes with ubuntu 8.10beta | 19:32 |
| lexrupy | bzr --version returns => Bazaar (bzr) 1.6.1 | 19:32 |
| lexrupy | I have also bzr-gtk installed | 19:33 |
| lexrupy | I found it very strange, because earlyer versions (also 1.6.x downloaded from ppa repo) were not doing this | 19:34 |
| fynn | Bazaar always keeps the file ownership and permissions on *NIX systems, right? | 19:34 |
| lexrupy | and with that versions I also used bzr-gtk | 19:34 |
| lexrupy | fynn: I never had this kind of problems... permissions always kept right | 19:35 |
| fynn | So if I delete a monitored some_file.py, and then "bzr revert some_file.py", I should always get some_file.py with the same permissions and ownership information? | 19:35 |
| lexrupy | fynn: I cannot do the rigtht answer for this question.... | 19:36 |
| lexrupy | going back to my "issue" | 19:37 |
| lexrupy | the good part is that all things gone right | 19:37 |
| Peng_ | fynn: The only permissions bzr cares about is the execute bit. | 19:39 |
| Peng_ | fynn: Also, try it and see. :P | 19:39 |
| lexrupy | local commits, and the when network was resumed I done "bzr update", all things happened as I had "bzr commit --local" off the network, a merge has been done and next commit goes to master branch | 19:41 |
| lexrupy | *gone to master branch | 19:42 |
| miracle2k | I want to go to (and use) a certain revision of a branch. what is the right way to do that? "bzr revert -r d"? | 19:52 |
| luks | depends on your definition of 'use' | 19:53 |
| fullermd | Depends on just what you mean by "go to and use". | 19:53 |
| luks | heh | 19:53 |
| miracle2k | actually, I want to use the 1.8.0 release of bzrtools, since the trunk requires a new bzr version | 19:54 |
| miracle2k | so i have a branch of lp:bzrtools, except that I need an older version | 19:54 |
| miracle2k | I know I could do "bzr checkout -r", but what would I do if I have an unbound branch? | 19:55 |
| fullermd | I'd just pull down to the version you care about. | 19:55 |
| Odd_Bloke | miracle2k: 'bzr uncommit -r' is probably what you want. | 19:55 |
| fullermd | Then you're all set to pull up to a later version when you want to. | 19:55 |
| fullermd | No, don't do that; it's extra work. Just use pull. | 19:56 |
| Odd_Bloke | Uhm... how is it extra work? | 19:56 |
| fullermd | Because you have to do a revert afterward. | 19:56 |
| miracle2k | I already tried "bzr pull -r tag:release-1.8.0", except it gives me "no revisions to pull" | 19:56 |
| Odd_Bloke | Hmm, true. | 19:56 |
| Odd_Bloke | miracle2k: 'pull --overwrite' | 19:56 |
| fullermd | You need --overwrite to pull, since you're moving backward. | 19:56 |
| miracle2k | ah, I see, that works. | 19:57 |
| miracle2k | thanks everybody | 19:57 |
| === Spaz is now known as Spazpaimon | ||
| === Guest52963 is now known as jelmer | ||
| === jelmer is now known as Guest30665 | ||
| === Guest30665 is now known as Guest52963 | ||
| === fta_ is now known as fta | ||
| === Guest52963 is now known as jelmer | ||
| poolie | hello | 21:55 |
| poolie | vila: are you still here? | 21:55 |
| lifeless | poolie: hi | 21:57 |
| lifeless | poolie: middayish ok with you ? | 21:57 |
| lifeless | poolie: also, for usertest, patches via lp merge requests or to the list ? | 21:58 |
| poolie | i think so | 21:58 |
| poolie | i should check with steph | 21:58 |
| poolie | i don't know, either | 21:58 |
| poolie | did spiv post his yet? | 21:58 |
| lifeless | not sure | 21:58 |
| lifeless | I'm adding st -r -2..-1 | 21:58 |
| poolie | lifeless: also, you need to tell marianna _today_ when you're arriving and departing | 21:58 |
| lifeless | oh frell | 21:58 |
| lifeless | I need to book tickets | 21:59 |
| poolie | you don't necessarily need to book as there are plenty of flights, but you do need to decide | 21:59 |
| poolie | but you should book soonish | 21:59 |
| lifeless | marianna is in the uk yes? | 22:00 |
| poolie | yep | 22:00 |
| lifeless | righto | 22:00 |
| lifeless | btw, usertest doesn't lock itself out :P | 22:00 |
| lifeless | and bzr.inv is a tad slower at fetch | 22:01 |
| lifeless | hilarity ensued | 22:01 |
| poolie | ah | 22:01 |
| poolie | i wondered how that could be happening | 22:01 |
| lifeless | so looking at it | 22:02 |
| lifeless | the output name rearranging is in the bash script | 22:02 |
| lifeless | so I think we need to lock in the bash script | 22:02 |
| lifeless | as the output name stuff should be protected | 22:02 |
| poolie | yes, we should | 22:04 |
| poolie | i started adding one but because it needs to be bulletproof against the machine stopping, as happened a couple of times, i was a bit lazy | 22:05 |
| Accidus | Hmm... I want to use a different version of a plugin. I've set the BZR_PLUGIN_PATH variable to point at the new directory, but bzr still doesn't list it under 'bzr plugins'. | 22:05 |
| lifeless | poolie: well, we can unwedge after a restart | 22:06 |
| lifeless | Accidus: you need to point at the containing directory | 22:06 |
| lifeless | if your plugin is /foo/bar/myplugin | 22:06 |
| lifeless | BZR_PLUGIN_PATH should be /foo/bar | 22:06 |
| Accidus | That's what I did. | 22:07 |
| lifeless | poolie: also I think there is a stock shell lock utility one can use, I don't recall the name offhand | 22:07 |
| lifeless | Accidus: does bzr report an error loading it perhaps? | 22:07 |
| lifeless | Accidus: and are you on windows? | 22:08 |
| Accidus | Do I need to look anywhere, or will it output it to the terminal? | 22:08 |
| Accidus | Now, working on Ubuntu | 22:08 |
| Accidus | * no | 22:08 |
| lifeless | it should put a one-liner to the terminal | 22:08 |
| lifeless | and details to ~/.bzr.log | 22:08 |
| Accidus | No error reported on terminal | 22:08 |
| lifeless | Accidus: well look in the log anyhow :) | 22:10 |
| Accidus | No, doesn't seem to contain any errors | 22:11 |
| Accidus | Here's what I did. I probably missed something | 22:12 |
| lifeless | it should say | 22:12 |
| lifeless | looking for plugins in XXX | 22:12 |
| lifeless | where XXX is your path | 22:12 |
| Accidus | 1. Set the BZR_PLUGIN_PATH to point to /home/accidus/dev/plugins | 22:12 |
| Accidus | And the actual plugin is a directory under plugins | 22:12 |
| Accidus | So that if I ``ls $BZR_PLUGIN_PATH'', I see the plugin's dir listed | 22:13 |
| Accidus | Ah. I have an idea. | 22:13 |
| Accidus | Okay. I'm stoopid | 22:16 |
| Accidus | Never mind me. Sorry to have wasted your time. | 22:17 |
| * Accidus blushes. | 22:17 | |
| lifeless | ? | 22:17 |
| lifeless | poolie: btw please let the current usertest run complete | 22:17 |
| lifeless | poolie: I will get valuable data from it even though its glacially slow | 22:17 |
| Accidus | Didn't export the env var | 22:18 |
| Accidus | So bzr didn't have it. | 22:18 |
| poolie | did you kill off the others? | 22:18 |
| lifeless | poolie: yes | 22:18 |
| lifeless | poolie: oh foo, just realised, they're stomping on teh same file, so I won't gain data anyhow | 22:18 |
| lifeless | poolie: so don't worry, I'll nuke that one too | 22:19 |
| === abentley1 is now known as abentley | ||
| lifeless | poolie: how does this sound - I will disable the cronjob | 22:26 |
| lifeless | poolie: and start a fresh run | 22:26 |
| poolie | if it's going to be slow i'd rather get the locking etc fixed up | 22:27 |
| poolie | i can do it in a bit | 22:27 |
| lifeless | it will be, I'd like a result today though and I suspect that even with just one running it will be pushing it to finish by 5 | 22:28 |
| lifeless | I've just started a task with cron disabled; its easy enough to kill that and please do so if you want to | 22:29 |
| lifeless | I'm also trying to dig up an easy locker for us | 22:29 |
| dfc | Is the bzr service up and running on lp? | 22:31 |
| dfc | i am getting an odd error and the references that I can find for it have all coincided with a lp outage. | 22:31 |
| jam | lifeless: I'm looking over your "repository" code. Quick point of clarification | 22:35 |
| jam | you have a "chk_serializer" module | 22:35 |
| jam | which seems to be an XML derived form | 22:35 |
| jam | is that meant to go away in time? | 22:35 |
| jam | also, some quick naming thing for CHKInventory. you use the term "entry" in multiple ways. For example: | 22:37 |
| lifeless | jam: not unless we kick away all the existing code that checks serializer objects; its used for the revision objects | 22:37 |
| jam | return self._bytes_to_entry( | 22:37 |
| jam | self.id_to_entry.iteritems([file_id]).next()[1]) | 22:37 |
| lifeless | jam: inventory objects are not serialized through it, and finally | 22:37 |
| jam | lifeless: sure, but not for inventory objets? | 22:37 |
| lifeless | its used for equality testing | 22:37 |
| lifeless | repo1.serializer != repo2.serializer | 22:37 |
| jam | lifeless: k. I mostly just wast trying to understand, as you added special code to unpack inventories | 22:38 |
| lifeless | dfc: afaik it is | 22:38 |
| jam | _unpack_entry is only used for inventory stuff | 22:38 |
| jam | I realize it is "work in progress" I just wanted to make sure I understood | 22:38 |
| dfc | AttributeError: 'ProtocolThreeDecoder' object has no attribute '_in_buffer' . . . .. . . > http://pastebin.com/f57b9959d | 22:38 |
| dfc | lifeless: any idea why I would be getting that message? | 22:39 |
| jam | dfc: you only get that error if you run "-Dhpss" what is the failure without it? | 22:39 |
| jam | dfc: (the cause is buggy code in a debug statement) | 22:39 |
| dfc | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 22:39 |
| lifeless | jam: that code fragment uses entry in the same way I think | 22:39 |
| lifeless | dfc: I suspect a ssh key issue | 22:39 |
| lifeless | dfc: try ssh bazaar.launchpad.net | 22:40 |
| jam | lifeless: I think you need "sftp bazaar.launchpad.net" | 22:40 |
| jam | since it doesn't support plain connections | 22:40 |
| lifeless | jam: no, ssh will test auth just fine | 22:40 |
| lifeless | 08:36 < jam> return self._bytes_to_entry( | 22:40 |
| lifeless | ^ convert from bytes to an inventory entry object | 22:41 |
| lifeless | 08:36 < jam> self.id_to_entry.iteritems([file_id]).next()[1]) | 22:41 |
| lifeless | ^ a CHKMap (aka persistent dict) from file id to inventory entry | 22:41 |
| jam | lifeless: so that code is a bit confusing because "id_to_entry" is "id_to_bytes" object | 22:41 |
| jam | I understood what was happening eventually | 22:41 |
| lifeless | ok | 22:42 |
| lifeless | thanks for looking! | 22:42 |
| jam | you also poke at CHKMap._root_node directly in CHKInventory, is it meant to be that coupled? | 22:42 |
| lifeless | I'm being cautious about making things public attributes | 22:43 |
| lifeless | given all the insane fuss about it in reviews over the last few mnoths | 22:43 |
| jam | then I'm a bit surprised that you expose "CHKInventory.id_to_entry" as a plain attribute, and hide CHKMap._root_node | 22:44 |
| jam | id_to_entry seems like an implementation detail | 22:44 |
| jam | are you planning on making it more public? | 22:44 |
| lifeless | I very much expect fetch and inventory delta iteration to walk the maps | 22:45 |
| lifeless | if that ends up being in methods on CHKInventory then id_to_entry will become private | 22:45 |
| lifeless | so root_node is something I'm not sure how/where/when it belongs; its part of the how-to-make-COW-clean question | 22:47 |
| lifeless | which isn't that functional, but is important for safety and cleanliness | 22:47 |
| lifeless | id_to_entry is something I am sure it is in the right place; I'm not 100% it is public but I suspect it is | 22:47 |
| jam | lifeless: are the final value nodes all single-inventory-object bytes? | 22:48 |
| jam | I don't see anywhere that they are aggregated | 22:48 |
| lifeless | jam: thats right | 22:49 |
| lifeless | jam: I was working on the 'what breaks when we have multiple documents per inventory' issue | 22:49 |
| lifeless | this was a fast to implement way to achieve that | 22:49 |
| jam | so the 4.4k entries in .cix for bzrtools is because there are that many total versions of the various inventory lines? | 22:50 |
| jam | I'm still understanding why some values in that index have an "N" as the prefix, but I'll get to that somewhere | 22:50 |
| lifeless | you'll have 1 entry per inventory (the root node of the CHK) and 1 per unique inventory entry value | 22:50 |
| lifeless | isn't N no end of line ? | 22:52 |
| lifeless | (how are you looking at the index - be sure you get \x00 seperators visible) | 22:53 |
| lifeless | spelling blah | 22:53 |
| jam | lifeless: "bzr dump-btree --raw | vim -R -" | 22:53 |
| jam | \x00 shows up just fine | 22:53 |
| lifeless | ok | 22:53 |
| lifeless | whats an example with a leading N ? | 22:53 |
| jam | sha1:0004feba9f0af7777528a6ac7a62abb83cd6ed3d \00 \00 N3131511 228 | 22:54 |
| jam | I added spaces around \00 to make it obvious | 22:54 |
| lifeless | yes thats the no end of line marker | 22:54 |
| jam | ah | 22:54 |
| lifeless | it says no end of line, starts at 3131511 for 228 bytes | 22:54 |
| lifeless | so its a value | 22:55 |
| lifeless | because values are chkvalue:\n%(BYTES)s | 22:56 |
| lifeless | and the serialiser for inventory entries doesn't put a trailing \n as that would be awkward | 22:56 |
| lifeless | so specifically its a chkvalue of an inventory entry | 22:56 |
| lifeless | jam: so my general approach for testing the next bits... | 22:59 |
| lifeless | jam: I want to parameterise CHKMap by how to aggregate values/internal nodes | 23:00 |
| lifeless | jam: and pass those same parameters to CHKSerializer | 23:00 |
| lifeless | so we get several different serializer values | 23:00 |
| lifeless | then we can trivially run up N different formats each behaving differently but with all the higher level iteration etc code the same | 23:01 |
| lifeless | jam: I'm not going to do this immediately, just sketching out the approach in the hope you'll want to dive in :P | 23:01 |
| jam | so just to make sure I understand | 23:02 |
| jam | at the moment you have a structure with 1 root node that contains a chk to every file-id | 23:02 |
| lifeless | jam: what I'm going to do now is to teach fetch to use CHKInventory.update(inv_delta) rather than full reserialization | 23:02 |
| jam | basically, just as though you took the current inventory and hashed each line separately and put it into the repository | 23:02 |
| lifeless | jam: yes, thats a fair description. layerwise it sounds different :) | 23:03 |
| lifeless | jam: actually, not quite, you missed the inventory object itself; the 4-liner that has root id, chk root and revision. | 23:03 |
| lifeless | so meta node, dictionary root, and one chk per file id | 23:04 |
| jam | k | 23:04 |
| ricardokirkner | hi. is this the place to (also) make questions about bzr-svn? | 23:04 |
| lifeless | ricardokirkner: sure | 23:04 |
| lifeless | jelmer: your public awaits | 23:04 |
| ricardokirkner | I am trying to compile bzr-svn from trunk (I know, I know)... and I'm getting some import issues | 23:05 |
| ricardokirkner | namely 'cannot import name foreign' | 23:05 |
| lifeless | ricardokirkner: there was a patch on the list for this | 23:06 |
| lifeless | ricardokirkner: I believe its been applied already, just pull again | 23:06 |
| lifeless | jam: another related thing is to add a path_to_id map | 23:06 |
| lifeless | jam: and use it it avoid full iteration when populating .children | 23:07 |
| ricardokirkner | lifeless, I just checked it out... last revno is 1935 | 23:07 |
| ricardokirkner | mhh... I did bzr branch lp:bzr-svn is this correct? | 23:08 |
| ricardokirkner | or should I use another branch? | 23:08 |
| lifeless | ricardokirkner: I'm not sure | 23:08 |
| lifeless | see the bzr-svn docs on the wiki | 23:08 |
| ricardokirkner | alright.. and I will look in the mailing list | 23:08 |
| ricardokirkner | thx | 23:08 |
| jam | ricardokirkner: I think the lp:bzr-svn branch isn't particularly stable | 23:11 |
| jam | I would recommend using a released version | 23:11 |
| ricardokirkner | jam, ok | 23:11 |
| ricardokirkner | jam, I wanted to build bzr-svn, in order to debug some issues with http authentication | 23:12 |
| ricardokirkner | but I can first try with a more stable release | 23:12 |
| jam | ricardokirkner: well, he also uses tags | 23:12 |
| jam | so you might do "bzr branch lp:bzr-svn -r bzr-svn-0.4.9" | 23:13 |
| jam | I'm not 100% sure his naming scheme, but it is something like that | 23:13 |
| jam | you can branch the whole thing and then "bzr revert -r tag:..." as well | 23:13 |
| ricardokirkner | alright.. I'm checking the 0.4 series right now | 23:14 |
| Peng_ | FWIW, I run bzr.dev and lp:bzr-svn/0.4 without issues, but I only use bzr-svn for pulling things. | 23:15 |
| Peng_ | (And bzr-svn does occasionally break, but not in data-lossy ways or anything.) | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!