| lifeless | jam: yes, thats my thoughts too | 00:00 |
|---|---|---|
| lifeless | jam: want to work up a patch, or shall I? | 00:00 |
| lifeless | the packing heuristics still bother the heck out of me | 00:01 |
| jam | obviously I won't have time to do so today... :) | 00:01 |
| lifeless | :P | 00:01 |
| jam | "packing heuristics"? | 00:01 |
| lifeless | I'm still looking at this critical bug today I expect | 00:01 |
| lifeless | keys to nodes | 00:01 |
| lifeless | the gzip magic | 00:01 |
| jam | ah, that part | 00:01 |
| jam | well, we can punt on it | 00:01 |
| poolie | jam, spiv, hi | 00:01 |
| jam | but it is fairly useful | 00:01 |
| lifeless | jam: its needed I think | 00:02 |
| jam | hi poolie | 00:02 |
| lifeless | jam: but its gets very bad on bzr-search indices | 00:02 |
| jam | IIRC it shrunk them by a significant amount | 00:02 |
| jam | lifeless: how long are your bzr-search keys? | 00:02 |
| lifeless | jam: tiny | 00:02 |
| lifeless | jam: 4, 5 bytes | 00:02 |
| jam | the pack work was certainly tuned around 60-byte keys, and often 120 bytes as tuples | 00:02 |
| lifeless | the keys are document ids | 00:03 |
| lifeless | e.g. '1' | 00:03 |
| lifeless | well, ('1',) | 00:03 |
| spiv | Good morning. | 00:03 |
| poolie | jam, merging from BB urls was working for me on monday | 00:03 |
| jam | poolie: it seems to be a BB thing | 00:03 |
| jam | as BB is giving a 200 OK, Status: 404 results | 00:03 |
| mwhudson | beuno: hm you said something about making the breadcrumb stuff less inventory specific | 00:03 |
| poolie | make up your mind :) | 00:03 |
| mwhudson | beuno: did you get to that? | 00:03 |
| jam | so something is confused about the return code | 00:03 |
| mwhudson | spiv: hello | 00:03 |
| jam | I don't know HTTP well enough to know if "Status: " is supposed to overwride | 00:04 |
| beuno | mwhudson, no, I didn't. I left that for after we fixed the root issue | 00:04 |
| lifeless | jam: so, inventories | 00:04 |
| mwhudson | beuno: hmm | 00:04 |
| lifeless | jam: I mailed, you replied - is it paused now ? | 00:04 |
| lifeless | hi poolie | 00:05 |
| jam | lifeless: today was painting the deck redux | 00:05 |
| jam | I want to follow up | 00:05 |
| spiv | mwhudson: hi | 00:07 |
| lifeless | jam: ok | 00:08 |
| lifeless | jam: I'd like that | 00:09 |
| mwhudson | beuno: http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/209 | 00:22 |
| beuno | mwhudson, I knew you'd find a simpe way around it :) | 00:23 |
| mwhudson | it's a bit of a hack, but then hey! it's loggerhead | 00:23 |
| mwhudson | at least it's a localized hack | 00:24 |
| beuno | hahaha | 00:24 |
| aquarius | I'm a bit confused by bzr init and init-repo. I'd like to store my home folder on my laptop in bzr, with a centralised repo on a remote sftp server (so I can check out from there to other machines). | 00:24 |
| james_w | hey aquarius | 00:25 |
| james_w | you probably don't need init-repo in that case | 00:25 |
| aquarius | ah. I'm not clear what the difference between init-repo and init is... | 00:25 |
| james_w | you may want it on the server if you are going to have branches "desktop" and "laptop" that are slightly different and you merge between them | 00:26 |
| beuno | mwhudson, so you think it's ready for merging, or do you want me to have another look at it? | 00:26 |
| james_w | but I doubt you'll be making feature branches on your laptop to try out experimental new settings | 00:26 |
| james_w | hey besonen_mobile__ | 00:26 |
| aquarius | so can I just, on the laptop, do "bzr init sftp://server; bzr checkout sftp://server $HOME" ? | 00:26 |
| james_w | hey beuno | 00:26 |
| beuno | hey james_w, how are you? | 00:26 |
| mwhudson | beuno: which? directory_breadcrumbs? no | 00:26 |
| james_w | good thanks beuno, you? | 00:26 |
| james_w | enjoying work? | 00:26 |
| aquarius | james_w: for the moment, assume that I want all checkouts to be identical on every machine. (I may add cleverness later. :)) | 00:27 |
| james_w | aquarius: that will work in principle, though it would probably fail as $HOME already exists | 00:27 |
| beuno | james_w, good good, enjoying it very much, yes :) | 00:27 |
| james_w | aquarius: you probably want to create the branch locally and then push to the server | 00:27 |
| james_w | beuno: cool :-) | 00:27 |
| aquarius | james_w: OK...see, now I'm confused again. How do I do that, then? :) | 00:28 |
| james_w | aquarius: "cd $HOME; bzr init; bzr add <files you want to version>; bzr commit; bzr push sftp://server/" or similar | 00:28 |
| james_w | aquarius: plain "bzr add" is probably not what you want, so I would avoid that. | 00:29 |
| james_w | judicious use of "bzr ignore" will probably help you avoid problems | 00:29 |
| aquarius | james_w: excellent. A few questions. can I just do plain "bzr add" if I already have a .bzrignore file that correctly ignores the stuff I want to ignore? | 00:29 |
| james_w | unless you actually aim to version ~/Videos/ and ~/Music/ | 00:29 |
| aquarius | second: does sftp://server/whatever/I/put have to exist before I push to it, or will push create it if it doesn't exist? | 00:30 |
| james_w | aquarius: yeah, if you've set up ignores then bzr add won't add them. If you "bzr add <something you've got in .bzrignore>" then it will be added | 00:30 |
| aquarius | *nod* win | 00:30 |
| james_w | aquarius: no, it doesn't have to exist, but if sftp://server/whatever/I doesn't exist then you will need --create-prefix | 00:31 |
| aquarius | third: once I've done all that, on machine2 can I just "cd $HOME; bzr checkout sftp://wherever/ ." ? | 00:31 |
| aquarius | fourthly: imagine that I'd tried to do all this a couple of weeks ago and got it wrong (this is why i have a .bzrignore file). If I just remove $HOME/.bzr then all my previous screwups are eliminated, yes? bzr doesn't keep my info anywhere else magic? | 00:32 |
| james_w | in principle, but again, I think it will fail due to . existing, though it's probably worth a try | 00:32 |
| aquarius | *nod* | 00:32 |
| james_w | a workaround is to checkout in to a tempdir, then move .bzr from that tempdir to $HOME | 00:33 |
| james_w | you will also need to move any files not already on the machine from the tempdir | 00:33 |
| james_w | just running "bzr diff" will tell you what is missing and modified | 00:33 |
| aquarius | final question (you've been really helpful!): if I want to work on other projects hosted in bzr (say, a project currently in launchpad) and I grab a branch into $HOME/Projects or similar -- is this going to screw up because I'm putting one bzr project inside another? | 00:33 |
| james_w | you can add anything else you like of course | 00:33 |
| james_w | 4) there's no secret hidden stuff, so removing .bzr should be enough | 00:34 |
| james_w | the exception would be if you had run "bzr init-repo ." in / or /home, which is very unlikely | 00:34 |
| aquarius | nah, I didn't do that :) | 00:35 |
| james_w | you can check "bzr info" output before removing the old .bzr to make sure | 00:35 |
| james_w | finally, no that's not a problem. | 00:35 |
| james_w | let me find you a reference on what init-repo actually is | 00:35 |
| james_w | aquarius: does http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#repositories explain what "init-repo" is for sufficiently? | 00:40 |
| aquarius | james_w: sorta, yeah. So if I'm not doing multiple branches then I don't need init-repo at all. | 00:41 |
| james_w | aquarius: yeah, that's the main point for you in this case | 00:42 |
| aquarius | right, ok. makes a bit more sense now, I think :) | 00:42 |
| james_w | but if you do work on a project and use multiple branches for it, then shared repositories (in the bzr sense) are a big win | 00:42 |
| aquarius | *nod* I can imagine. | 00:44 |
| aquarius | if I don't create a shared repo now (on my sftp server) and later wish I had created one after all, can I take the existing pushed-to repo and "upgrade" it to be a shared one? | 00:45 |
| james_w | aquarius: yup, see the reconfigure command | 00:46 |
| aquarius | coolness. so, it sounds to me like doing it the simple way first is the best plan and then being more complex later if I need to will work :) | 00:46 |
| james_w | aquarius: I've never done it myself, so I can't give you the recipe, but if you do come to need it then swing back here and someone will be able to help | 00:47 |
| markh | lifeless: fyi, that samba issue yesterday turns out to be fairly non-deterministic - it randomly fails and works without the additional gc.collect(). Would it be useful to keep it added and to try and determine if it ever fails *with* it? | 00:49 |
| lifeless | markh: well its not a 'solution' | 00:50 |
| lifeless | markh: but if we can track down an actual cause - ftw | 00:50 |
| markh | yeah, hence me not knowing if that avenue is worth spending more time on... | 00:51 |
| markh | I figure than in the short-term, if we can get everything working correctly on native windows (ie, no attempts to move/delete open files), then we can be fairly confident we aren't leaking such handles in a major way. Which led to me looking at those test failures yesterday I submitted a patch for | 00:53 |
| lifeless | right | 00:58 |
| beuno | mwhudson, bundle branch up for review. Is pickscrape's branch ready? Do you want me to merge it? | 01:19 |
| mwhudson | beuno: it should have breadcrumbs on all pages | 01:19 |
| pickscrape | beuno: once the branch root problem is solved I need to apply it to a few other pages before it should be merged | 01:19 |
| mwhudson | and the last 'crumb' shouldn't be a link | 01:20 |
| beuno | pickscrape, lp:~mwhudson/loggerhead/directory_breadcrumbs | 01:20 |
| beuno | it's fixed | 01:20 |
| mwhudson | and we should think about how it interacts with the --user stuff | 01:20 |
| mwhudson | but perhaps that's less important | 01:20 |
| beuno | ok, so a few more things to chew before | 01:20 |
| * beuno is going office -> home bbiab | 01:21 | |
| pickscrape | mwhudson: excellent, thanks! | 01:21 |
| pickscrape | I'll get to spreading that feature out to other pages as soon as I can | 01:22 |
| mwhudson | pickscrape: cool | 01:26 |
| mwhudson | pickscrape: please try to find some way of extracting the common code, not copy+paste :) | 01:26 |
| Toksyuryel | That seems like bad advice, except the last one. | 01:56 |
| mwhudson | Toksyuryel: ? | 01:59 |
| Toksyuryel | komputes's quitline | 02:00 |
| mwhudson | oh | 02:00 |
| * mwhudson has mental filters for those | 02:00 | |
| Toksyuryel | heh | 02:00 |
| poolie | markh, it would be interesting to do a test transport decorator that forbids moving/deleting open files | 02:04 |
| markh | yeah, that would be cool. How would it work? monkeypatching? | 02:05 |
| lifeless | wouldn't help with tree transform stuff | 02:05 |
| lifeless | but I don't think we actually do that; I think its more reference leaks and the like due to slack gc | 02:06 |
| markh | I think most of the problems I found last night were caused by exceptions keeping files alive slightly longer than normal. | 02:07 |
| poolie | that's true it won't particularly help with tree transform | 02:07 |
| markh | and most of these were fairly close to the "surface" of the API - so its only a problem in practice for a single process doing multiple bzr "commands" before terminating - eg, the test suite. | 02:07 |
| poolie | i guess you could either monkeypatch or otherwise intercept file open/close | 02:08 |
| markh | ie, I haven't yet found a problem a user of normal 'bzr' would see. | 02:08 |
| poolie | oh i see | 02:08 |
| markh | there is actually one strange bit of code in a decorator that might be responsible for the exception causing the cycle - lemme find it | 02:10 |
| markh | decorators._fast_needs_read_lock() - it has a try/except/raise construct where a try/finally appears more logical. Keeping the traceback alive in a local variable is potentially a cycle that wouldn't otherwise exist. | 02:12 |
| poolie | i was thinking of something similar but a bit different, which is catching on unix problems that might break windows | 02:13 |
| markh | the fact the name includes "_fast" though makes we worry someone has benchmarked things or something and found that to be faster | 02:13 |
| poolie | specifically relating to transport/control file stuff | 02:13 |
| markh | yes, I think that would be beneficial | 02:13 |
| poolie | see for example fakevfat.py | 02:13 |
| lifeless | markh: the fast refers to docstrings | 02:13 |
| markh | similarly for locks ;) Was there some conclusion to that? | 02:13 |
| lifeless | markh: and the like | 02:13 |
| lifeless | markh: did you read the dirstate RFC I posted a few days back | 02:13 |
| markh | lifeless: regarding the ability to avoid locks in many cases? | 02:14 |
| lifeless | yes | 02:14 |
| poolie | it seems to me we want to run most tests with the lowest-common-denominator transport... | 02:14 |
| markh | lifeless: it sounds good to me, but I have to admit the conversation was a little too far over my head to make any meaningful contribution :s | 02:15 |
| lifeless | I think we should run the entirely in memory - but we can make that as low as we want | 02:15 |
| jml | hmm. running bzr selftest --no-plugins only drops about 700 tests compared to the full suite for me. | 02:15 |
| * jml should write more tests for his plugins | 02:16 | |
| markh | poolie: fakevfat does seem to be the way to approach it | 02:17 |
| markh | they even list that as the first feature to be added ;) | 02:17 |
| poolie | i don't know if there are any interesting behaviours in ntfs that wouldn't occur on vfat | 02:18 |
| poolie | lifeless, i'd think we should gradually go to running on vfat+memory | 02:18 |
| poolie | it would be interesting to profile how many tests use which transport class | 02:19 |
| markh | not many we use. ntfs has recently grown links | 02:19 |
| lifeless | poolie: ntfs won't do things worse for us than vfat | 02:20 |
| markh | but - back to the locks in the short term. Many tests on windows are failing due to an assumption locks are not exclusive - any ideas about how to handle that in the short term? Just leave them failing? | 02:20 |
| lifeless | poolie: it simply has additional capabilities we could use if we wanted [but generally explorer dies in the arse if you use them, so we shouldn't] | 02:20 |
| lifeless | markh: its in the definition of behaviour for that tree type; I don't know that there is much we can do | 02:21 |
| poolie | sure | 02:21 |
| poolie | lifeless, i was thinking of things like unicode handling | 02:21 |
| poolie | it may not differ meaningfully to us | 02:21 |
| markh | we could arrange for them to be either skipped or known failures if it was worth the bother, and if it wasn't going to stay that way for the long term :) | 02:21 |
| poolie | at any rate the code that's affected should mostly not use transports | 02:21 |
| lifeless | vfat is the same as NTFS for unicode to all intents and purposes - | 02:21 |
| poolie | markh, so one approach here is to avoid having two objects addressing the same file | 02:22 |
| lifeless | poolie: so, tree rules, whats the outcome there? | 02:22 |
| poolie | we're seeing the conflict aaiu because we have that aliasing | 02:22 |
| markh | I'm still not sure of the impact of the locks - do_merge is being called by the test suite with the same dir - are there real user scenarios that would hit this? | 02:23 |
| lifeless | markh: yes | 02:24 |
| lifeless | markh: I answered that yesterday FWIW | 02:24 |
| markh | oops | 02:24 |
| * markh scrolls back... | 02:24 | |
| poolie | lifeless, well, i think we should still do what i said: remove the code that reads it | 02:24 |
| poolie | unless someone proposed an alternative? | 02:24 |
| lifeless | its a real bug, it causes problems and its not amenable to changes without changing the format, because of old bzr clients | 02:25 |
| poolie | lifeless, re _buffer_all, would those repos have also OOM'd in 1.5? | 02:25 |
| lifeless | poolie: no, just hadn't got the go-ahead | 02:25 |
| lifeless | poolie: yes, but they won't in 1.6 | 02:25 |
| lifeless | unless we start triggering _buffer_all | 02:25 |
| poolie | but at the price of getting substantially slower for things that currently _do_ work | 02:26 |
| lifeless | yes | 02:26 |
| lifeless | constraints and accomodations again | 02:26 |
| poolie | lifeless, i had in mind to make the api just something like _readahead_hint('per_file_graph') | 02:28 |
| poolie | or 'per_file_log' | 02:29 |
| poolie | then those repos in this release can buffer everything, but there's no implied promise it's doing so | 02:29 |
| jml | lifeless: btw, I was looking around the test scenario stuff. It seems that objects in the scenario dict are shared between tests? | 02:29 |
| lifeless | jml: bzr's scenarios? | 02:30 |
| lifeless | jml: the parameterisation stuff ? | 02:30 |
| poolie | markh, re do_merge, i didn't see lifeless's specific answer but it seems possible | 02:30 |
| poolie | but, i would think that locking the same object twice should not be a problem- it will just increment the internal counter | 02:31 |
| markh | I looked and failed to find his specific answer too :) | 02:31 |
| poolie | the problem we want to avoid is having two objects pointing to the same file | 02:31 |
| markh | 2 different objects involved IIRC | 02:31 |
| lifeless | markh: it wasn't as detailed as I just gave | 02:31 |
| poolie | if you can do that, there should be no problem with locks being exclusive or not | 02:31 |
| lifeless | the case it occurs for users is when the working tree is two of the coordinates in a merge operation | 02:31 |
| lifeless | one readonly one write, it will self-exclude on windows | 02:31 |
| === kiko is now known as kiko-zzz | ||
| poolie | if this is only happening in tests not in real use this may be a problem of, say | 02:32 |
| poolie | an api that implicitly opens a wt when it should allow the object to be passed in | 02:32 |
| poolie | jml, in the scenario they're just directly assigned to the test object | 02:32 |
| poolie | they're typically strings or valueobjects | 02:32 |
| poolie | if you pass a mutable object then yes, it may cause contamination between tests | 02:33 |
| lifeless | jml: we could deep copy to actively prevent bugs | 02:33 |
| poolie | which would be bad ;-) | 02:33 |
| lifeless | jml: but we've never had mutated objects there to day | 02:33 |
| jml | right. | 02:33 |
| poolie | lifeless, that kinda sounds like an accomodation ;-) | 02:33 |
| jml | I guess you guys use format specifiers and the like. | 02:33 |
| lifeless | poolie: python doesn't have 'const' :) | 02:33 |
| poolie | i mean it's pythonic to have mutable objects and tell people to use them carefully | 02:33 |
| lifeless | poolie: its also slow | 02:33 |
| lifeless | and many other things; we accomodate all the time | 02:34 |
| poolie | lifeless, slow to copy? | 02:34 |
| lifeless | poolie: just slow :> | 02:34 |
| poolie | anyhow there's no guarantee that deep copy would work correctly on arbitrary objects | 02:34 |
| lifeless | actually there is | 02:34 |
| poolie | oh you're agreeing? | 02:34 |
| mwhudson | sockets, for example :) | 02:34 |
| lifeless | there is a deep copy protocol | 02:34 |
| * markh wonders why the merge code can't detect the same tree is being used and not bother taking the second read lock... | 02:34 | |
| jml | so, I'm thinking that I want to do something a lot like what TestScenarioApplier does, except have it take a scenario *factory* | 02:35 |
| lifeless | jml: pass the factory in as the scenario | 02:35 |
| lifeless | jml: ? | 02:35 |
| jml | lifeless: right, that's what I'll do in the short term. | 02:35 |
| lifeless | jml: whats the use case? | 02:35 |
| poolie | jml, for instance, just put a callable as the scenario parameter | 02:35 |
| poolie | or a class | 02:35 |
| poolie | (which is a callable of course) | 02:35 |
| lifeless | we pass in factories all the time | 02:35 |
| jml | poolie: right, that's what I'll do in the short term. | 02:35 |
| poolie | jml, this would be worth documenting though | 02:36 |
| lifeless | so I'm keen to understand the use case that makes you think of this as a short term solution | 02:36 |
| lifeless | rather than the right solution | 02:36 |
| poolie | want to send a one-para patch to the hacking file? | 02:36 |
| jml | poolie: maybe a bit later -- after I've successfully used it. | 02:36 |
| poolie | markh, having two objects and not locking one of them would be risky | 02:36 |
| poolie | also probably futile as the object might implicitly lock itself | 02:37 |
| poolie | however, saying 'oh these should be the same object i'll fix them up' would be, | 02:37 |
| jml | lifeless: it's short term because in the slightly longer term I want to try doing things my way and see if it's better :) | 02:37 |
| lifeless | jml: there are many varied examples in bzrlib; I'd be delighted to help you choose a good one to cult from | 02:37 |
| poolie | um, maybe not optimal but worth looking at | 02:37 |
| poolie | jml, lifeless, i was wondering whether it is really tasteful to have the scenario written into arbitrary test attributes | 02:37 |
| poolie | rather than .scenario | 02:37 |
| lifeless | jml: so we started with a fully general thing that was called per function if I remember correctly | 02:38 |
| poolie | for instance | 02:38 |
| markh | poolie: but if its an oslock, its only purpose is to keep others out isn't it? And as we work correctly when the locks aren't exclusive, I don't see much risk. But I'm sure I'm just blinkered :) | 02:38 |
| lifeless | poolie: I think its tasteful; you can always have a scenario that puts everything on .scenario | 02:38 |
| * jml disagrees | 02:38 | |
| jml | but taste is a matter of... taste. | 02:38 |
| lifeless | jml: which statement do you disagree with ? | 02:39 |
| markh | I can imagine all the decorators failing though... | 02:39 |
| poolie | markh, you might get two in-memory objects that are out of sync with each other | 02:39 |
| lifeless | markh: no, they are exclusive | 02:39 |
| poolie | but, presumably it already has to deal with this on unix | 02:39 |
| jml | lifeless: I disagree that it's tasteful. | 02:39 |
| lifeless | jml: to write to any attribute? | 02:39 |
| markh | yeah - that's what I'm a little lost with still... | 02:39 |
| jml | lifeless: yeah. | 02:39 |
| lifeless | markh: so, on unix they are exclusive *cross process* | 02:40 |
| poolie | markh, btw, today's my last day here, do you want to catch up? | 02:40 |
| lifeless | markh: its a special case that it doesn't exclude the same process | 02:40 |
| poolie | i do have a bunch to do | 02:40 |
| markh | lifeless: right - so in process you could theoretically detect and avoid 2 locks on the same file? | 02:40 |
| lifeless | markh: not locking would allow two bzr processes to stamp on each other on windows *as well* as allowing a single-process to behave as bzr on linux does | 02:40 |
| markh | but I'm only saying not to lock when we already have a write lock | 02:41 |
| lifeless | markh: I guess you could reinstate the global dict we used to have | 02:41 |
| lifeless | markh: but IIRC we took it out cause it caused other bugs | 02:41 |
| markh | but why not just compare paths, and if we already have a write lock on the same path, just don't take the read lock. Could theoretiucally be all detected in do_merge | 02:41 |
| poolie | lifeless, do you agree that the general approach is to try to have one in-memory object corresponding to each real-world or fs object? | 02:42 |
| lifeless | jml: I think forcing the core code to only write to one attribute is not treating callers like adults; and it doesn't stop people having all the issues arbitrary attributes have in micro | 02:42 |
| lifeless | poolie: no, I don't agree with that | 02:42 |
| poolie | ok | 02:42 |
| markh | it would just solve the problem for a single "Merger" object, that that seems the only real use case that its a real problem with | 02:42 |
| lifeless | poolie: I think its good when we do that but aliasing can trivially stop that working, so we need to be correct regardless | 02:42 |
| lifeless | poolie: consider z: and f: mapped to the same SMB drive, for instance. | 02:43 |
| poolie | sure | 02:43 |
| lifeless | jml: I will agree that as a convention having stuff on .scenario is good for documentation and predictability; but thats up a layer in the 'userspace' of the facility | 02:43 |
| lifeless | markh: I think we should just fix the underlying bug and issue a new recommended format for windows | 02:44 |
| jml | lifeless: well, actually, I think that the nicest way would be to call a method on the test. | 02:45 |
| lifeless | jml: to set stuff? | 02:45 |
| jml | lifeless: yes. | 02:45 |
| lifeless | jml: kind of like _setattr_ but different? | 02:45 |
| jml | lifeless: kind of like setScenario(scenario) | 02:45 |
| lifeless | jml: I think that would be great; I also want python unittest compatibility | 02:46 |
| lifeless | jml: but doing a getattr for setScenario first would be fine IMO | 02:46 |
| jml | lifeless: of course, then the way you set attributes would have to match whatever the default implementation of setScenario does. | 02:46 |
| poolie | jml, that seems pretty close to just poking into .scenario_* then letting setUp() run... | 02:47 |
| poolie | lifeless, yeah i was thinking of .scenario* just as a convention not a requirement | 02:48 |
| jml | poolie: well, the difference is that the test decides what to do with the scenario. | 02:48 |
| lifeless | jml: yes, but hopefully both are in the same codebase | 02:48 |
| jml | lifeless: I've got use cases for doing otherwise. | 02:49 |
| lifeless | jml: you're making me guess here | 02:49 |
| poolie | i guess in my experience it's often just storing them | 02:49 |
| poolie | but your cases would be interesting | 02:49 |
| jml | lifeless: bzr plugins | 02:49 |
| jml | lifeless: like bzr-loom | 02:50 |
| poolie | jml, out of curiousity, did addCleanup go from bzrlib to pyunit3k? | 02:50 |
| jml | wait, wrong example | 02:50 |
| jml | poolie: no. | 02:50 |
| markh | lifeless: I'm not sure exactly what the bug is? I got the impression from yesterday that they were *intended* to be exclusive? | 02:50 |
| jml | poolie: I implemented addCleanup using test-driven development for Twisted and then re-implemented it with TDD as a patch to Python | 02:50 |
| jml | poolie: the one in pyunit3k is from the latter. | 02:50 |
| lifeless | markh: WT4 is designed with a built in flaw; its a design bug we need to fix | 02:50 |
| markh | and that would impact the recommended default format for windows? | 02:51 |
| jml | poolie: the addCleanup in bzrlib isn't tested, per se. | 02:51 |
| lifeless | markh: for everyone | 02:51 |
| markh | or you mean we'd end up with a wt5? | 02:51 |
| markh | right | 02:51 |
| poolie | really? | 02:51 |
| lifeless | wt5 | 02:51 |
| jml | poolie: really no tests. | 02:51 |
| lifeless | markh: 'bzr commit' -> opens editor | 02:52 |
| lifeless | in the editor, !bzr diff, or similar | 02:52 |
| lifeless | -> FAIL | 02:52 |
| markh | right - you mean implement your RFC? | 02:52 |
| lifeless | yes | 02:52 |
| markh | gotchya - cool | 02:52 |
| === RAOF_ is now known as RAOF | ||
| markh | which will still leave us with the longer term problem of how to disable the existing tests once this new wt comes out - the old tests aren't going away... | 02:54 |
| jml | poolie: the Twisted one allows cleanups to return Deferreds and ensures they are run in serial, fwiw. | 02:54 |
| markh | disable on windows | 02:54 |
| markh | but that can wait ;) | 02:54 |
| jml | poolie: and as such is way more complex than any other implementation I've seen. | 02:54 |
| poolie | jml, i meant did the idea come from bzrlib or was it independent reinvention | 02:54 |
| jml | poolie: oh, the idea is from bzrlib. | 02:55 |
| lifeless | markh: we'd add a feature | 02:55 |
| lifeless | markh: and requireFeature those tests | 02:55 |
| markh | ahh - nice clue - thanks! | 02:55 |
| jml | poolie: in fact, I don't know of anyone else who's done it apart from bzrlib and myself. | 02:55 |
| lifeless | the feature would be something like | 02:55 |
| lifeless | BrokenInProcessLocksFeature | 02:56 |
| lifeless | jml: I think that bzrlib is one of the drivers of testing facilities in unittest tests in python | 02:56 |
| poolie | let's use a more specific word than 'Broken' | 02:56 |
| lifeless | jml: other than e.g. nose which seems half cool half terminally confused | 02:57 |
| lifeless | poolie: :) | 02:57 |
| lifeless | poolie: I tried to think of one, to represent what linux os locks do | 02:57 |
| lifeless | poolie: but nothing other than 'fucked' and 'broken' came to mind | 02:57 |
| lifeless | so I went polite | 02:57 |
| poolie | <stephane> don't goof off too much | 02:57 |
| poolie | ^^ at me laughing at you | 02:57 |
| markh | :) | 02:57 |
| lifeless | :) | 02:57 |
| jml | lifeless: well... | 02:57 |
| jml | lifeless: Twisted and Zope have both explored new testing territory. | 02:58 |
| poolie | ProcessWideFileLocks | 02:58 |
| jml | lifeless: Zope, for example, has definitively shown that layers are a terrible idea. | 02:58 |
| poolie | jml, congratulations on the user reviews of the code review feature! | 02:58 |
| jml | lifeless: that's progress. | 02:58 |
| poolie | markh, so do you need anything from me before i go? | 02:59 |
| poolie | (at about 5pm today) | 02:59 |
| poolie | it looked like the questions about packaging were fairly well answered? | 02:59 |
| markh | poolie: yeah, thanks. Over that period I ill have binaries available and I'm not sure what I should do with them exactly :) Current plan is to mail the mailing list and host them on that starship server I have access to. Anything else I should do with them while you are gone? | 03:00 |
| poolie | you can put them up as file downloads on launchpad? | 03:01 |
| poolie | s//can't you/ | 03:01 |
| poolie | you might need to join the right team there... | 03:01 |
| markh | yeah - will that give them much visibility? | 03:01 |
| poolie | https://edge.launchpad.net/bzr/+download | 03:01 |
| markh | yeah - that's what I'm thinking - I'm still a total newb with launchpad | 03:02 |
| poolie | and then link them from the /Download page on the main site | 03:02 |
| poolie | do you get an 'add download file' link there? | 03:02 |
| markh | the fact mailing lists were attached to teams is what threw me before | 03:02 |
| lifeless | jml: :) | 03:02 |
| lifeless | jml: I meant positive directions | 03:02 |
| lifeless | jml: we're still on for sunday? | 03:02 |
| poolie | markh, yeah that's one of those possibly too clever ideas | 03:02 |
| jml | lifeless: I thought it was Saturday | 03:02 |
| lifeless | jml: ah yes, it is | 03:02 |
| lifeless | I was thinking with my wow-addict-hat for a second | 03:03 |
| lifeless | jml: btw, can you log in sometime and hit return on the stuff in your mailbox ;) | 03:03 |
| markh | poolie: no "add download file" link | 03:03 |
| jml | lifeless: to which machine? | 03:03 |
| poolie | what's your lp userid? | 03:04 |
| lifeless | caelstraz | 03:04 |
| markh | mhammond | 03:04 |
| poolie | lifeless, jml, i assume you wouldn't object to me adding him to ~bzr? | 03:04 |
| lifeless | not at all | 03:04 |
| lifeless | though perhaps you meant jam & abently there :) | 03:05 |
| jml | lifeless: oh, right. I guess so. | 03:05 |
| poolie | markh, try again? | 03:06 |
| thumper | is there any easy way to check the revno of the public branch? like `bzr revno -d :public`? | 03:07 |
| * thumper waves hands around | 03:07 | |
| spiv | thumper: "bzr revno :public" | 03:08 |
| thumper | spiv: thanks# | 03:08 |
| markh | poolie: awesome, thanks! You now have my permission to enjoy yourself for a couple of weeks on that BMW riding north! :) | 03:09 |
| poolie | :-) | 03:09 |
| jml | spiv: bzr://rhino.local/addCleanup-args | 03:13 |
| thumper | abentley: I don't suppose bzrtools has a command that does the equivalent of "branch X into shared repo, then do a lightweight checkout" ? | 03:14 |
| abentley | thumper: Sounds like cbranch. | 03:14 |
| thumper | abentley: can I tell cbranch to --hardlink from a different working tree though? | 03:14 |
| thumper | abentley: normally I go `bzr cbranch local-a local-b` and that's exactly what I want for that use case | 03:15 |
| abentley | thumper: Yes. --files-from | 03:15 |
| thumper | abentley: but if I want to go `bzr cbranch lp:~a/b/c` that works? | 03:15 |
| abentley | thumper: Yes, you can cbranch from any location that bzr understands. | 03:16 |
| thumper | abentley: you rock! | 03:16 |
| abentley | btw, you need to supply *both* --hardlink and --files-from if you want that. | 03:16 |
| thumper | abentley: gotcha | 03:17 |
| thumper | abentley: I have cbranch aliased to `cbranch --lightweight --hardlink` | 03:17 |
| abentley | Me too. | 03:17 |
| abentley | thumper: If you forget to supply --files-from, you can use "bzr link-tree" to hardlink after the fact. | 03:19 |
| spiv | Hmm, "bzr diff -r submit:" is including the changes in the common ancestor revision in the diff. | 03:19 |
| spiv | That's weird. | 03:19 |
| thumper | abentley: and that converts copies to hard links? | 03:19 |
| abentley | thumper: Yes. | 03:19 |
| thumper | cool | 03:20 |
| thumper | is link-tree in bzrtools or trunk? | 03:20 |
| thumper | s/trunk/core/ | 03:20 |
| lifeless | poolie: there is a squid meetup in sydney while you are away | 03:20 |
| lifeless | poolie: ok if I pop down there for a bit? not sure how much time I want to spend; its monday and tuesday next week | 03:21 |
| spiv | Ah, it's because my mirror of bzr.dev is older than the branch I'm making a diff of. | 03:24 |
| lifeless | beuno: around still? | 03:27 |
| poolie | lifeless, np | 03:34 |
| pickscrape | mwhudson/beuno: ping | 04:14 |
| beuno | lifeless, pong | 04:34 |
| beuno | pickscrape, pong | 04:34 |
| lifeless | beuno: hi | 04:37 |
| beuno | hi lifeless | 04:37 |
| lifeless | beuno: uhm, what was it, oh yeah - does loggerhead have a way to get favicon.ico from a branch ? | 04:37 |
| lifeless | beuno: wondering if I should file a bug for that | 04:37 |
| pickscrape | beuno: hi. I was looking to move the breadcrumbs markup out into a shared place. It looks like metal is what I'm after | 04:38 |
| beuno | lifeless, I've seen your comments on the bug. What do you mean "from a branch"? from the actual tree? | 04:38 |
| beuno | pickscrape, yes, or in macros.pt | 04:38 |
| pickscrape | There is a template there already called 'macros.pt', but it contains a full-HTML macro and it doesn't like it if I try to define any outside of the html element | 04:38 |
| beuno | but that will just make rockstar move them to a separate tempalte later on | 04:38 |
| pickscrape | Ah, he's unifying or something like that isn't he | 04:39 |
| lifeless | beuno: I mean from the branch, so for non-launchpad installs of loggerhead | 04:39 |
| beuno | he's spliting things up so it's more themeable | 04:39 |
| beuno | lifeless, currently LH gets it's favicon statically from it's own dir | 04:40 |
| beuno | you would want to add a favico.ico to each dir of each branch? | 04:40 |
| pickscrape | favicon just gets served from root doesn't it? | 04:41 |
| lifeless | beuno: sure, why not :) | 04:41 |
| lifeless | pickscrape: I think documents can override per-document | 04:41 |
| beuno | pickscrape, I can help you place it in the templates, if you get the python code in place to spit out the content | 04:42 |
| beuno | lifeless, no reason why not, it would make projects more personalized. Although I wonder how many people will go through the trouble of creating one per project/branch | 04:42 |
| pickscrape | beuno: I'm actually keen to learn how this works myself. I've been playing around and have actually got it working from a separate macros template, though I'm sure that's not ideal | 04:43 |
| beuno | lifeless, I'm all for it, just not on the top of the list right now. I agree with you :) | 04:43 |
| lifeless | beuno: well, if it was (say) .favicon.ico, I'd happy put one in most of my projects | 04:43 |
| beuno | pickscrape, separate macros template? embeded in each template? | 04:44 |
| pickscrape | I created a breadcrumbs.pt file in the same location as macros.pt, and also had to add a line to loggerhead/templatefunctions.py to get it to recognise it | 04:45 |
| beuno | pickscrape, that sounds correct :) | 04:45 |
| rockstar | pickscrape, the "unify" was because the branch was started with a different idea then what actually came out of it. :) | 04:46 |
| tacone | favicon can be specified in <head> as well | 04:46 |
| pickscrape | Is that the approach that rockstar will be taking? | 04:46 |
| beuno | pickscrape, yes, that's why it sounds right :) | 04:46 |
| rockstar | Yes, absolutely. | 04:46 |
| rockstar | The idea is that someone might want to put the breadcrumbs somewhere else. | 04:46 |
| pickscrape | Oh sweet. I was concerned that calling it 'breadcrumbs' was being a bit too granular. | 04:46 |
| rockstar | So they should just have a template function that generates the breadcrumbs, and they can call that wherever they like. | 04:47 |
| pickscrape | Yes, that makes sense | 04:47 |
| pickscrape | In that case it doesn't sound like I'll be conflicting with rockstar as much as I was afraid I might be. | 04:48 |
| rockstar | beuno, are you gonna merge my branch before or after 1.6? | 04:48 |
| beuno | rockstar, not at all, ASAP | 04:48 |
| beuno | so, before | 04:48 |
| rockstar | Cool. | 04:49 |
| beuno | anything that's laying around and intersting goes in. I just don't want more features, or it will be like bzr's 1.6 | 04:49 |
| * beuno ducks | 04:49 | |
| rockstar | :) | 04:51 |
| lifeless | beuno: so I should file a bug? | 04:54 |
| beuno | lifeless, haven't you already? Where have you been ping-ponging with poolie about this then? | 04:56 |
| lifeless | bazaar-launchpad, different use case | 04:56 |
| lifeless | almost entirely unrelated in fact :) | 04:57 |
| * beuno looks | 04:58 | |
| beuno | ah, right. I pictured it in my head on how I'd implement it, so I ended up thinking it was on LH :p | 04:58 |
| beuno | lifeless, sure, go ahead | 04:58 |
| pickscrape | night all | 05:00 |
| lifeless | done | 05:00 |
| thumper | beuno, rockstar: I've commented on the review, and I think they should be looked at before merging | 05:00 |
| mwhudson | lifeless: oh, i thought your bug report was about loggerhead too :) | 05:01 |
| beuno | thumper, just saw it and replied. I fully agree with most of it. Does answering by email automagically work? | 05:01 |
| thumper | beuno: it should do :-) | 05:01 |
| beuno | pickscrape, g'night | 05:01 |
| beuno | thumper, it did, yay! Now I like reviews better | 05:01 |
| mwhudson | oh, it was | 05:01 |
| thumper | beuno: :-) | 05:02 |
| thumper | beuno: you can thank abentley | 05:02 |
| * beuno thanks abentley | 05:02 | |
| abentley | beuno: just doing my job | 05:03 |
| beuno | abentley, still worth thanking you :) | 05:03 |
| beuno | hm, LP's sends me back the email I sent as a review | 05:06 |
| * beuno takes back 1/8th of his thank you from abentley | 05:06 | |
| abentley | beuno: Mailing lists generally do that. | 05:07 |
| beuno | abentley, isn't it disabled on most of em? | 05:07 |
| lifeless | beuno: no | 05:08 |
| * beuno can't think of any lists he's on that work that way | 05:08 | |
| abentley | bazaar@lists.canonical.com, bzr-gtk@lists.canonical.com | 05:09 |
| beuno | the bzr ml doesn't send me back my own emails AFAIK | 05:10 |
| abentley | beuno: It sends me mine. | 05:10 |
| mwhudson | it's a per-user option in mailman | 05:10 |
| spiv | Mailman lists let subscribers opt out of having their own messages sent back to them. | 05:10 |
| beuno | (I'm not actually complaining anymore, just truthfully curious now) | 05:10 |
| spiv | By default those lists will send them back, I believe. | 05:10 |
| abentley | beuno: I find it essential to have the mail sent back to me so that I can read mail threads I've participated it. | 05:11 |
| abentley | participated *in* | 05:11 |
| beuno | hm, I wonder if it's gmail "doing stuff for me" then | 05:11 |
| lifeless | abentley: speaking of this | 05:13 |
| lifeless | abentley: I find I miss reviews when folk use BB's web interface because it doesn't mail me | 05:13 |
| lifeless | abentley: how do you feel about reimplementing mailmain in turbogears/ | 05:13 |
| lifeless | ? | 05:14 |
| beuno | ROFL | 05:14 |
| lifeless | beuno: gmail hides N>1 instances of a mail with the same id | 05:14 |
| abentley | You miss reviews because they aren't addressed to you personally? | 05:15 |
| lifeless | yes | 05:15 |
| beuno | lifeless, ah, ok. So I've been protected from reality up to today. Why doesn't this apply to LP then? | 05:15 |
| lifeless | I send in a patch, someone reviews on the web, I notice a few days later when I'm doing a list-scan or BB web UI check | 05:15 |
| AfC | "I've been protected from reality". Heh. I'm going to steal that. | 05:15 |
| lifeless | beuno: LP sends its mails with a different id | 05:15 |
| lifeless | beuno: rather than as a bounce | 05:15 |
| abentley | lifeless: I am too busy reimplementing Mailman in launchpad to reimplement it in TurboGears :-) | 05:16 |
| abentley | beuno: This is arguably a bug. | 05:16 |
| beuno | abentley, yeah, it at least felt odd to my normal workflow. Mind if I file it then? | 05:17 |
| abentley | Not at all. It should have had the same id. | 05:17 |
| lifeless | abentley: is it actually the same content? | 05:17 |
| abentley | lifeless: More or less. May have a header prepended or a footer appended. | 05:18 |
| lifeless | then I agree | 05:18 |
| lifeless | FWTW | 05:19 |
| beuno | \o/ | 05:19 |
| lifeless | thumper: hi | 05:20 |
| beuno | abentley, I found bug #240564 | 05:21 |
| lifeless | I keep asking this | 05:21 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/205416/+addbranch | 05:21 |
| lifeless | can we make the whiteboard be shorter so I don't have to scroll on that page? | 05:21 |
| beuno | fixing that would fix this too, wouldn't it? | 05:21 |
| beuno | https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/240564 | 05:21 |
| lifeless | thumper: if you say yes I'll file a bug | 05:21 |
| lifeless | thumper: also, at least for me, the common case is 'fix available' not 'work in progress', so could we change the default too ? | 05:21 |
| thumper | lifeless: please file a bug, and assign it to rockstar | 05:23 |
| thumper | lifeless: I know you've been asking, but I've been implementing something else you asked for ;-) | 05:23 |
| rockstar | Yes please. Assign all bugs to me. | 05:23 |
| rockstar | :) | 05:23 |
| thumper | rockstar: something for you to do :) | 05:23 |
| rockstar | thumper, job security :) | 05:24 |
| thumper | :) | 05:24 |
| mwhudson | watch out, at current rates our team will run out of work ... in 2120 or so | 05:25 |
| lifeless | thumper: rockstar whats your lp id ? | 05:27 |
| rockstar | rockstar | 05:27 |
| rockstar | :) | 05:27 |
| rockstar | mwhudson, after my talk on LP and bzr tonight, people were telling me all about the bugs they've discovered, as if I was the bug tracker myself. :) | 05:28 |
| mwhudson | yeah, people do that | 05:28 |
| beuno | abentley, so, still file a bug inspite of https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/240564 ? | 05:33 |
| beuno | it's the last thing I'm doing before *really* going to bed | 05:33 |
| abentley | beuno: Yes. This bug is "The message id isn't being preserved when handling incoming mail" | 05:34 |
| abentley | 240564 is "Only code review messages are threaded, not other messages about the merge proposal". | 05:35 |
| beuno | abentley, thanks, filed as #257494 | 05:36 |
| beuno | I'm really off now, g'night everybody | 05:37 |
| abentley | beuno: g'night. | 05:38 |
| lifeless | gnight beuno | 05:39 |
| Peng_ | This is late, but good night. | 05:44 |
| abentley | lifeless: If Bundle Buggy CC'ed the submitter, would that stop you from missing reviews? | 05:49 |
| lifeless | abentley: yes indeed | 05:53 |
| abentley | lifeless: I've got Mailman configured not to mail me duplicates. So I think if it sent a message to bazaar@lists.canonical.com that was cc'ed to me, Mailman would not forward it to me. | 05:55 |
| abentley | That would mean we've covered both cases without having to introduce any per-user settings on BB. | 05:56 |
| lifeless | abentley: cool | 06:40 |
| lifeless | spiv: bb:tweak on the testing docs btw | 06:45 |
| lifeless | spiv: I think I forgot to say | 06:45 |
| spiv | lifeless: oh cool, thanks | 06:45 |
| lifeless | spiv: | 07:08 |
| lifeless | if I could ask for a review, my InterTree + remove tweaks would be a lovely pair to do | 07:08 |
| spiv | lifeless: I'll take a look. | 07:10 |
| poolie | lifeless: hm this might have been faster if i'd re-read your rfc before we talked for so long | 07:12 |
| poolie | it's good | 07:12 |
| lifeless | poolie: :) | 07:12 |
| lifeless | poolie: thats good to hear | 07:13 |
| poolie | hm | 07:21 |
| poolie | so it's basically like being split by directory, except not necessarily by directory | 07:21 |
| poolie | i'm not sure if explaining that way is going to cause more or less confusion | 07:22 |
| lifeless | split by directory achieves some of the goals | 07:22 |
| lifeless | but conceptually its what a lot of people reach for first | 07:22 |
| poolie | right | 07:22 |
| lifeless | I think its important that we explain why that isn't sufficient; and also why its good so that we can use the good bits | 07:24 |
| lifeless | the good bits are having a canonical form, being updatable in < tree | 07:26 |
| lifeless | the bits that are not sufficient are being == dir size, and pathological cases have such a strong habit of turning up | 07:28 |
| lifeless | (also not mapping fileids -> paths at all well) | 07:29 |
| poolie | that last one may be a challenge for many designs | 07:29 |
| lifeless | if its too hard its too hard | 07:30 |
| lifeless | but trivially consider three things | 07:30 |
| lifeless | a path->id index | 07:30 |
| lifeless | a id->path index | 07:30 |
| lifeless | content | 07:31 |
| poolie | sure | 07:32 |
| lifeless | making the indices outside the core data is possiblty doable | 07:33 |
| lifeless | and another thing to consider | 07:33 |
| lifeless | if we put them outside and use a parallel design to implement the index, it might make the 'core' smaller but is it simpler | 07:37 |
| lifeless | right now we have no path<->id indices, instead we derive them on th efly | 07:39 |
| lifeless | we could do that too | 07:40 |
| lifeless | as long as there was an index on (say) basename<->fileid, and fileid->content | 07:40 |
| lifeless | then path-> content is 'basename) -> fileid set, repeat lookup on fileid->content until a parent mismatches | 07:46 |
| poolie | hm | 07:56 |
| poolie | i do feel very excited about trying to write such a thing | 07:57 |
| poolie | :/ | 07:57 |
| lifeless | :) | 07:57 |
| lifeless | thats a good sign | 07:57 |
| lifeless | it indicates the design sounds attractive | 07:57 |
| poolie | hm | 08:13 |
| poolie | i want to talk more about how to prototype it but really should not | 08:13 |
| lifeless | :> | 08:14 |
| lifeless | thanks for the feedbackm its was good | 08:16 |
| lifeless | I have replied | 08:16 |
| === mark1 is now known as markh | ||
| poolie | i'd be inclined to start by prototyping something that takes an in-memory inventory and writes it out in a new form | 08:16 |
| lifeless | yes, that would give you a canonical form | 08:16 |
| lifeless | the converter has to do that anyhow :P | 08:17 |
| poolie | sue | 08:19 |
| poolie | sure* | 08:19 |
| poolie | i mean that might be an interesting place to start | 08:19 |
| lifeless | I am inclined to start by crisping-up the interfaces for diff etc | 08:19 |
| lifeless | so that we pass inventory deltas around more | 08:19 |
| lifeless | rather than upcasting dirstate to an inventory | 08:20 |
| lifeless | so diff -r -3 internally becomes | 08:20 |
| lifeless | a call to diff -3..-1 updated by -1..current: | 08:20 |
| lifeless | poolie: if you do want to chat, I am around for 30 more minutes, raid is at 6 | 08:23 |
| poolie | i have some more mail to send and then need to clean up here | 08:23 |
| poolie | sadly | 08:23 |
| poolie | i kind of wish i was disconnecting with a laptop and less interruptions | 08:23 |
| lifeless | heh | 08:24 |
| lifeless | would be less of a holiday wouldn't it :) | 08:28 |
| robsta | hi | 09:11 |
| robsta | is it possible to push a sequence of bzr commits to an svn repo as a single commit? | 09:12 |
| james_w | robsta: hi, it's not as far as I know, you need to do a squash merge first. | 10:02 |
| lifeless | robsta: do you want to discard the history, or to make it look like a single merge? | 10:04 |
| robsta | make it look like a single commit in svn | 10:05 |
| lifeless | robsta: bzr checkout svn:/// fo | 10:10 |
| lifeless | cd fo | 10:10 |
| lifeless | bzr merge <your branch> | 10:10 |
| lifeless | bzr commit | 10:10 |
| lifeless | that will result in a single commit to svn | 10:10 |
| lifeless | you'll want the latest bzr-svn which has a raft of bugfixes | 10:11 |
| robsta | ok, so i need two branches | 10:11 |
| lifeless | jelmer announced it monday or something | 10:11 |
| robsta | fair enough | 10:11 |
| * robsta wondering how to best leverage the combination of gnome's svn and bzr-playground | 10:14 | |
| lifeless | spiv: ping | 10:18 |
| rjek | Incase it's not been reported before; http://rafb.net/p/cqMCzd70.html | 10:51 |
| rjek | (bzr explosion when doing bzr vis with no DISPLAY on 1.3.1) | 10:51 |
| lifeless | fun | 10:52 |
| lifeless | please file a bug? | 10:52 |
| rjek | Sorry, I don't have an account on Launchpad. | 10:52 |
| lifeless | oh, ok | 10:53 |
| lifeless | uhm, perhaps a mail to the bzr-gtk list? | 10:53 |
| lifeless | you don't need to subscribe, moderator can let it through | 10:53 |
| rjek | Right, OK. I'll do that. | 10:53 |
| rjek | Do you happen to know its address, or an URL of a page that describes it? | 10:54 |
| lifeless | http://bazaar-vcs.org/bzr-gtk | 10:54 |
| rjek | Ta. | 10:54 |
| rjek | sent! | 10:56 |
| rjek | Thanks. | 10:56 |
| Peng_ | BB down? | 12:04 |
| Peng_ | Oh, good, just slow. | 12:08 |
| === AnMaster_ is now known as AnMaster | ||
| markh | I think I'm still missing something conceptually to do with merging. Let's say i have 3 branches, 'bzr.dev', and 2 'work' branches 'bzr.1' and 'bzr.2'. I periodically update bzr.dev then pull from 'bzr.dev' into 'bzr.1' - but in the meantime I also make a number of changes in bzr.2, then 'bzr merge' them into bzr.1 and commit them (into bzr.1). When a do 'bzr log' of bzr.1, all I see is a single 'merge' commit, and not the individual comm | 12:57 |
| james_w | markh: even with "bzr log --long" (the default, but you may have it aliased)? | 12:59 |
| markh | james_w: yeah | 13:00 |
| james_w | and I assume you didn't do "bzr revert --forget-merges" at any point? | 13:01 |
| james_w | and the merge wasn't a cherry pick? | 13:01 |
| james_w | i.e. it was just "bzr merge ../bzr.2" not "bzr merge -rx..y ../bzr.2" ? | 13:01 |
| markh | actually, when I first started looking at this, the initial merges were '-r x..y' - but even then I'd expect to see the logs for r..y? I'm experimenting now with trying to stitch 2 related branches together without a '-r' though... | 13:04 |
| === kiko-zzz is now known as kiko | ||
| james_w | if you use "-rx..y" then it's a cherry pick, and so all of the commits will be collapsed | 13:04 |
| markh | (for x..y) | 13:04 |
| james_w | -ry or no -r won't do that | 13:04 |
| james_w | could you pastebin a transcript showing what you did, and the resulting log? | 13:05 |
| markh | this is all kinda "post-mortem" - I do need to try some controlled experiments (or find clear docs :) | 13:07 |
| markh | yeah, merge without -r does what I expect. So maybe I'm confused about how to make 2 branches "re-converge", so a simple 'bzr merge' keeps them up to date even when they previously diverged. IIUC, 'bzr pull --overwrite' will lose history too. I'm still too confused to phrase a reasonable question though :-S | 13:24 |
| james_w | yeah, pull --overwrite is the wrong thing | 13:26 |
| james_w | if you "bzr merge" one way you can "bzr pull" the other way afterwards, then the branches should be mirrors | 13:26 |
| james_w | if you run "bzr pull" and it succeeds then the two branches are mirrors | 13:26 |
| james_w | "bzr merge" allows you to bring in the changes from another branch regardless of whether a pull would succeed | 13:27 |
| markh | but once I've done a merge, how do I then get a pull to work again in the future once things are back together? | 13:30 |
| markh | eg, I checked in locally, then sent a bundle which was merged to bzr.dev - but in the meantime, I've had to "bzr merge" from bzr.dev. But now it was merged upstream, what do I do? | 13:30 |
| markh | start a new branch? | 13:30 |
| markh | (but in the meantime I've also merged various other branches in - although everything in bzr.dev is now in my branch) | 13:31 |
| markh | eg, I've 3 outstanding merge requests with bundle-buggy - all these are already in my branch that I'm otherwise keeping up-to-date with bzr.dev. hence my general confusion :) | 13:32 |
| awilkins | Here's a thing ; the smart server requires the dumb server to work | 13:34 |
| awilkins | On modern webserver ; fine, on IIS 6 ; annoying | 13:34 |
| awilkins | How much work would it be to get the smart server to just serve the files that normally come from the dumb server? | 13:35 |
| Peng_ | The smart server already provided VFS access, so I think it should be *possible*. | 13:36 |
| Peng_ | The ideal solution is for the smart server to do everything through RPCs. | 13:36 |
| awilkins | IIS7 works fine | 13:36 |
| awilkins | IIS7 has a way of catching /smart links though | 13:36 |
| awilkins | IIS6 only likes directing things with dotted file extensions to ISAPI modules though | 13:37 |
| markh | yeah - merging into a new tree seems to be much closer to what I expect. | 13:41 |
| markh | it avoids the need to cherry pick. I think trying to stick to an initial "base tree" that has diverged from public branch is the problem | 13:41 |
| markh | (and it seems I also get to learn about "criss-cross merging" :) | 13:43 |
| james_w | markh: if you are merging multiple things in to a branch, including bzr.dev then you won't be able to resynchronise to bzr.dev, but you can keep merging it | 13:43 |
| markh | i've got myself into the state where the only merge that works is to cherry-pick - which collapses the merges as we mentioned. | 13:46 |
| james_w | hmm, I'm not sure why that would happen | 13:46 |
| markh | I think I'm looking for the "--oh-yeah-i-know-i-merged-something-silly-before-but-please-just-reconcile-things" option ;) | 13:47 |
| james_w | heh :-) | 13:47 |
| james_w | does the command say that you are not allowed to do it, or are you hitting an error? | 13:47 |
| james_w | the only way I know of to prevent merge working is to have no common ancestor, which shouldn't be the case here | 13:48 |
| markh | it actually just ended up merging more than I wanted. things got very confusing when I ended with with both 1.6 and .dev branches | 13:48 |
| james_w | hmm, interesting | 13:49 |
| markh | so I've got patches I'm submitting against bzr.dev, but still applying locally to a 1.6 based branch | 13:49 |
| markh | starting with a clean, new branch up the upstream, then merging in the various ".work" branches seems to be working fine. | 13:50 |
| markh | I think I just got myself working on the "rhs" of a branch, not the left. | 13:50 |
| markh | (or something like that :) | 13:50 |
| markh | s/branch up the upstream/branch *of* the upstream/ | 13:50 |
| markh | I've now got 6 branches based, at some stage in the past, on bzr.dev | 13:51 |
| markh | each with their own changes, each less or more important | 13:52 |
| markh | so each now targetting either .dev or both .dev and 16 | 13:52 |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| Toranin | How do you get a proper log of bzr selftest results? Piping to tee seems to truncate the test names to 80 characters wide, which is not really useful. | 15:04 |
| jam | markh: I might be able to add a bit more to the locking discussion if you are around | 15:06 |
| epsy | hi, i've just filed a bug, and i'm not sure what priority to give it | 15:16 |
| epsy | it affects storage(dirstate), blocks me from using the repository, but is something that could only happen in a very specific setup | 15:17 |
| epsy | well, i think it could only happen in a very specific setup, that is | 15:17 |
| james_w | epsy: I'll give it a priority if I triage it | 15:18 |
| epsy | ok | 15:18 |
| james_w | epsy: drop the number here and I can do it now | 15:18 |
| epsy | https://bugs.launchpad.net/bzr/+bug/257599 | 15:18 |
| ubottu | Launchpad bug 257599 in bzr "exceptions.AssertionError: no parent entry" [Undecided,New] | 15:18 |
| epsy | heh, nice | 15:18 |
| james_w | Toranin: are you sure it's not what you are using to view the log that is truncating? | 15:19 |
| james_w | epsy: that's a dupe I think, let me find it | 15:19 |
| Toranin | james_w: fairly sure but I'll try it again -- I'm just doing (more or less) bzr selftest -v | tee testlog | 15:20 |
| epsy | was the other report resolved? | 15:20 |
| james_w | epsy: yeah, it will be fixed in 1.6 | 15:20 |
| epsy | is there any way i can fix my repo or should i trash it? | 15:20 |
| Toranin | output looks like: | 15:20 |
| Toranin | running 14456 tests... | 15:20 |
| Toranin | ...hon2.5/site-packages/bzrlib/doc/api/branch.txt) OK 1294ms | 15:20 |
| james_w | epsy: there's a way to fix it | 15:22 |
| epsy | phew :) | 15:22 |
| james_w | bug 150438 | 15:23 |
| ubottu | Launchpad bug 150438 in bzr "corrupt inventory deltas are not detected by dirstate" [High,Fix released] https://launchpad.net/bugs/150438 | 15:23 |
| Toranin | "COLUMNS=$COLUMNS bzr selftest -v | tee testlog" <-- this widens it out to my terminal width in the log at least. 218 ought to be enough for most test names, I think | 15:23 |
| james_w | epsy: I think it's "mkdir dir; bzr add dir; bzr st; bzr rm dir" | 15:23 |
| james_w | where "dir" is the directory that was removed that it is complaining about | 15:24 |
| epsy | the way to reproduce it or the way to fix it? | 15:24 |
| james_w | the way to fix it | 15:24 |
| epsy | ok | 15:24 |
| epsy | in my case, it's images/avatars/ that i have to add again, right? | 15:26 |
| epsy | Great, it works! thank you very much :) | 15:29 |
| james_w | no problem | 15:39 |
| === kiko is now known as kiko-phone | ||
| jonnydee | lifeless: Just wanted to let you know it seems like you have found a bugfix for https://bugs.launchpad.net/bzr/+bug/255656 :) | 15:58 |
| ubottu | Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] | 15:58 |
| jonnydee | Thank you very very much!!!! | 15:58 |
| === kiko-phone is now known as kiko | ||
| jam | beuno: ping | 16:29 |
| beuno | jam, pong | 16:29 |
| jam | beuno: were you the one that helped me make deb releases? | 16:29 |
| jam | markh: ping | 16:31 |
| beuno | jam, yeap. You ready to release? | 16:31 |
| jam | Not quite yet, but I just wanted you on hand because it makes my life easier :) | 16:31 |
| jam | I'll *probably* do a 1.6rc2 today if at all possible | 16:31 |
| * Peng_ predicts 1.6rc7 will be released on October 24. | 16:33 | |
| jam | Peng_: :) Martin is gone so I have release powers now | 16:33 |
| jam | And I'm planning on forcing it out the door. | 16:33 |
| Peng_ | I'll believe it when I see it. :P | 16:33 |
| pickscrape | Wasn't this a long release in order to get something in for the gnome project? Was it successful? | 16:33 |
| Peng_ | Are you sure you don't want to wait for groupcompress to be merged? | 16:34 |
| * Peng_ hides. | 16:34 | |
| jam | :) | 16:34 |
| beuno | jam, I'm here for the next 8 hours or so :) probably more | 16:34 |
| cody-somerville | beuno, :-) | 16:34 |
| jam | anyone know what markh's hours are? He seems to be only online late at night or early morning CST time, which seems a bit odd for someone in the US | 16:34 |
| Peng_ | jam: I'm in the U.S. | 16:35 |
| Peng_ | Maybe he's just crazy like me. | 16:35 |
| jam | Peng_: you're online late morning :) | 16:35 |
| Peng_ | Yeah, my schedule is slipping. | 16:35 |
| beuno | jam, isn't he in australia? | 16:35 |
| james_w | yeah, that's what I thought | 16:36 |
| jam | Well, according to this: http://www.swfwmd.state.fl.us/about/staff/hammond.html he is in Florida (yes I know that's not him :) | 16:36 |
| jam | It was never clear to me where he lived, you could be completely right. | 16:37 |
| jam | great, on non win32 WindowsError isn't defined, so you can't just blindly put it in your exception handler... :( | 16:38 |
| jam | ah, but WindowsError is a subclass of OSError | 16:39 |
| beuno | jam, his LP page says australia: https://edge.launchpad.net/~mhammond | 16:40 |
| LarstiQ | jam: he's in .au | 16:51 |
| jam | LarstiQ: you know, for how active you are in #bzr, I'm surprised I don't see you at all on the mailing list :) | 16:52 |
| LarstiQ | jam: that's scheduled for september | 16:54 |
| LarstiQ | jam: I have been reading some mail again for starters. | 16:54 |
| jam | what's in Sept? You start school again ? | 16:54 |
| LarstiQ | stop school actually. | 16:54 |
| jam | abentley: ping | 17:19 |
| abentley | jam: pong | 17:19 |
| jam | abentley: In the interests of getting 1.6rc2 out today, I want to make sure I've evaluated everything that people want to land | 17:20 |
| jam | And I'd like a bit more info why your patch is necessary for 1.6 | 17:20 |
| abentley | jam: It fixes readability of "info" for branches in the new formats. | 17:21 |
| jam | well, I'm getting something even weirder here | 17:22 |
| jam | using bzr.dev | 17:22 |
| jam | I get a traceback with | 17:22 |
| jam | bzrlib.errors.UnknownFormatError: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n' | 17:22 |
| jam | though that might be my 'nick' script | 17:23 |
| abentley | jam: I can't reproduce that with bzr.dev | 17:24 |
| jam | abentley: And this looks perfectly readable: http://rafb.net/p/Or1iue87.html | 17:24 |
| jam | The indentation is a little odd, I guess | 17:25 |
| jam | but not unreadable | 17:25 |
| abentley | jam: It gets away with it because it comes last. If both branch and working tree formats were multi-line descriptions, it would be very hard to parse. | 17:27 |
| abentley | But it's always been a single line in the past, and I believe that's what people want and expect. | 17:27 |
| jam | true, though arguably info-v should be updated to support multiple lines. | 17:27 |
| jam | I kind of like the more verbose description | 17:28 |
| jam | I'm willing to merge what you have | 17:28 |
| jam | I'm just not sure I agree 100% | 17:28 |
| abentley | jam: It's a very poor answer to the question "What is my repository format?" | 17:28 |
| abentley | jam: additionally, the docstring for the RichRoot variant is flat-out wrong. | 17:29 |
| jam | hmm... I find it a pretty good response | 17:29 |
| jam | I agree that RichRoot is just wrong. | 17:29 |
| abentley | jam: Not in my opinion. It's not the reply I'd want on IRC, or when discussing things in email. | 17:30 |
| jam | abentley: well *I* would want "RepositoryFormatKnitPack5" as that fully encapsulates it ,and is short for IRC, etc. | 17:31 |
| jam | I don't think that is suitable for "bzr info" though | 17:31 |
| jam | so I'm not sure if that is the best test | 17:31 |
| abentley | It's a fine reply to "What does my repository format support, etc" | 17:31 |
| abentley | jam: So how can people find out what their repo format is, if not through "info"? | 17:32 |
| jam | abentley: well plain "bzr info" gives: Shared repository with trees (format: pack-0.92) | 17:32 |
| jam | If we were going to do it *right* | 17:32 |
| jam | then we should be using the short names for them. | 17:32 |
| jam | for some definition of "right" because of the permutation problem | 17:33 |
| abentley | It shouldn't say pack-0.92 | 17:33 |
| jam | abentley: that was a different repo | 17:33 |
| jam | Shared repository with trees (format: 1.6) | 17:33 |
| jam | If you prefer | 17:33 |
| jam | I'm really tending on the "get 1.6 released" already and postponing everything that isn't an actual regression. | 17:34 |
| jam | But if you feel strongly, I'll merge it | 17:34 |
| abentley | Many are unhappy with using the short strings. | 17:35 |
| abentley | Especially when you're talking about a shared repo or checkout where it could be one of many. | 17:35 |
| abentley | The current docstrings are unacceptable to me because they don't say "RepositoryFormatKnitPack5" or something like that anywhere, and because they make false statements. | 17:36 |
| abentley | I don't insist on fixing the multi-line thing for 1.6. | 17:37 |
| abentley | Though of course, the simplest thing to do would be to apply my patch. | 17:39 |
| jam | abentley: so you *do* feel like the strings need to be updated for 1.6 | 17:39 |
| jam | I'll probably just merge your patch | 17:39 |
| jam | you know, I wish Thunderbird wouldn't include BB emails when I search by your name | 17:40 |
| jam | I think it is because bb's email address includes yourname.com | 17:41 |
| abentley | Yeah. Sorry. | 17:41 |
| jam | If I use your full name with a space, then BB is filtered out | 17:41 |
| awilkins | jam: Would your proposed consideration of kind == 'file' to kind == None as a content change mean that the deltetion of a file would show up as a revision it participated in, in the log (desirable, IMHO) | 17:44 |
| jam | awilkins: something else entirely | 17:45 |
| jam | bzr log -v already does that | 17:45 |
| jam | Just that bzr log -v file doesn't IIRC | 17:45 |
| awilkins | Someone was asking about it last week and this reminded me | 17:46 |
| jam | abentley: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48A307FB.7060905%40arbash-meinel.com%3E | 17:46 |
| jam | I think it is the last patch which is specifically blocking 1.6rc2 | 17:46 |
| jam | Though you may not be comfortable reviewing it | 17:46 |
| abentley | jam: I don't think I have time today. | 17:47 |
| jam | It's rather small | 17:47 |
| jam | just win32 specific | 17:47 |
| awilkins | He wanted to know which revision a file(not in present inventory) was deleted in ; it's easy enough to extend bzr log to support --file-id, but then the log alas, doesn't show the deletion :-( | 17:48 |
| * awilkins would review it if his vote carried any weight | 17:48 | |
| jam | awilkins: I'm well versed in the problem, and know why it is an issue | 17:48 |
| jam | awilkins: all reviewers carry some weight | 17:48 |
| awilkins | But if I voite, BB ignoreds me, right ? | 17:48 |
| jam | BB probably does | 17:48 |
| jam | That doesn't mean *I* would :) | 17:48 |
| abentley | jam: I'm not supposed to be working on bzr during paid hours, and I'm in the middle of reviewing other stuff, and I have plans this evening. | 17:49 |
| jam | I'm surprised you aren't supposed to do any bzr work, given that you are in launchpad-bazaar, but sure | 17:49 |
| jam | I mean, you *did* just submit a patch because it effected LP :) | 17:50 |
| jam | We just don't have any other reviewers in this TZ | 17:50 |
| jam | Unless jelmer is awake ... | 17:50 |
| awilkins | I can work on it during paid hours (with a clean conscience) as long as it benefits my project | 17:50 |
| awilkins | I can work on it (with a dirty conscience) anyway :-P | 17:50 |
| abentley | jam: It doesn't affect LP. I've already overridden those strings for LP. | 17:51 |
| jam | awilkins: :) | 17:52 |
| jam | abentley: so I should make the request in #bzrlp, right ? :) | 17:52 |
| abentley | jam: I don't think anyone there is awake and in my chain-of-command. | 17:54 |
| jam | no, I just mean then it appears as a bzrlp request | 17:55 |
| jam | We've taken longer discussing it than it would have taken you to review it | 17:55 |
| jam | Don't worry about me, I'll find someone else | 17:55 |
| awilkins | Pulling patches via URLs is very convenient | 17:57 |
| jam | awilkins: I agree | 18:00 |
| awilkins | jam: Well, it makes the test pass ; but I see a few other places where ENOTDIR is used | 18:00 |
| jam | awilkins: sure, I'm just looking for a *regression* fix | 18:00 |
| jam | not a full solution to all problems | 18:00 |
| jam | For a release, I want it to not be worse than it was in the last release. | 18:01 |
| jam | And we *really* need to get a release out the door | 18:01 |
| awilkins | I suppose it does lower the footprint | 18:01 |
| awilkins | jam: I agree about the release, building my own is a PITA (and worrying, if I've patched it off the main line) | 18:04 |
| awilkins | This will fix my last issue with 1.6 (all my other patches are in) | 18:04 |
| jam | beuno: ping | 18:07 |
| jonnydee | jam: hi, regarding the bug https://bugs.launchpad.net/bzr/+bug/255656 -- what do you think? will my nomination for release 1.6 be considered? | 18:08 |
| ubottu | Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] | 18:08 |
| beuno | jam, pong | 18:08 |
| jam | jonnydee: well, the fix robert proposed isn't really an official fix, more of a workaround to see what the bug was | 18:08 |
| jam | as such, I'm hesitant to make it into 1.6 without a real fix and test (as I'm trying to get 1.6 pushed out the door) | 18:09 |
| jam | I would be surprised if it didn't land in 1.7, though | 18:09 |
| jonnydee | so I will have to copy with this bug in release 1.6, too? | 18:09 |
| jam | jonnydee: 1.5 performs the same, right? | 18:09 |
| jonnydee | well, I'm not sure... | 18:10 |
| jonnydee | sorry, I meant "cope" | 18:10 |
| jam | jonnydee: I'm really trying to keep changes to 1.6 as regressions only | 18:10 |
| jam | we have slipped 3 months because of delays | 18:11 |
| jonnydee | yes, I understand... | 18:11 |
| jam | when we get back into a regular release | 18:11 |
| jam | 1.7 will come out within a couple weeks | 18:11 |
| jam | so no big "must get it right now" issues | 18:11 |
| jam | jonnydee: so... if it is a *regression* you have a chance otherwise, not really | 18:11 |
| jam | beuno: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48A307FB.7060905%40arbash-meinel.com%3E | 18:11 |
| jam | I figure 2 non-core people looking over the code for obvious flaws is enough for me to merge it | 18:12 |
| jam | and then I'll be ready for 1.6rc2 | 18:12 |
| jonnydee | how can I support to get it to a *regression* | 18:12 |
| jam | jonnydee: If 1.5 *works* and 1.6 *doesn't* that is a regression | 18:13 |
| beuno | jam, sure, looking | 18:13 |
| jonnydee | ok, I see | 18:13 |
| jam | jonnydee: which is why I'm trying to get the "rm" patch merged | 18:13 |
| jam | and not the 10 other things that are pending review in BB that I've written :) | 18:14 |
| === mw is now known as mw|brb | ||
| Toranin | jam: FWIW, the patch looks sane to me, presuming your comments on Python's behavior are correct | 18:16 |
| Toranin | however, I've not read or worked on the context code at all | 18:16 |
| jam | Toranin: thanks, we have some strong hints that it is correct because we've been using a variant in workingtree_4.py | 18:17 |
| Toranin | my only concern would be that you strip the comment explaining WHY the exception is okay in the first use case | 18:18 |
| awilkins | jam: I't OK on Python25 but for a (related/unrelated?) reason I am running into an error on Python24 | 18:18 |
| jam | awilkins: what specific test are you running? | 18:19 |
| awilkins | jam: Is pywin32 supposed to be a cast-iron requirement for bzr on windows? | 18:19 |
| jonnydee | anyway, thanks for your help! :) You do great work!!! :) | 18:19 |
| awilkins | jam: I'm running test_switch, which is where I found it at first | 18:19 |
| jam | awilkins: are you python extensions rebuilt? | 18:20 |
| awilkins | jam: nope, hold on | 18:20 |
| jam | I get: NotImplementedError: We must have one of fcntl, pywin32, or ctypes available to support OS locking. | 18:20 |
| awilkins | awilkins: But I think it's because my Python24 lacks pywin32 | 18:20 |
| jam | but that just means I need to install pywin32 | 18:20 |
| jam | which sounds the same as yours :) | 18:20 |
| beuno | jam, sent my thumbs up to the list | 18:20 |
| jam | beuno: thanks | 18:20 |
| awilkins | Does gmane work well for list posting? | 18:22 |
| * awilkins has just used it to post approval | 18:22 | |
| awilkins | jam: That means that pywin32 is required to run the test suite? | 18:23 |
| jam | awilkins: We either need ctypes or pywin32 | 18:23 |
| jam | Python2.5 bundles ctypes directly | 18:23 |
| awilkins | Ah, yes | 18:23 |
| awilkins | Hey, Python 2.6 !? | 18:25 |
| jam | beuno: ok, well, I'll merge this patch, and one more to get the version strings to show 1.6rc2 | 18:25 |
| jam | And then I'll be ready for some packaging. | 18:25 |
| jam | This won't be 1.6 final, so that people can respond to my comments in the 1.6 thread | 18:26 |
| beuno | sounds good | 18:26 |
| === kiko is now known as kiko-fud | ||
| === mark1 is now known as markh | ||
| dato | heh, persona non gratis | 18:31 |
| awilkins | Bugger, I meant "grata" didn't I.... | 18:31 |
| dato | :) | 18:33 |
| pickscrape | Interestingly, bzr 1.6_rc1 is already available in the bzr gentoo overlay :) | 18:33 |
| LarstiQ | jam: unless it's python2.5 on win64 of course, sigh | 18:34 |
| pickscrape | Gah, ignore me. You're talking about rc2 aren't you. :) | 18:34 |
| jam | pickscrape: yep | 18:35 |
| jam | LarstiQ: yeah, but we probably have a raft of issues with p2.5 on win64 anyway | 18:35 |
| === mw|brb is now known as mw | ||
| jam | And nobody has stepped up to complain yet :) | 18:35 |
| pickscrape | Is anyone aware of a problem deleting a symlink that points to a directory that doesn't exist? | 18:35 |
| awilkins | They tried to get me to buy Vista64 at my friendly retailer | 18:36 |
| rockstar | beuno, lp:~rockstar/loggerhead/unify-templates | 18:36 |
| awilkins | I laughed in their face and burned their warehouse down | 18:36 |
| Peng_ | abentley: ping | 18:36 |
| rockstar | I've moved the search and rss out of the menu | 18:36 |
| pickscrape | It gives me: bzr: ERROR: Not a branch: "/path/to/symlink/target/". | 18:36 |
| Peng_ | abentley: I just got a mailer daemon error from a message sent to you (just a CC on a mailing list post). time limit exceeded: "procmail -a "$EXTENSION"" | 18:36 |
| jam | awilkins: well, I got your email from gmane, so it seems to work fine | 18:37 |
| * beuno looks at rockstar's branch | 18:38 | |
| LarstiQ | jam: as does everybody else, yes. | 18:39 |
| jam | LarstiQ: especially with the Py_ssize_t stuff | 18:40 |
| beuno | rockstar, all changes look good to me | 18:49 |
| beuno | I'm happy to merge, unless you want to wait for mwhudson and thumper to re-review | 18:50 |
| pickscrape | Is it worth me raising a new bug about the fact that bzr rm <dangling_symlink> doesn't work, or it is amply covered by the existing bugs that deal with the same problem with other commands? | 18:50 |
| beuno | pickscrape, I'd say it's worth it. If it turns out to be covered, it'll just get marked as duplicate | 18:52 |
| beuno | rockstar, btw, if you ever want to test search, you just need to install the bzr-search plugin, and run 'bzr index' on the branch | 18:52 |
| === mw is now known as mw|lunch | ||
| === kiko-fud is now known as kiko-phone | ||
| rockstar | beuno, I've addressed everything thumper had in the review. I haven't seen a review from mwhudson yet. | 20:15 |
| rockstar | Although, sometimes it takes him a few days. | 20:15 |
| beuno | rockstar, I'll merge. mwhudson can yell at me later. I think 2 reviews is more than adecuate | 20:16 |
| TheEric | How does one reconcile without using ssh? | 20:16 |
| rockstar | beuno, :) | 20:16 |
| beuno | TheEric, bzr reconcile sftp://... | 20:16 |
| TheEric | k, I'm going to try that approach to reconcile our current app as the ssh method evidently doesn't work. | 20:17 |
| beuno | TheEric, good luck :) | 20:18 |
| TheEric | fail. Paraminko needs to be installed.. Bah. | 20:18 |
| beuno | TheEric, it should be installed by default. You're on windows, right? | 20:19 |
| Manfre | i had the same problem yesterday, gave up since pycrypto needed vs2003..i only have 2005/2008 | 20:19 |
| Manfre | beuno, it's not installed by default for python 2.5 installer and not for 1.6 bzr iinstaller | 20:19 |
| * beuno pokes markh | 20:20 | |
| beuno | I don't know much about windows anymore. Mark may be awake already | 20:21 |
| === kiko-phone is now known as kiko | ||
| TheEric | Gotta love university bandwidth. Downloads around 1000kb/s | 20:23 |
| beuno | rockstar, merged | 20:24 |
| rockstar | beuno, great, thanks! | 20:24 |
| === sm is now known as sm-afk | ||
| Peng_ | Ooh. | 20:35 |
| === mw|lunch is now known as mw | ||
| Peng_ | beuno / rockstar: The feed button on /changes is broken (not the <link> tag, just the regular old <a> next to the search box). | 20:38 |
| Peng_ | <a href="Exception: name 'url' is not defined" title="RSS feed for /my/branch"> | 20:38 |
| rockstar | Peng_, ah, thanks. | 20:38 |
| rockstar | beuno, I'll fix it in the existing branch, and you can just merge it again. Sound good? | 20:38 |
| beuno | rockstar, yeap | 20:39 |
| beuno | Peng_, as always, you rock :) | 20:39 |
| Peng_ | :) | 20:39 |
| === Toranin1 is now known as Toranin | ||
| jam | beuno: There is a release candidate tarball that has been uploaded. | 20:53 |
| jam | I'm sending the announcement now | 20:53 |
| Peng_ | Whee. | 20:53 |
| rockstar | beuno, the fix is ready for merging. | 20:54 |
| === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc2! / http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ | ||
| beuno | jam, I'll upload packages then. | 20:54 |
| beuno | rockstar, cool, I'll merge | 20:54 |
| rockstar | I also checked to make sure that nothing else is broken. :) | 20:54 |
| beuno | rockstar, pushed. Sorry I missed that in the review | 21:00 |
| rockstar | beuno, yea, I missed it as well. It happens. | 21:00 |
| beuno | jam, when do you expect 1.6 final to be out? this week? | 21:00 |
| jam | beuno: ASAP, within a week if nobody complains about the release | 21:02 |
| jam | markh: I would like you to make full-fledged installers if you can. If not, I can put together some bzr-lite ones (I won't be including tbzr, etc.) | 21:03 |
| beuno | jam, because it may be worth uploading 1.6rc2 hardy to the ~bzr PPA too, since there's no bzr release on it now | 21:03 |
| jam | beuno: can't we just copy the one from gutsy? | 21:03 |
| jam | I'm not a big wizard on the ppa side of things | 21:03 |
| jam | but I thought the gutsy and hardy package were identical | 21:03 |
| beuno | jam, copying packages breaks stuff. I haven't gotten them to work. Ever. | 21:04 |
| beuno | there are theories | 21:04 |
| beuno | I can try it again | 21:04 |
| beuno | last I heard, copyong gutsy -> hardy should be fine | 21:04 |
| beuno | but it tends to not work | 21:04 |
| beuno | oh, and we can't have 1.5 | 21:04 |
| beuno | since we already uploaded 1.6b2 before | 21:04 |
| jam | "can't have 1.5" ? ouch | 21:04 |
| beuno | so it's 1.6b3+ | 21:05 |
| beuno | yeah | 21:05 |
| pickscrape | That seem like quite a limitation to the PPA system. | 21:05 |
| jam | well, in that case I'd do 1.6rc2, but still crappy | 21:05 |
| jam | pickscrape: you *can* have old versions, but it won't recommend them | 21:05 |
| jam | if something newer has been uploaded and then subsequently removed | 21:05 |
| beuno | pickscrape, it's apt, not ppa | 21:05 |
| jam | beuno: so I believe you *can* explicitly request 1.5 | 21:05 |
| beuno | jam, ok, cool. I'll upload to both | 21:05 |
| jam | beuno: only for hardy though on ~bzr | 21:05 |
| pickscrape | Even if you never installed the previously uploaded version? | 21:06 |
| jam | beuno: and don't forget the bzr1.6~rc1 :) | 21:06 |
| beuno | jam, there may be stuff in place on PPA to prevent that | 21:06 |
| beuno | jam, yes, and yes :) | 21:06 |
| beuno | I'll run it by you before uploading | 21:06 |
| jam | pickscrape: if you use the 'any' filter you can see it: https://edge.launchpad.net/~bzr/+archive?field.name_filter=&field.status_filter=any | 21:07 |
| jam | there is a bazaar1.5 there | 21:07 |
| jam | It has status "superseded" though, and it is superseded by the deleted package :( | 21:07 |
| jam | beuno: are you sure Superseded isn't only a ppa thing? | 21:07 |
| === meteoroid_ is now known as meteoroid | ||
| pickscrape | But isn't that status defined on the PPA side, or would changing it break apt? | 21:08 |
| beuno | jam, yeah, it works that way everywhere else | 21:08 |
| james_w | beuno: you can re-upload 1.5 | 21:08 |
| jam | james_w: but isn't it superseded by something newer? | 21:09 |
| jam | james_w: I mean, the 1.5 package is *still there* | 21:09 |
| james_w | just give it a version of "1.6b3+really.1.5-1" or similar | 21:09 |
| jam | james_w: evil | 21:09 |
| beuno | james_w, right, dato proposed that, but it seemed like too much of a hack | 21:09 |
| pickscrape | but crafty :) | 21:09 |
| james_w | there's plenty of precedent | 21:09 |
| beuno | and, well, 1.6 has been "almost" out for a while now :) | 21:10 |
| jam | james_w: with the downside that 1.6b3 will be "upgraded" to 1.5, right? | 21:10 |
| james_w | yeah, if you had the ~bzr ppa, but not the ~bzr-beta | 21:10 |
| jam | beuno: well, I'm planning on pushing really hard to see that it does | 21:10 |
| james_w | that's normally the intention when you do that | 21:10 |
| jam | There was really only 1 thing that Martin had on his list that I'm skipping | 21:11 |
| jam | but I have to wait for AU time for everyone to respond to my plans | 21:11 |
| jam | beuno: are you going to be around in 48 hours? (My friday) | 21:11 |
| beuno | jam, I can't upload to ~bzr-beta-ppa, I haven't been approved | 21:12 |
| beuno | jam, yeah, I'll be here friday | 21:12 |
| TheEric | well, that reconcile failed with the sftp:// | 21:12 |
| TheEric | http://pastebin.com/m65dc1423 | 21:13 |
| jam | beuno: well, we'll have to see if *I've* been approved :) | 21:13 |
| jam | I think martin added me a while back | 21:13 |
| jam | if you can put them somewhere, I'll upload | 21:13 |
| beuno | jam, yeah, you're approved. Once I upload succesfully to ~bzr, I'll place em somewhere so you can upload them to ~beta | 21:14 |
| TheEric | Here's the .bzr.log file - http://pastebin.com/m13f08af1 to go with that failed reconcile. | 21:17 |
| jam | beuno: once you upload it, I can actually just copy it directly to ~bzr-beta-ppa using LP's copy package feature | 21:18 |
| beuno | jam, for hardy you can, not the rest | 21:19 |
| jam | beuno: can't I copy ~bzr/hardy => ~bzr-beta-ppa/hardy | 21:20 |
| jam | and then copy /hardy => /gutsy, etc ? | 21:20 |
| jam | Just not dapper | 21:20 |
| beuno | jam, nope. It broke every single time we did that with poolie | 21:20 |
| jam | well, that's pretty crummy | 21:20 |
| jam | james_w: what's up with that ? | 21:20 |
| beuno | OTOH, it's rumoured that uploading to, say, feisty, and then copying "upwards", works | 21:20 |
| jam | beuno: was it just a dependencies thing? | 21:21 |
| james_w | beuno: what broke? | 21:21 |
| jam | and does it change if you check the "copy binaries" flag? | 21:21 |
| james_w | if it's just a source copy and you are re-uploading the same source then I would assume it works, but I am probably missing something | 21:21 |
| beuno | james_w, dependencies | 21:22 |
| beuno | if you re-upload, and it re-builds, it's fine | 21:22 |
| beuno | if you copy, it's not | 21:22 |
| james_w | yeah, they are generated at build time, so I would have thought that a source copy would cause a rebuild and that would work | 21:22 |
| jam | james_w: so you think that copying without checking the "copy binary" should work? | 21:24 |
| james_w | that's what I thought, but it hasn't worked previously | 21:25 |
| beuno | jam, bzr_1.6~rc2-1~bazaar1~hardy1 | 21:26 |
| jam | beuno: I thought we weren't doing the ~hardy1 thing ? | 21:26 |
| beuno | jam, I'm not, but poolie kept on doing it | 21:26 |
| jam | Just plain ~bazaar1 | 21:26 |
| beuno | yeah, I like that more | 21:27 |
| jam | as long as there is precedence, I guess | 21:27 |
| james_w | you should to provide an upgrade path | 21:27 |
| jam | james_w: but then you have to edit it for each one | 21:27 |
| james_w | jam: yup, it's a pain | 21:27 |
| jam | to do ~intrepid1, ~gutsy1, etc. | 21:27 |
| jam | james_w: and how does *that* work with copying? | 21:27 |
| beuno | jam, it copies ~release1 | 21:27 |
| james_w | don't copy if you are doing that I think | 21:27 |
| beuno | which is confusing :) | 21:28 |
| jam | beuno: so if you copy ~hardy1 => gutsy, it changes that value? | 21:28 |
| miracle2k | am I crazy or is there now way to link to the latest revision of a file in the launchpad browser? | 21:28 |
| beuno | jam, nope | 21:28 |
| awilkins | markh: Are you win32 release builder? | 21:28 |
| beuno | miracle2k, where are you looking? | 21:28 |
| miracle2k | beuno: say I want to link to the latest README.txt from: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/files | 21:29 |
| beuno | jam, I'd say, leave ~hardy1, etc, don't copy, and have a talk with poolie when he gets back from vacation | 21:29 |
| jam | beuno: um, then I have to re-upload everything | 21:30 |
| beuno | miracle2k, ah, I don't think we have a direct link for that now | 21:30 |
| jam | miracle2k: There is a secret revision "HEAD" that you can use, just a sec | 21:31 |
| beuno | jam, your call. I'll do either | 21:31 |
| jam | beuno: I'll just upload it, but I worry because I've never *actually* successfully built and uploaded packages | 21:31 |
| jam | way too much hassle to do the N-way release thing | 21:32 |
| jam | beuno: this gives me an "internal server error": http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head?file_id=readme.txt-20061211064337-5lpgd5knbgm7jrgz-2 | 21:32 |
| jam | I thought that was the right way | 21:32 |
| beuno | jam, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head:?file_id=readme.txt-20061211064337-5lpgd5knbgm7jrgz-2 | 21:32 |
| jam | ah 'head:' | 21:33 |
| jam | the ':' | 21:33 |
| jam | miracle2k: ^^ | 21:33 |
| miracle2k | jam: thanks a lot! | 21:33 |
| miracle2k | the extra stuff in the file_id just refers to the branch itself I assume? | 21:34 |
| beuno | miracle2k, it's the unique ID for that file | 21:34 |
| beuno | we will probably address that in the next release | 21:35 |
| jam | beuno: wasn't there a path= that you could use? | 21:35 |
| jam | miracle2k: so using a file_id, means that if you rename the file, it will follow the rename | 21:35 |
| beuno | jam, no, I don't think you can use paths ATM | 21:35 |
| jam | beuno: so, you have the package available, or it has been uploaded? | 21:35 |
| jam | beuno: hmm.. I was pretty sure it used to work, but not that *I* really care | 21:36 |
| beuno | jam, uploading hardy to ~bzr | 21:36 |
| miracle2k | jam: I get that, but I guess I am confused by the fact that the filename itself is included as well. but nvm, I'll have a closer look at the bzr internals at some point | 21:36 |
| beuno | jam, I've never used the path bit, and I can't think of any part of the code that would do it. That said, Loggerhead still has some unexplored places, so anything's possible | 21:37 |
| jam | miracle2k: when you 'bzr add' a file, we generate a filename that starts with the path | 21:38 |
| jam | after renames, etc, it keeps the original id | 21:38 |
| jam | beuno: I just thought someone posted a link using head: and path= as a "nice" url that wasn't exposed anywhere. | 21:39 |
| jam | You just had to know it existed. | 21:39 |
| jam | But I would guess you have as much info about LH as anyone anymore | 21:39 |
| beuno | I remember the head:, because we use bzr's magic underneath. path escapes me, but, again, it wouldn't shock me that it's hidden somewhere. mwhudson is good with those things | 21:40 |
| beuno | jam, [PPA bzr] Accepted: bzr 1.6~rc2-1~bazaar1~hardy1 (source) | 21:40 |
| jam | beuno: well the obvious "path=README.txt" doesn't work | 21:41 |
| jam | certainly it is just a "path2id()" away | 21:41 |
| beuno | jam, maybe we can get a LP admin to approve me in ~beta instead of us uploading/downloading, etc? | 21:42 |
| Peng_ | Yeah, the feed thing is fixed. :) | 21:43 |
| Peng_ | Thanks. | 21:43 |
| jam | beuno: yeah, poolie added lifeless and I as "Members" but not "Administrators" so we can't approve you. | 21:44 |
| jam | I started the copy to ~bzr-beta-ppa | 21:44 |
| jam | Which seems successful and seems to want to build binaries for it | 21:44 |
| beuno | jam, wanna try copying to intrepid/gutsy/feisty? | 21:45 |
| jam | james_w: can you mark a package "Needs building" ? | 21:45 |
| jam | beuno: I can certainly try it, right? | 21:45 |
| jam | worst case we just upload them directly? | 21:45 |
| beuno | yeap, with -2 in 'em | 21:45 |
| james_w | jam: don't think so, it should happen automatically if you didn't copy binaries | 21:45 |
| jam | james_w: Well, I just tried to copy ~hardy1 => intrepid, and it gave me: | 21:46 |
| jam | The following source cannot be copied: bzr 1.6~rc2-1~bazaar1~hardy1 in hardy (same version already building in the destination archive for Hardy) | 21:46 |
| jam | james_w: It seems the "series" field isn't being respected? | 21:46 |
| jam | Maybe it is being overloaded by the ~hardy1 ? | 21:46 |
| beuno | hrm | 21:47 |
| beuno | maybe PPA's don't allow the same package in 2 different places? | 21:47 |
| jam | beuno: well, that negates the *point* of the copy feature, right? | 21:47 |
| === salimander is now known as Mercenary | ||
| === Mercenary is now known as Suigintou | ||
| jam | I mean, if you can't actually copy to another "Destination Series" then you really can't do anything | 21:47 |
| jam | other than between PPAs | 21:47 |
| jam | but certainly they are trying to give the option | 21:48 |
| beuno | jam, unless it's for a different release, but yeah, I can't get my head around copying in PPA | 21:48 |
| jam | beuno: and, of course, there is "expected behavior" and there is "bugs" | 21:48 |
| beuno | exactly :) | 21:49 |
| jam | That's why I'm trying to poke at james_w to see what category this sort of thing falls under | 21:49 |
| jam | https://help.launchpad.net/PPA?action=show&redirect=PPAQuickStart#Copying%20packages | 21:49 |
| jam | Is pretty vague | 21:49 |
| james_w | I've never done a package copy, I agree with your expectation of this though jam | 21:50 |
| jam | Really, it just says what you should expect on the page | 21:50 |
| james_w | it sounds like it's trying hardy->hardy | 21:50 |
| jam | and not really what you should expect it to actually do | 21:50 |
| james_w | maybe #launchpad ? | 21:51 |
| jam | james_w: it does indeed, but I'm definitely changing the "Destination Series" | 21:51 |
| jam | trying there | 21:58 |
| [reed] | How do I kill a stuck lock on a bzr repo? Trying to commit to a local repo, and it says there's a lock. The pid it claims the lock belongs to doesn't exist (it did the first time, but it's been killed since then). | 22:02 |
| awilkins | bzr break-lock | 22:03 |
| [reed] | thanks! | 22:04 |
| beuno | OMG, jam names his PC after pokemons! | 22:13 |
| LarstiQ | beuno: you didn't know? :) | 22:15 |
| * LarstiQ fondly remembers jigglypuff | 22:15 | |
| beuno | no, I should pay more attention | 22:16 |
| Peng_ | I didn't know. Nice. :) | 22:18 |
| === kiko is now known as kiko-afk | ||
| Stavros | hello | 22:29 |
| Stavros | is there a bzr repo that has the current version of bzrtools? | 22:29 |
| Stavros | right now i can install either the latest bzr version or bzrtools :/ | 22:30 |
| lifeless | jam: ^ I think perhaps you uploaded a beta to stalle ppa? | 22:30 |
| beuno | lifeless, I did. There was no bzr for hardy | 22:31 |
| beuno | so, I thought, better 1.6rc2 than nothing | 22:31 |
| beuno | of course, this breaks bzrtools | 22:31 |
| beuno | *sigh* | 22:31 |
| beuno | and, good morning lifeless :) | 22:32 |
| Stavros | is there a solution for the bzrtools problem? | 22:32 |
| beuno | Stavros, you can uninstall it, and install from source | 22:32 |
| Stavros | beuno: but that way it won't be tracked | 22:32 |
| beuno | Stavros, right. The other option is wait until someone has time to upload bzrtools 1.6 (is that even released?) | 22:33 |
| Stavros | ah :/ | 22:34 |
| beuno | sorry about that | 22:34 |
| Peng_ | You could install bzrtools from source, and delete it once an update is available. | 22:35 |
| === meteoroid_ is now known as meteoroid | ||
| === meteoroid is now known as meteoroid_ | ||
| === meteoroid_ is now known as meteoroid | ||
| jam | beuno, LarstiQ: Actually after Super Smash Brothers | 22:45 |
| jam | Samus == Metroid lady | 22:45 |
| jam | Jigglypuff was my old mac | 22:45 |
| jam | lifeless: Kiko on #launchpad determined that you *can't* use the copy feature of LP to copy between distributions within the same archive | 22:46 |
| jam | because it can't rename the package | 22:46 |
| beuno | jam, right, right, smash brothers :) | 22:46 |
| jam | So it would get naming conflicts. | 22:46 |
| beuno | jam, btw, uploading for dapper now, that should be the last of it | 22:47 |
| jam | beuno: SSB with sudden death mode, and all Jigglypuff characters was very entertaining | 22:47 |
| lifeless | jam: AIUI we shouldn't ever be using copy | 22:47 |
| jam | lifeless: well, copy is mentioned in the docs | 22:47 |
| jam | because it would make our lives a lot easier | 22:47 |
| lifeless | our docs or launchpads? | 22:47 |
| jam | and you *can* copy the package from ~bzr-beta-ppa => ~bzr | 22:47 |
| jam | lifeless: ours | 22:47 |
| jam | and launchpad hints that you can use it | 22:47 |
| jam | but gives very little as to what to expect. | 22:47 |
| lifeless | right, but it lies :) | 22:47 |
| jam | LP will *let* you say that you want to copy X package to the same archive | 22:48 |
| jam | but that never works | 22:48 |
| jam | unless maybe you copy the binaries | 22:48 |
| jam | but then you likely have problems with deps | 22:48 |
| lifeless | jam: full test run of .bzrrules disabling code is running now | 22:52 |
| jam | lifeless: well, you also have to convince at least one other person that it is *correct*, as I don't really think it is. | 22:52 |
| lifeless | jam: I've convinced three others | 22:53 |
| lifeless | jam: Ian, Jelmer, and Martin | 22:53 |
| lifeless | though to be pedantic, Jelmer came preconvinced | 22:53 |
| lifeless | and if I could find this damn email rant from Aaron back in the day I'd have more evidence | 22:53 |
| strk | bazaar thinks I hold a lock, but I've no bzr process running | 22:55 |
| strk | any way to further debug the issue ? | 22:55 |
| lifeless | strk: we don't use oslocks, so thats possible | 22:55 |
| lifeless | strk: what does bzr break-lock say about the lock ? | 22:55 |
| jam | lifeless: If you've convinced Ian, I'm okay with it. I think it falls into the "we keep saying this isn't the right way, but we provide no better way so we have nothing". | 22:55 |
| strk | prompts me to break it, said yes | 22:56 |
| strk | said it was hold by me (my email) | 22:57 |
| strk | one hour, 30 mins | 22:57 |
| strk | it was after a merge from trunk | 22:57 |
| lifeless | jam: I've just reread Ian's mail to me, I think I had agreement there is an issue. | 22:58 |
| lifeless | jam: I'm forwarding it to you | 22:58 |
| lifeless | strk: something must have hard-interrupted bzr | 22:59 |
| lifeless | strk: e.g. SIGKILL or SIGHUP | 22:59 |
| strk | possible | 23:00 |
| lifeless | strk: we can't use OSLocks over the network; so we don't use them for data structures that are network accessible | 23:01 |
| beuno | jam, all debs uploaded and published | 23:01 |
| jam | lifeless: I'm also responding with the last post I saw from igc on the mailing list | 23:02 |
| jam | lifeless: or two SIGINTs at the right time (one while we're cleaning up is sufficient) | 23:02 |
| jam | beuno: thanks a lot!! | 23:02 |
| beuno | jam, my pleasure. You should milk this as much as possible, before I actually get a manager assigned and have something specific to do :) | 23:03 |
| lifeless | jam: did you have more feedback on the inventory docs? I think I have enough to recast it as a tighter set of needs if you don't | 23:04 |
| jam | lifeless: I have an email for you I'm finishing, but right now I have to pick up my son from daycare. | 23:05 |
| lifeless | jam: go then | 23:05 |
| lifeless | jam: think you'll get it to me today? | 23:05 |
| thumper | could I get someone who knows about reconcile to take a look at https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/257340 please? | 23:06 |
| ubottu | Launchpad bug 257340 in launchpad-bazaar "Revision History set to 0 following push" [Undecided,New] | 23:06 |
| thumper | it is beyond me | 23:06 |
| lifeless | jam: on the rules stuff | 23:07 |
| lifeless | jam: I had a conflict of interests in my head back at the start of the yea | 23:07 |
| lifeless | *year* | 23:07 |
| lifeless | as a community guy I wanted to flat veto designs involved versioned user files | 23:07 |
| lifeless | as a canonical guy I wanted to see features land as fast as possible | 23:08 |
| lifeless | I've wrestled with myself and come to the conclusion that landing the wrong thing isn't right for anyone | 23:08 |
| lifeless | which is why I'm engaging on this topic again | 23:08 |
| luks | I wonder how do you want to handle historical data if you don't version .bzrrules | 23:15 |
| === sam__ is now known as samatwork | ||
| samatwork | does anyone know how to fix a bzr: ERROR: not well-formed (invalid token) error? | 23:20 |
| samatwork | I've looked all over for an error that explains it and I know that many have had it, but I didn't see any clear-cut solution | 23:20 |
| james_w | samatwork: hi, I've never seen that before, do you get a full backtrace, or just that? | 23:21 |
| samatwork | just that | 23:21 |
| samatwork | I'm getting it on all clients that are referencing a central repository | 23:21 |
| samatwork | I fibbed it it also gives a line and column number, but I have no idea what this is referencing | 23:22 |
| samatwork | can't find anything at launchpad either | 23:23 |
| james_w | could you please run with "-Derror" as an extra command line argument to get a backtrace, and then pastebin that? | 23:24 |
| james_w | ubottu: paste | 23:24 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 23:24 |
| samatwork | here you go .... http://paste.ubuntu.com/37261/ | 23:27 |
| james_w | samatwork: what about "bzr -Derror update"? | 23:27 |
| lifeless | luks: its not about historical data; its about decoupling representation and function | 23:28 |
| james_w | if it's the same then the problem is on the remote side, I think | 23:28 |
| lifeless | luks: if you want to to a fix for squid 3.0, on windows, you need EOL translation | 23:28 |
| lifeless | luks: but the 3.0 revision doesn't have .bzrrules | 23:28 |
| lifeless | luks: so I think having .bzrrules in the users tree is fine as a presentation layer today | 23:30 |
| lifeless | luks: but I want us to retain the ability to change representation in the future; without requiring a 'dump and reload' approach | 23:31 |
| lifeless | luks: think about CVS 'b' flags - they were not per-branch, there was no 'propogation' needed | 23:31 |
| samatwork | james_w: http://paste.ubuntu.com/37263/ | 23:32 |
| samatwork | looks like it has something to do with an unexpected inventory format | 23:32 |
| james_w | it looks like corruption of the inventory on disk | 23:33 |
| samatwork | it must be on the side of the repository though since all clients point to it return the same message | 23:34 |
| samatwork | any thoughts on how to fix this short of recreating the repository? | 23:34 |
| james_w | I'm not sure | 23:34 |
| james_w | lifeless: any hints for samatwork? | 23:35 |
| jam | lifeless: my response has been emailed | 23:36 |
| lifeless | james_w: I'd use repository.get_inventory_xml to get the raw xml and look at it | 23:36 |
| jam | lifeless: I understand your concern, but I also feel you have at least 2 major things on your plate for 1.7 | 23:36 |
| lifeless | samatwork: are you using bzr-svn ? | 23:36 |
| jam | bringing in a 3rd is not really going to happen | 23:36 |
| samatwork | lifeless: nope just straight bzr | 23:37 |
| lifeless | jam: If it needs to happen to avoid a mistake, it needs to happen | 23:37 |
| lifeless | jam: its a lot less stressful for me to do that than to see .bzrrules go in as-is | 23:37 |
| jam | I also have to say that the last messages from IGC don't look like agreement | 23:37 |
| lifeless | it will make nested-trees harder, join-tree and split-tree, it won't solve the usability problems the folk that I know that want EOL stuff on windows have | 23:38 |
| jam | They pretty much say "we need something, and this is the path of least resistance" | 23:38 |
| jam | which is where I fall | 23:38 |
| jam | I fully understand your conflict of interest | 23:38 |
| jam | And feel the same way | 23:38 |
| lifeless | if I had resolved it previously, I would have bb:vetoed this code | 23:38 |
| jam | I probably am more on the "frustrated by not having things like nested trees" | 23:38 |
| jam | for *years* now | 23:38 |
| jam | in any form | 23:38 |
| lifeless | full ack | 23:38 |
| jam | and taking what, >1 year to get any real in-core tags | 23:38 |
| jam | and we still have non-optimal ones | 23:38 |
| lifeless | note that git doesn't version its tags | 23:39 |
| jam | I guess sort of like the OpenGL 3.0 release... wait a year, and still get only something incrementally better. | 23:39 |
| lifeless | jam: that is because noone is spending time on these things, not because its a particularly hard problem | 23:39 |
| jam | lifeless: well, we had several designs that were possible | 23:40 |
| jam | and it was fundamentally a trade-off | 23:40 |
| jam | between complexity and handling all cases | 23:40 |
| jam | In git, moving a tag is a bad deal | 23:40 |
| jam | which it pretty much is in bzr as well | 23:40 |
| jam | trying to get it to propagate | 23:40 |
| jam | and deleting anything doesn't work | 23:40 |
| jam | (well, it deletes locally, but never propagates, etc) | 23:42 |
| jam | different topic... With LP, if I upgraded from Knit => pack-0.92 when I upgrade from pack-0.92 => 1.6 won't that cause a problem with the backup.bzr directory? | 23:43 |
| jam | Is there a simple way to delete that? | 23:43 |
| jam | (Other than going in with abentley's hitchiker and doing a sftp deltree) | 23:43 |
| samatwork | thanks for the help everyone... I have to run | 23:44 |
| lifeless | jam: they are just refs in git, and their ref management is quite sophisticated | 23:45 |
| jam | lifeless: specifically, change a tag and pull into the next repo | 23:46 |
| jam | it won't propagate | 23:46 |
| jam | well, maybe just merge | 23:46 |
| jam | I think if you force a pull it will overwrite | 23:46 |
| jam | And I don't know about delete | 23:46 |
| lifeless | jam: I think you need hitchhiker | 23:46 |
| lifeless | jam: I'd file a bug on lp :P | 23:47 |
| jam | lifeless: I'm not doing it right now, I'm just upgrading a Knit repo | 23:47 |
| jam | and realizing we'll probably have a problem later | 23:47 |
| ben__ | Hi! I have a question on how to clean up a repository e.g.: | 23:51 |
| ben__ | bzr init-repository foobar | 23:51 |
| ben__ | bzr init foobar/trunk | 23:51 |
| ben__ | bzr branch foobar/trunk/ foobar/feature | 23:51 |
| ben__ | dd if=/dev/urandom of=foobar/feature/random count=10000 | 23:51 |
| ben__ | bzr add foobar/feature | 23:51 |
| ben__ | bzr ci foobar/feature | 23:51 |
| ben__ | du -sh foobar/.bzr | 23:51 |
| ben__ | 5,0M foobar/.bzr/ | 23:51 |
| ben__ | how do I delete the branch feature out of the whole project? | 23:51 |
| Peng_ | ben__: You pretty much don't. | 23:51 |
| ben__ | theere | 23:52 |
| ben__ | there is no way? | 23:52 |
| james_w | ben__: you mean you want to discard the branch, and free up the used disk space? | 23:53 |
| ben__ | yes | 23:53 |
| ben__ | the docu says i just have to rm foobar/feature | 23:53 |
| james_w | yeah, but that doesn't free up the space | 23:54 |
| ben__ | but then I have the wasted space in .bzr | 23:54 |
| ben__ | yes | 23:54 |
| james_w | there's no simple command to do this at the moment | 23:54 |
| ben__ | is there already a bugreport (featurerequest) for this? | 23:54 |
| james_w | what you basically have to do is create a new repo, branch the branches you want in to it, and then delete the old one and move the new one in to place | 23:54 |
| james_w | I'm not sure | 23:55 |
| ben__ | yes, that solution came into my mind, but it is not very nice… | 23:55 |
| james_w | no, it's not great | 23:56 |
| james_w | there's an experimental plugin to do it in one go if you want to test that | 23:56 |
| ben__ | yes, of course ;)) | 23:56 |
| ben__ | but i didn't found one doing this at the homepage… | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!