| === poolie_ is now known as poolie | ||
| spiv | Hmm, I think I just found a hack to improve the test suite time by about 10%. | 01:03 |
|---|---|---|
| poolie | nice | 01:06 |
| poolie | what was it? | 01:10 |
| lifeless | rm -r <some dir> | 01:12 |
| spiv | Yep, seems to work: have _check_safety_net just open .bzr/checkout/dirstate directly and compare the raw bytes to its known pristine state, rather than open_workingtree and check .last_revision() | 01:14 |
| spiv | Which perhaps hints we can optimise opening a working tree a little more, but this is easier ;) | 01:14 |
| spiv | (And perhaps we can improve further by just using stat, but that's probably not worth the complexity) | 01:16 |
| poolie | indeed | 01:31 |
| poolie | +1 | 01:31 |
| spiv | Hmm, I thought I'd targetted that branchbuilder patch to lp:bzr/2.4. I wonder if I entered lp:bzr/2.4 into the text field without also clicking the radio button... | 01:41 |
| poolie | :/ | 01:48 |
| poolie | spiv your branch has conflicts | 01:48 |
| poolie | so you probably need to resubmit anyhow | 01:48 |
| poolie | or fix it before mine completes | 01:48 |
| spiv | poolie: thanks, looking now | 02:03 |
| spiv | Oh, lp:bzr/2.4 is the same as lp:bzr. I got the impression that we'd split them already. | 02:06 |
| spiv | Just in time to avoid resubmitting :) | 02:08 |
| poolie | we were meant to have split but vila hasn't done it | 02:15 |
| poolie | maybe we should | 02:15 |
| === poolie_ is now known as poolie | ||
| vila | poolie, spiv: lp:bzr shouldn't be the same as lp:bzr/2.4 AIUI, at least I've seen poolie sending a cleanup on lp:bzr and that's ok, the plan is to open lp:bzr as 2.5dev1. A few commits before that won't matter. | 06:29 |
| vila | poolie: I think we should keep the minimum API to 2.4.0 for a little while so plugin authors can focus on releasing for 2.4 without having to handle 2.5 | 06:31 |
| vila | poolie: Does delaying the API bump sounds ok ? | 06:38 |
| spiv | vila: Well, https://launchpad.net/+branch/bzr/2.4 still resolves to ~bzr-pqm/bzr/bzr.dev | 06:39 |
| poolie | vila, i'm not sure what you mean | 06:40 |
| poolie | there might have been api changes on trunk that would not be appropriate post-final-beta | 06:40 |
| poolie | if that's true, we should branch off 2.4 from a previous revision | 06:41 |
| vila | spiv: eerk | 06:41 |
| spiv | vila: Poking around I see there is a lp:~bzr-pqm/bzr/2.4, but that's not where lp:bzr/2.4 resolves to | 06:41 |
| poolie | possibly we should branch from the revision tag anyhow | 06:41 |
| vila | poolie: no no | 06:41 |
| vila | spiv: yup, that's the bit I missed, hopefully we can fix that without losas | 06:41 |
| vila | poolie: there is no known API break that I know | 06:41 |
| vila | poolie: I'm talking about bumping to 2.5. Last time we did this bump early, I don't want to make it *too* early | 06:43 |
| vila | at a minimum, not when opening for 2.5dev1 | 06:44 |
| poolie | you're talking about when to change the api version vs the library version? | 06:44 |
| vila | After 2.4.0 sounds about right | 06:44 |
| vila | yes | 06:44 |
| poolie | i think the separate api version is almost a null concept | 06:44 |
| vila | ha | 06:44 |
| poolie | iow i think people should just depend on the implementation version | 06:44 |
| poolie | i don't think the api version is reliable enough to be worth while | 06:45 |
| poolie | i don't think the api version is reliable enough to be worth while | 06:46 |
| vila | hmm, ok, in this case we should decide if we deprecate that and make it widely known | 06:46 |
| poolie | there is a bug complaining about it | 06:46 |
| vila | so in the short term, I can just open 2.5dev1 and leave it at that (and also fix the lp:bzr/2.4 associated branch) | 06:46 |
| poolie | can we be more concrete? | 06:48 |
| poolie | i think the actions are | 06:48 |
| poolie | - branch off bzr/2.4 from trunk | 06:48 |
| poolie | - increment the version in trunk | 06:48 |
| poolie | ...? | 06:48 |
| poolie | - add pqm configuration for 2.4 if needed? | 06:48 |
| vila | branch off and pqm are already done | 06:48 |
| vila | and I have a branch to switch to 2.5dev1 where I should commit and land | 06:49 |
| poolie | but the 2.4 series in lp is pointing at the wrong branch? | 06:49 |
| poolie | - add news and other document stubs | 06:49 |
| vila | last, lp:bzr/2.4 should point to lp:~bzr-pqm/bzr/2.4 | 06:49 |
| poolie | right | 06:50 |
| vila | yup, document stubs are uncommitted but done | 06:50 |
| vila | I need to create a 2.5 series and some milestones on lp | 06:51 |
| vila | (while ensuring doc/developers/releasing.txt is still up to date) | 06:52 |
| poolie | ok, thanks for taking care of it | 06:59 |
| poolie | vila, babune seems unreachable | 07:11 |
| vila | restarted | 07:11 |
| poolie | i was wondering if spiv's changes would have made things faster | 07:12 |
| vila | which ones ? | 07:13 |
| poolie | he did a thing to make selftest faster at checking whether it needs to make a new scratch directory | 07:14 |
| vila | hmm, just looking at it | 07:14 |
| spiv | vila: r6020 | 07:14 |
| vila | but the dirstate doesn't protect against repository changes | 07:14 |
| vila | we talked about making the branch/repo read-only but I don't think we ever implemented that | 07:15 |
| spiv | It's no weaker than the check it replaces | 07:18 |
| spiv | Which was just wt.last_revision() == 'null:' | 07:18 |
| vila | spiv: yup, just saw that | 07:18 |
| jam | morning all | 07:18 |
| vila | spiv: may be it should :) | 07:18 |
| spiv | vila: well, maybe | 07:19 |
| spiv | vila: except that this check has proved quite sufficient for years | 07:19 |
| poolie | hi there jam | 07:19 |
| spiv | So I think probably the effort to make it stricter is probably not worth it :) | 07:19 |
| vila | spiv: did you see it trigger often ? | 07:19 |
| vila | I know I never did | 07:19 |
| spiv | vila: a better question is: | 07:19 |
| poolie | is this about the guard wt above the tests? | 07:20 |
| spiv | vila: did you ever see a problem that a stricter check would have avoided or helped with? | 07:20 |
| spiv | vila: I never have. | 07:20 |
| * vila nods | 07:20 | |
| poolie | it's a little kludgy that it's even there | 07:20 |
| * spiv -> gone for the day | 07:29 | |
| poolie | bye spiv | 07:43 |
| vila | poolie: all done, 2.5dev1 sent to pqm | 07:50 |
| vila | there will probably some tweaks needed to move news entries from 2.4 to 2.5 for the ones landed since the fork | 07:51 |
| poolie | ok good, thanks | 07:59 |
| poolie | jam, how are you? | 07:59 |
| Riddell | good morning | 08:07 |
| poolie | hi Riddell, how are you? | 08:09 |
| jam | poolie: doing pretty good | 08:09 |
| jam | did you enjoy your vacation? | 08:09 |
| jam | seems you were productive on the flight back againg | 08:09 |
| poolie | i did | 08:10 |
| poolie | it was pretty good | 08:10 |
| poolie | i got a bit closer to getting usertest to do what i want too | 08:10 |
| poolie | i hope to get back to that tomorrow or wednesday | 08:10 |
| poolie | jam, how did you go with the performance bug that was affecting linaro? | 08:11 |
| jam | poolie: bzr-svn peak memory issues? I got a little ways, but mostly I have to learn the bzr-svn codebase a bit | 08:12 |
| jam | they are unblocked for now, because of the manual improt | 08:13 |
| jam | import | 08:13 |
| Riddell | poolie: I'm bright and breezy and looking forward to another exciting week of bzr | 08:14 |
| poolie | :) great | 08:14 |
| poolie | any topics in particular? something on the developer guide perhaps? | 08:15 |
| poolie | jam, so what's next for you? | 08:15 |
| jam | I was hoping to meet up with Jelmer today | 08:15 |
| jam | once he wakes up | 08:15 |
| jam | and finish the "is branch up-to-date" stuff | 08:15 |
| poolie | did you see his mail? he won't be back for another day | 08:15 |
| poolie | *2 days | 08:15 |
| poolie | vila, according to the wiki you're pp this week; will that fit with your RM work? | 08:16 |
| Riddell | poolie: yes I began looking at the packaging guide, I'll make some changes to it. although the main problem with it is working out how to sensibly split the UDD stuff and the traditional packaging stuff (which mostly isn't in it) | 08:16 |
| poolie | yes, that is a big question | 08:17 |
| poolie | depending a bit on how much this is supposed to be a description of the future vs practically useful today | 08:17 |
| poolie | spiv's selftest change doesn't seem to have especially made a visible change on babune | 08:21 |
| poolie | but, there is a fair bit of noise | 08:21 |
| poolie | oh, it did on maverick | 08:21 |
| poolie | http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/buildTimeTrend | 08:21 |
| poolie | perhaps natty just ran when the machine was busy | 08:21 |
| vila | poolie: argh, how did I manage to miss that :( | 08:30 |
| vila | poolie: don't answer :) | 08:31 |
| poolie | which bit? | 08:31 |
| vila | pp'ing this week | 08:31 |
| poolie | oh that's ok | 08:31 |
| vila | yeah, the queue is pretty short | 08:31 |
| vila | poolie: regarding spiv change: yeah, looks noticeable on maverick and lucid but not on natty | 08:34 |
| vila | they run serialized and the machine was quiet otherwise so, a priori, no external noise | 08:35 |
| vila | we'll see if the progress persists but it's a good improvement | 08:35 |
| jam | maxb: ping for great justice! (Actually just to ask you what happened to your code that checks if a package-import branch is up-to-date.) | 08:51 |
| jam | maxb: I found: https://code.launchpad.net/~jelmer/bzr-builddeb/check-udd-status | 08:57 |
| jam | but jelmer said you made it much faster by avoiding launchpadlib | 08:57 |
| jam | and I don't see a ~maxb branch of bzr-builddeb | 08:57 |
| poolie | jam i wonder what the action is on lp ssh performance | 08:58 |
| poolie | since it's partly just waiting for it to get to the top of the queue | 08:59 |
| jam | poolie: the last state-of-the-losa report said it was being worked on | 09:02 |
| poolie | oh, really | 09:02 |
| jam | (getting ha proxy at least) | 09:02 |
| poolie | that's great | 09:02 |
| poolie | i rebuilt on natty and it did get faster | 09:03 |
| poolie | so, go spiv | 09:03 |
| jam | "Partial de-spof of codehosting in process " | 09:03 |
| jam | I'm inferring a bit there | 09:03 |
| jam | but haproxy would be getting rid of a SPOF | 09:03 |
| === hunger_ is now known as hunger | ||
| === 13WAAFAXG is now known as wallyworld | ||
| === med_out is now known as medberry | ||
| === tchan1 is now known as tchan | ||
| === oubiwann` is now known as oubiwann | ||
| bigjools | can anyone help with this please http://pastebin.ubuntu.com/641976/ - bzr switch thinks that something I just branched is not a branch :( | 15:37 |
| maxb | bigjools: I'd guess that your current checkout is a checkout of a local branch since deleted? | 15:57 |
| bigjools | maxb: gah, yes | 15:58 |
| bigjools | thanks | 15:58 |
| bigjools | what a weird error though | 15:58 |
| maxb | well, ish | 15:58 |
| bigjools | I guess it would help if I'd realised it was referring to a different branch to the one I just tried to switch to! /o\ | 15:59 |
| maxb | It's a perfectly sensible error, but thrown from too low-level a point in the code, and not decorated with suitably informative context | 15:59 |
| === deryck is now known as deryck[lunch] | ||
| muep | hello | 16:58 |
| muep | is there something roughly equivalent to git fetch origin && git log master..origin/master in bzr? | 17:00 |
| muep | I'd like to see the changelog before I actually apply the new upstream changes | 17:01 |
| AuroraBorealis | just branch upstream and do a bzr log on it? | 17:03 |
| === beuno is now known as beuno-lunch | ||
| AuroraBorealis | bzr branch <orgin> && bzr log <orgin> or something | 17:04 |
| maxb | muep: 'bzr missing --theirs-only' ? | 17:07 |
| muep | looks somewhat what I am looking for | 17:08 |
| muep | is it safe to mv a directory to which I have cloned an upstream bzr-using project? | 17:20 |
| muep | I currently have just trunk cloned in src/emacs/ and I guess to get other local branches I would need to get some other directory | 17:24 |
| muep | so I though I should maybe move my current copy to src/emacs/trunk and branch my local branches from that alongside it | 17:24 |
| === beuno-lunch is now known as beuno | ||
| === AuroraBorealis is now known as aurora|away | ||
| === yofel_ is now known as yofel | ||
| jamdahl | Hey guys, I'm having a problem with bzr explorer not launching from its shortcut | 20:16 |
| jamdahl | anytime I try to open bzrw.exe, nothing happens | 20:17 |
| === aurora|away is now known as AuroraBorealis | ||
| AuroraBorealis | is the launch argument like this? "C:\Program Files (x86)\Bazaar\bzr.exe" explorer | 20:26 |
| jamdahl | not exactly"C:\Program Files (x86)\Bazaar\bzrw.exe" explorer | 20:36 |
| AuroraBorealis | should still work. whats bzr.log say? | 20:36 |
| AuroraBorealis | should be in your documents folder | 20:36 |
| AuroraBorealis | .bzr.log i think | 20:36 |
| jamdahl | Mon 2011-07-11 16:36:30 -0400 0.041 bazaar version: 2.2.3 0.041 bzr arguments: [u'explorer'] 0.044 looking for plugins in C:/Users/jamdahl/AppData/Roaming/bazaar/2.0/plugins 0.044 looking for plugins in C:/Program Files (x86)/Bazaar/plugins 0.125 encoding stdout as osutils.get_user_encoding() 'cp1252' 0.255 loading explorer extensions for clothes ['Bazaar support', 'Register on Launchpad'] 0.255 explorer extensions provided by th | 20:37 |
| jamdahl | gah, limit to length | 20:37 |
| AuroraBorealis | pastebin | 20:37 |
| AuroraBorealis | that shiz | 20:37 |
| jamdahl | http://pastebin.com/q81TeHum | 20:38 |
| AuroraBorealis | hmm weird | 20:39 |
| jamdahl | when I run bzr explorer from command line I get the same NoRepositoryPresent: No repository present: "file:///C:/" line | 20:41 |
| AuroraBorealis | is it trying to autoload a repository? | 20:42 |
| AuroraBorealis | try deleting your config for bzr explorer and see if that fixes it | 20:42 |
| jamdahl | Where is it? I've tried deleting the folder in appdata/roaming | 20:43 |
| jamdahl | that was the first thing I tried when reinstalling failed... pesky config files... | 20:45 |
| AuroraBorealis | yeah | 20:45 |
| AuroraBorealis | its %appdata%/Roaming/Bazaar | 20:45 |
| jamdahl | Yep, I've deleted that and if I run bazaar explorer it will regenerate that directory but still doesn't launch a gui | 20:46 |
| AuroraBorealis | are you running the latest version of both bzr and explorer? | 20:49 |
| jamdahl | thankfully I can call pretty much everything else in bzr and qbzr from the command line | 20:49 |
| AuroraBorealis | i dunno what its doing trying to load C: | 20:49 |
| jamdahl | I'm using one of the standalone packages | 20:50 |
| jamdahl | if I have the wrong version of python it isn't my fault :P | 20:50 |
| jamdahl | and it's not exactly the latest version but I'm downloading that now | 20:51 |
| jamdahl | I was using 2.2.3 | 20:51 |
| jamdahl | downloading 2.3.3 now | 20:51 |
| AuroraBorealis | it comes bundled with python so you don't need that | 20:52 |
| jamdahl | That's what I'm saying :P | 20:53 |
| jamdahl | updating to latest version of bzr did not change anything | 20:55 |
| AuroraBorealis | hmm =/ i dunno | 20:56 |
| jamdahl | aha | 20:56 |
| jamdahl | I've been writing a plugin for excel to use bzr for VBA version control | 20:57 |
| jamdahl | it got a bit messy at ttimes | 20:57 |
| jamdahl | apparently at one point it did an init on the c drive | 20:57 |
| jamdahl | apprently bazaar didn't like that and tried to autoload it or somethign | 20:57 |
| jamdahl | deleting the repo in the c drive fixed it | 20:57 |
| AuroraBorealis | nice =) | 20:58 |
| jamdahl | too bad I can't find a satisfactory tool to diff sheets themselves | 21:03 |
| jamdahl | anyway, thanks for the help aurora | 21:06 |
| Noldorin | is it possible to edit old commit messages? | 21:06 |
| maxb | Noldorin: no | 21:24 |
| Noldorin | maxb, is this feature being considered? i know it was at some point. | 21:24 |
| AuroraBorealis | dunno why you would want to | 21:24 |
| Noldorin | AuroraBorealis, typos in past messages, basically | 21:24 |
| Noldorin | AuroraBorealis, or accidental misinformation | 21:24 |
| maxb | Noldorin: The immutability of revisions is pretty much baked deep into the fundamental precepts of bzr (and git and hg) | 21:25 |
| maxb | The only way that I can see it could ever be implemented is via some sort of "No, actually I meant ..." metadata attached to future revisions, which masked the appearance of earlier revisions in the UI | 21:26 |
| Noldorin | maxb, that's not what i heard. was talking to one of the guys who designed the bzr system, a couple of years ago here, and he said it would be possible | 21:26 |
| Noldorin | maxb, he said it would be hard and require some changes to the way hashing was done or something, but possible | 21:26 |
| maxb | Sounds like you should ask him then :-) | 21:26 |
| maxb | But in any case, it's definitely a Hard Problem, and I've not heard of anyone seeking to address it recently | 21:27 |
| Noldorin | maxb, oh yeah, i totally agree it's non-trivial :-) | 21:28 |
| Noldorin | maxb, was discussed briefly on the mailing list before i think...wish i knew the guy's name i once talked to. | 21:28 |
| spiv | maxb: to be precise, I think it'd be possible to have that metadata not necessarily be "attached to future revisions" | 21:28 |
| maxb | The benefit seems quite low compared to the necessary expenditure of effort, which makes it a feature fairly unlikely to be worked on | 21:28 |
| spiv | maxb: but it would need to be stored in the repo somehow, and we'd need to figure out how/when to transmit it efficiently, etc. | 21:29 |
| maxb | Hi spiv | 21:29 |
| * maxb now has jubany access :-) | 21:29 | |
| spiv | maxb: yay! | 21:30 |
| Noldorin | maxb, possibly, though bzr is fairly mature these days...there can't be *that* many more important thigns? | 21:30 |
| Noldorin | well, perhaps there are | 21:30 |
| Noldorin | maxb, spiv right, so what's making the problem trickier than simply editing the metadata file for the repo with the new comit message? | 21:31 |
| maxb | Suppose you edit the embedded metadata of a revision in one repository... how does bzr know it needs propagating to other repositories? | 21:32 |
| maxb | How do you manage the auditability of such changes - or otherwise prevent them from being done maliciously? | 21:33 |
| Noldorin | maxb, a simple boolean flag? either per branch or per revision | 21:33 |
| maxb | boolean? What happens when I want to edit my edit? :-) | 21:33 |
| spiv | Noldorin: "per branch" doesn't work, a repository can be used by many branches, and the number can change over time | 21:33 |
| maxb | And what about if two people edit a revision in conflicting ways? | 21:34 |
| spiv | (And similarly a revision can be propogated any number of times) | 21:34 |
| Noldorin | maxb, spiv ok, so i'm being naive. the only thing that would really work is versioning the commit messages *themselves* :-P | 21:34 |
| Noldorin | having each commit message essentially as a file | 21:34 |
| Noldorin | maxb, that would seem to solve all those issues | 21:35 |
| spiv | Noldorin: you could prototype that approach as a plugin | 21:35 |
| Noldorin | spiv, oh yes? | 21:36 |
| maxb | Of course, once you start down this path, people will want to edit metadata other than messages :-) | 21:36 |
| spiv | Noldorin: store the extra info in a secondary store next to the regular repo | 21:36 |
| spiv | Noldorin: and hook into bzr's fetch etc logic to do the propagation the way you envisage | 21:36 |
| spiv | Noldorin: I think that it'd be an interesting (and useful) way to prototype it. I also think you'll find it's harder than it looks ;) | 21:37 |
| Noldorin | spiv, no doubt it will be quite hard, yeah. good suggestion though | 21:37 |
| Noldorin | spiv, just thinking, would the functionality really be so different to bzr tags? | 21:37 |
| spiv | There *might* be one or two points in bzrlib that don't make it as easy to write that plugin as it ought to be -- file a bug if you find them, they can be fixed. | 21:38 |
| spiv | It is different to tags, because tags are per-branch | 21:38 |
| spiv | (and not versioned either :P) | 21:38 |
| Noldorin | spiv, the tags list is simply merged in the case of a conflict i suppose? | 21:39 |
| spiv | See bzrlib/tag.py; if there's a conflict bzr reports it and lets the user sort it out basically. | 21:40 |
| spiv | And tag deletion isn't propagated. | 21:41 |
| Noldorin | spiv, in terms of merges you mean? | 21:41 |
| spiv | (See also https://bugs.launchpad.net/bzr/+bugs?field.tag=tags) | 21:41 |
| spiv | Noldorin: well try it yourself: make a test branch with two commits, branch it, and do 'bzr tag foo -r1' in one and 'bzr tag foo -r2' in the other | 21:42 |
| spiv | Noldorin: and see what happens if you try push/pull/merge between those | 21:42 |
| Noldorin | spiv, right | 21:46 |
| AuroraBorealis | what should i include in a bug report for bzr explorer? | 21:46 |
| AuroraBorealis | just my bzr log? | 21:46 |
| Noldorin | spiv, so wouldn't it be easier just to patch the source rather than do a plugin? | 21:46 |
| Noldorin | spiv, since i'd really want to modify the metadata structure. otherwise it owuld work too differently to an intended working version | 21:46 |
| spiv | Hmm, much of it would be the same, and it would probably avoid requiring a new repo format if you did it as a plugin that used a secondary store. | 21:47 |
| Noldorin | spiv, yeah, we'll see... | 21:48 |
| Noldorin | brb for now | 21:48 |
| spiv | I guess it would be easier to patch bzr proper, but it's also harder for people to test a patch | 21:48 |
| Noldorin | cheers for the info | 21:48 |
| Noldorin | spiv, yeah, so it might not get known as quickly | 21:48 |
| Noldorin | hmm | 21:48 |
| Noldorin | i'll consider. bye for now | 21:48 |
| spiv | And I don't think it would be *that* much easier. | 21:48 |
| spiv | I might be wrong :) | 21:48 |
| putrycy | hi! Let's assume that I am working on some project. In some point in the past I gave the source to my friend. He has been coding and how he is sending the modified source to me. In the meantime I made some changes too | 22:04 |
| putrycy | what is the simpliest way to merge? | 22:04 |
| putrycy | From my point of view of course | 22:04 |
| spiv | putrycy: how did they send the modified source to you? | 22:05 |
| putrycy | only source files | 22:05 |
| spiv | Ah. | 22:05 |
| putrycy | they don't have access to the repository | 22:05 |
| spiv | Ideally you'd have been using bzr branches from the start. | 22:05 |
| putrycy | nor they use bazaar | 22:05 |
| putrycy | so, I should make a branch usning the received source files? | 22:06 |
| spiv | Still, in your case the best you can do is basically make a branch starting from the revision they started from | 22:06 |
| spiv | (i.e. 'bzr branch -r 1234 my-branch friend-branch') | 22:06 |
| spiv | then in friend-branch apply their changes (copy their version of the source files into it) | 22:07 |
| spiv | then commit that, and then use 'bzr merge' to merge that back into my-branch | 22:07 |
| putrycy | OK, I get it, thank you very much | 22:08 |
| putrycy | btw isn't there anything like patch in bazaar? | 22:08 |
| spiv | You're welcome. | 22:08 |
| spiv | Sure, the 'bzrtools' plugin adds a 'bzr patch' command | 22:08 |
| putrycy | and does it resolve my problem too? | 22:08 |
| spiv | But you said you had entire source files, not patches? | 22:09 |
| putrycy | yes, of course | 22:09 |
| putrycy | just looking for the simpliest way to merege | 22:09 |
| putrycy | It would be perfect If I could make patch using the source tree and the branch from that they started development | 22:10 |
| putrycy | and then just apply the patches | 22:10 |
| spiv | Sure, you can use 'bzr diff' to generate patches, but I don't think it'd be easier (I don't think it'd be significantly harder either) | 22:10 |
| spiv | If you already have patches, then just applying the patches is almost certainly the way to go. | 22:11 |
| putrycy | I have to try out both to find out... | 22:11 |
| sidnei | so, how easy is it to split a bzr branch while keeping history? | 22:22 |
| putrycy | yesterday i noticed some strange (for me) bahaviour: bzr didn't want to add any files to the repository if there was a .svn directory in the same director what an added file | 22:30 |
| putrycy | could somebody explain it to me? And how to overcome it? | 22:30 |
| dupondje | https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/809048 any idea whats broken ? | 22:39 |
| ubot5` | Ubuntu bug 809048 in bzr (Ubuntu) "bzr crashed with AttributeError in stopTest(): '_TypeEqualityDict' object has no attribute 'clear'" [Undecided,New] | 22:39 |
| lifeless | dupondje: what python version ? | 22:44 |
| lifeless | putrycy: you have bzr-svn installed | 22:44 |
| lifeless | putrycy: so that is detecting you have an svn checkout there and is working with that instead | 22:45 |
| dupondje | Python 2.7.2+ (default, Jul 10 2011, 09:48:58) | 22:46 |
| dupondje | ubuntu oneiric | 22:46 |
| lifeless | dupondje: I suspect testcase.__dict__ isn't what it used to be in earlier pythons ;) | 22:47 |
| poolie | hi all | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!