| james_w | the bug on the nightlies was that they didn't build them at all | 00:00 |
|---|---|---|
| james_w | pyrex wasn't installed because the usual debs don't need it as the tarballs contain the c files | 00:01 |
| lifeless | oh! | 00:01 |
| lifeless | righto | 00:01 |
| james_w | I fixed that, but neglected to check the paths | 00:01 |
| lifeless | so, can you check then, that the so's are going to the right place | 00:01 |
| lifeless | and if they aren't make the build fail | 00:01 |
| james_w | just looking now | 00:01 |
| lifeless | / workaround | 00:01 |
| lifeless | I'd rather the dailies fail if the .so's won't be available to the user. | 00:02 |
| james_w | todays uploads have python*/*-packages/bzrlib/*.so | 00:04 |
| lifeless | thats great | 00:04 |
| james_w | I can add a check that that glob matches something at build time | 00:04 |
| lifeless | please | 00:04 |
| lifeless | look for one of the pyrex based ones | 00:05 |
| lifeless | Noldorin: http://pastebin.ca/1533156 | 00:06 |
| ronny | sup | 00:10 |
| ronny | lifeless: what are the current plans for python3 support? | 00:10 |
| Noldorin | lifeless: same result | 00:10 |
| lifeless | ronny: there aren't any | 00:10 |
| lifeless | Noldorin: can you paste the output please? | 00:11 |
| Noldorin | sure | 00:11 |
| lifeless | ronny: by which I mean, that we'll accept patches making it easier to use a porting tool etc | 00:11 |
| Noldorin | lifeless: http://pastebin.ca/1533161 | 00:11 |
| lifeless | ronny: but we need to keep supporting python 2 for 5 more years or so | 00:11 |
| lifeless | ronny: and python 3 is basically a different language/platform | 00:11 |
| lifeless | Noldorin: _wow_ | 00:12 |
| lifeless | Noldorin: can you do that again, with -Dtransport please | 00:12 |
| Noldorin | sure | 00:12 |
| Noldorin | indeed, it is behaving rather unusually :P | 00:13 |
| Noldorin | lifeless: http://pastebin.ca/1533166 | 00:15 |
| Noldorin | lifeless: making any sense to you? | 00:20 |
| lifeless | Noldorin: yes, look at lines 33, 34, 35 | 00:21 |
| lifeless | we read a file twice | 00:22 |
| lifeless | then get an error renaming the directory above it | 00:22 |
| lifeless | I suspect this is just too much damage to reliably work around it | 00:22 |
| lifeless | showing that trace to your sysadmins should convince them something is wrong pretty quickly :) | 00:22 |
| lifeless | I'll update the bug with more info | 00:22 |
| Noldorin | heh, fair enough | 00:23 |
| Noldorin | thanks :) | 00:23 |
| lifeless | and do whatever I can to help them get to a cause | 00:23 |
| Noldorin | lifeless: do you recommend i just point the admins to the bug report, or specifically this trace? | 00:23 |
| lifeless | Noldorin: both I suspect | 00:25 |
| Noldorin | right | 00:26 |
| Noldorin | not sure what i can expect them to do however :( | 00:27 |
| Noldorin | if the problem is due to IIS6 | 00:27 |
| lifeless | IIS has many options | 00:27 |
| lifeless | it could be a backing server | 00:27 |
| lifeless | they can file a bug with microsoft | 00:27 |
| lifeless | etc | 00:27 |
| lifeless | I wouldn't want to assume they can't do anything ;) | 00:27 |
| Noldorin | yeah, i know | 00:28 |
| Noldorin | it certainly doesn't heart to try | 00:28 |
| Noldorin | it's just i'm not optimistic! | 00:28 |
| Noldorin | but yeah | 00:28 |
| Noldorin | if you could update the bug report with the new info, that would be great :) | 00:28 |
| lifeless | I will be doing so shortly | 00:29 |
| Noldorin | great | 00:29 |
| Noldorin | the latest -Dtransport trace should really be attached there, of course | 00:30 |
| spm | *** FYI. restarting codehosting for a Cherry Pick *** | 00:47 |
| JoaoJoao | Hello | 00:52 |
| lifeless | hai | 00:53 |
| JoaoJoao | So, when I cancelled a bzr merge, when I tried the same bzr merge, bzr complained about already existing upload packs | 00:54 |
| Noldorin | lifeless: i have to go now, but i plan on emailing my host tomorrow. | 00:56 |
| Noldorin | if the bug report will be updated by then, that would be helpful | 00:57 |
| Noldorin | anyway, i'll let you know the result. | 00:57 |
| JoaoJoao | it looks like it's related to the bug https://bugs.launchpad.net/bzr/+bug/165293 | 00:58 |
| ubottu | Ubuntu bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed] | 00:58 |
| Noldorin | lifeless: is that alright...? if you're busy, i could always update it myself. but i feel you understand the issue significantly better than me | 01:01 |
| lifeless | Noldorin: Its in my queue to update | 01:04 |
| Noldorin | :) | 01:04 |
| Noldorin | right ho | 01:04 |
| Noldorin | bye | 01:04 |
| lifeless | JoaoJoao: you hit ctrl-C while bzr was doing the merge? | 01:04 |
| JoaoJoao | yep | 01:06 |
| lifeless | ok, I suspect you've found/provoked a bug in the final insertion stage | 01:07 |
| lifeless | what repo do you have - info -v will tell you | 01:07 |
| lifeless | it prints a repository line | 01:07 |
| lifeless | Noldorin: bye ;) | 01:08 |
| JoaoJoao | you mean the format? | 01:08 |
| JoaoJoao | it's 2a | 01:09 |
| lifeless | ok | 01:09 |
| lifeless | bzr dump-btree .bzr/repository/pack-names | 01:10 |
| lifeless | pastebin the output (its not personal) | 01:10 |
| lifeless | JoaoJoao: ^ | 01:24 |
| lifeless | igc: could I beg three reviews off you? | 01:30 |
| lifeless | https://code.edge.launchpad.net/~lifeless/bzr/bug-398668/+merge/10288 | 01:30 |
| lifeless | has two reviews listed in the last comment | 01:30 |
| lifeless | and after that, the main branch itself | 01:30 |
| * lifeless foods | 01:33 | |
| JoaoJoao | lifeless: I'm not at the computer with the repo, I'll post that tomorrow, ok? | 01:35 |
| lifeless | ok | 01:35 |
| === thumper is now known as thumper-afk | ||
| lifeless | bbiab | 02:05 |
| * igc lunch | 02:58 | |
| [1]reggie | anyone got a second to answer a question about bundles? | 03:22 |
| bob2 | best to just ask | 03:22 |
| [1]reggie | sorry | 03:22 |
| [1]reggie | our commit messages have a bundle file attached. I uncommitted some revs and then reverted them (mistake). now I want to reapply from the bundles | 03:22 |
| [1]reggie | but when I save a bundle file to my desktop and then do bzr merge <bundle file> it just says nothing to do | 03:23 |
| [1]reggie | this is bzr 1.1 | 03:23 |
| [1]reggie | 1.17 | 03:23 |
| [1]reggie | I thought the bundle file contained the "diff" of the revision and it could be applied right from the bundle | 03:24 |
| jam | [1]reggie: if you are getting 'nothing to do' that probably means the changes are already merged (by ancestry, if not by diff) | 03:29 |
| jam | I'm not user about "uncommitted some revs and then reverted them" | 03:29 |
| jam | if you reverted some changes and then committed | 03:29 |
| jam | then I would see how you would get the behavior you are seeing | 03:30 |
| jam | *uncommit* should remove them from the ancestry, such that 'bzr merge' will re-apply it. | 03:30 |
| [1]reggie | jam, could the problem be the encoding of the bundle? it's not a readable diff. it's encoded for email | 03:30 |
| [1]reggie | does merge handle the unencoding or do I have to do that? | 03:30 |
| jam | [1]reggie: possible. If we can't detect that it is a real bundle, then we would probably try to merge the containing dir | 03:31 |
| jam | though last I looked at the code, it would read through as much as it could to find the # Bazaar bundle ... header | 03:31 |
| jam | even if it was in the middle of an email | 03:31 |
| jam | (inline vs attachment) | 03:31 |
| lifeless | I suspect a commit-of-the-revert rather than an uncommit | 03:31 |
| jam | [1]reggie: so my initial thought is that you didn't uncommit as much as you thought you did | 03:31 |
| lifeless | so the bundle is already merged, as jam says above | 03:31 |
| [1]reggie | i basically did several bzr uncommit --local | 03:32 |
| jam | [1]reggie: there is also the possibility that you could pull the revision-id directly from the bundle | 03:32 |
| [1]reggie | and then a bzr revert | 03:32 |
| jam | [1]reggie: uncommit --local will be negated by you next 'bzr update' | 03:32 |
| jam | *your* next | 03:32 |
| jam | since you didn't uncommit the remote revs | 03:32 |
| [1]reggie | jam, ok, sorted some things out but I hit a new snag | 03:53 |
| [1]reggie | the uncommit command told me that I coudl restore to this tip by running a certain bzr pull command | 03:53 |
| [1]reggie | but I neve rpushed the commits that I uncommitted | 03:53 |
| [1]reggie | and when I run the pull command it says the branches have diverged and I need to run bzr merge | 03:54 |
| [1]reggie | but bzr missing says I'm up to date and bzr merge says nothing to do | 03:54 |
| [1]reggie | I thin it is confused | 03:54 |
| jam | [1]reggie: are you doing "bzr merge . -r revid:..." ? | 03:54 |
| jam | not just plain "bzr merge" | 03:54 |
| [1]reggie | the command it gave me to run was bzr pull . -r revid:reggie.burnett@sun.com-20090817220415-3vg2w7n0a46u09jj | 03:55 |
| [1]reggie | but that says 'these branches have diverged' | 03:55 |
| jam | [1]reggie: because you've done commits since the uncommit, the histories have diverged | 03:57 |
| jam | you can do "bzr merge . -r revid:reggie.burnett@sun.com-20090817220415-3vg2w7n0a46u09jj" | 03:57 |
| === thumper-afk is now known as thumper | ||
| RenatoSilva | Instead of keeping a changelog file for changes in software releases, I want to keep a changes_from_previous file, that is, a changelog for the current release only, so that each changeset would be a revision of that file matching the related release. What do you think, is it a good idea? | 04:41 |
| doctormo | I wanted to ask if it's possible to warn someone if they are about to commit a forbiden (or highly questionable) file type, such as pdf, doc, jpeg. We want to make sure our learning courses for ubuntu have only the sources. | 04:56 |
| lifeless | yes, a precommit hook can do policy checks and abort commits that fail $whatever-your-policy is | 04:58 |
| doctormo | useful | 04:59 |
| spm | doctormo: fwiw, if you go down that path - don't just rely on "*.(pdf|jpg)" for example; Suggest you use file(1) against the suspect. Assuming I'm not telling you stuff you didnt already know. :-) | 05:07 |
| doctormo | spm: This is an offical Ubuntu project to teach people how stuff works, the course writers will need help understanding bzr to get into development. I was thinking gtk-bzr | 05:08 |
| === thumper is now known as thumper-afk | ||
| johnjosephbachir | if both branches and checkouts can be branches, what is the value of having a mirror branch vs a mirror checkout? | 06:45 |
| johnjosephbachir | s/can be branches/can be branched | 06:45 |
| ronny | johnjosephbachir: branches carry the history along | 06:46 |
| ronny | checkouts just point to it | 06:46 |
| johnjosephbachir | so do non-lightweight checkouts | 06:46 |
| johnjosephbachir | they carry all the history | 06:46 |
| fullermd | If you're never committing to it, there's no significant difference. | 06:47 |
| bob2 | if you are, the default merging behaviour differs | 06:47 |
| fullermd | Though of course, you can't really branch a checkout. When you think you are, you're branching a branch, which you find by pointing at a checkout of it. | 06:47 |
| bob2 | 'bzr up' can do unpleasant things | 06:47 |
| johnjosephbachir | okay | 06:47 |
| vila | hi all | 07:03 |
| vila | hmpf, massive upgrade all around, massive reboots will follow :) bbar | 07:04 |
| spm | hey vila-massive-reboots! | 07:11 |
| gsuveg | re | 07:24 |
| gsuveg | i srtongly thinkig about write netbeans bzr plugin | 07:27 |
| lifeless | that would be great | 07:31 |
| gsuveg | i use netbeans | 07:31 |
| gsuveg | and doesnt exist bzr only git | 07:31 |
| === lionel_ is now known as lionel | ||
| vila | lifeless: inserting CountingDecorator has no effect (unsurprisingly but I checked anyway), do you still want it ? | 07:58 |
| lifeless | vila: it totally should for parallel=fork | 07:59 |
| vila | lifeless: yeah, we both wish, but it doesn't work | 07:59 |
| lifeless | do you get a progress bar? | 08:00 |
| lifeless | parallel=subprocess will add its own decorator. | 08:00 |
| vila | oh yes, I always have a pb, the # tests is missing though | 08:00 |
| lifeless | I mean a counter ;) | 08:01 |
| vila | yes, I got the counter but without indication of how many tests *will* be run, I can live with that for a while though | 08:01 |
| vila | it's better than not having it (man, 2 weeks without it... such a joy to get it back ;-) | 08:02 |
| lifeless | ok | 08:02 |
| lifeless | I did the better API | 08:02 |
| lifeless | it needs a review I think, in subunit. You could do that if you wanted ;) | 08:02 |
| vila | Already ? Great, I'll have a look | 08:02 |
| vila | lp:~lifeless/subunit/push-pop-progress ? | 08:03 |
| lifeless | something like that | 08:06 |
| lifeless | a week and a bit back actually ;) | 08:06 |
| vila | yeah. 20090808 sounds like that | 08:06 |
| * fullermd begins to lose hope that bundlebuggy will display the page... | 08:08 | |
| vila | lifeless: I still can't imagine when you can have a negative delta with PROGRESS_CUR, care to enlight me ? | 08:08 |
| vila | fullermd: wait for abentley to be bacl from vacations and restart his BB host ? | 08:09 |
| fullermd | Well, I don't so much have any _need_ to see it... | 08:09 |
| vila | stop hoping then :) | 08:10 |
| vila | but he's supposed to come back today... | 08:10 |
| fullermd | That's sorta my mantra. Everything's easier when you give up hoping :) | 08:10 |
| gsuveg | nono. hope is important | 08:10 |
| vila | I think the trick is not to give up but to accept that not all hopes can be fulfilled :) | 08:11 |
| vila | ... and keep smiling anyway (yeah, right...) :-D | 08:11 |
| fullermd | It takes more muscles to frown than to smile, but it doesn't take any to just sit there with a stupid expression on your face. | 08:14 |
| lifeless | vila: test filtering | 08:14 |
| vila | lifeless: ooooh, excellent, thanks | 08:17 |
| === Leonidas_ is now known as Leonidas | ||
| OllieR | will be a bzr up stop if a shell session is terminated/ | 08:40 |
| OllieR | ? | 08:40 |
| lifeless | OllieR: if it gets SIGHUP'd | 08:45 |
| lifeless | its up to your shell | 08:45 |
| OllieR | ok so yeah the update would fail? | 08:45 |
| OllieR | can you do a disown on that command then | 08:46 |
| bob2 | screen's easiest | 08:46 |
| OllieR | i tried but then it asks for a password and doesn't allow my input | 08:46 |
| OllieR | can't think how I would do it | 08:47 |
| fullermd | That's what nohup is for... | 08:47 |
| OllieR | ok but can i issue a password with nohup? | 08:49 |
| lifeless | I'd use screen | 08:50 |
| lifeless | :) | 08:50 |
| fullermd | nohup doesn't disconnect it from the terminal. It just blocks SIGHUP. | 08:51 |
| fullermd | Of course, it also may screw with std{out,err} and do other such manipulation, so something like screen can be a better choice (and for other reasons as well), but it's a simple choice. | 08:53 |
| OllieR | lifeless: thanks screen is ideal :) | 09:00 |
| === denys_ is now known as denys | ||
| * igc dinner | 09:09 | |
| === obstriege is now known as obst | ||
| === denys_ is now known as denys | ||
| thumper-afk | can we move cbranch into bzr.dev? | 09:43 |
| === thumper-afk is now known as thumper | ||
| thumper | it is the only reason I still have bzrtools | 09:43 |
| vila | thumper: You just don't like bzrtools, are you ? I knew it... | 09:49 |
| thumper | vila: I love it | 09:49 |
| thumper | I use cbranch and shelve | 09:49 |
| thumper | now shelve is in trunk | 09:49 |
| thumper | I want cbranch there too | 09:49 |
| thumper | because right now, bzrtools won't run with bzr.dev or the nightly ppa | 09:50 |
| thumper | which for me is a serious PITA | 09:50 |
| vila | Yeah, you want to empty bzrtools, you don't like it, stop pretending :-D | 09:50 |
| * vila is afraid the initial joke went unnoticed :-D | 09:50 | |
| pygi | vila, :P | 09:51 |
| vila | thumper: hmm, bzrtools still hasn't relaxed it's compatibility policy and refuse to load ? | 09:51 |
| thumper | no... | 09:52 |
| thumper | vila: I did notice | 09:52 |
| thumper | vila: I just ignored it :) | 09:52 |
| vila | thumper: abentley is coming back from vacations today right ? The patch is easy enough (jam used such a patched version to build the windows installers) | 09:52 |
| thumper | vila: oh, I'm sure it is simple | 09:53 |
| thumper | vila: but this isn't the first time things have gotten out of sync | 09:53 |
| thumper | vila: and since it is pretty trivial to make this right | 09:53 |
| thumper | vila: lets DTRT | 09:53 |
| vila | thumper: as for your initial question, past 2.0 the overall worflow UI will be reworked so certainly cbranch feature will be taken into account | 09:54 |
| lifeless | I wouldn't want to bring cbranch in before 2.0 | 09:54 |
| lifeless | and after 2.0, well as vila says theres a big overhaul to do | 09:55 |
| vila | thumper: ha ! You're preaching the chore (sp?) !! But try again with abentley :-D | 09:55 |
| thumper | well, we're almost there now anyway | 09:55 |
| thumper | I know, I know, I'm just frustrated | 09:55 |
| lifeless | thumper: talk to your wife about that :)\ | 09:55 |
| thumper | I'm running the 1.18 branch build locally instead of my system installed package | 09:55 |
| fullermd | vila: "choir". Though, for some of us, choir WOULD be a chore... | 09:56 |
| * vila giggles | 09:57 | |
| vila | fullermd: by the way, using merge proposals on LP is now the preferred way for submissions, | 09:58 |
| vila | fullermd: regarding your DWIM revisions, 1) using mp will ensure a better tracking, 2) it will certainly get more attention once 2.0 is out 3) Can't you try it as a plugin ? Such features are really hard to judge without using them for a while.... | 10:00 |
| fullermd | Well, that requires uploading a branch, rather than just sending a bundle. And that means either waiting forever, or stacking, and from all the fun stacking seems to be giving everyone for 2a upgrades... | 10:00 |
| vila | fullermd: bzr.dev is not in 2a (yet) and push is stacked by default on lp and works flawlessly, just give a try, really | 10:01 |
| fullermd | I don't see how it could work as a plugin, since it requires changing functions. | 10:01 |
| vila | *All* merge proposals (i.e. the vast majority of landed patches) for the last releases came from stacked branches on lp | 10:01 |
| vila | monkey patching ? | 10:01 |
| fullermd | Well, yeah. If it were in 2a already, issues stacking causes upgrading to 2a would be moot :) | 10:01 |
| fullermd | (and for changes like those trivial cleanups in revspec.py in my other [MERGE], it seems insane to create and upload branches for 3 lines of change) | 10:02 |
| fullermd | I'm vaguely aware of what monkey patching it, but I haven't the slightest idea how to go about it, nor would I want to if it were at all avoidable. | 10:03 |
| thumper | fullermd: pushing a stacked branch to lp is pretty quick | 10:03 |
| vila | you should talk to lifeless one of these days, he add some n lines patches (with n quite small) landed in no time with that | 10:03 |
| thumper | fullermd: also, when the merge directive stuff for 2a is sorted out | 10:03 |
| thumper | fullermd: you can use bzr send | 10:03 |
| thumper | fullermd: and LP will create the branch for you | 10:03 |
| OllieR | does anyone else get this. I commit a single character change in one file and I need to upload 3mb for the commit to finish. doesn't make any sense... | 10:04 |
| vila | thumper: hey ! Right I think the md stuff *is* sorted out (in trunk if not in 1.18), what email should be used ? | 10:04 |
| fullermd | It's still conceptual overhead of having a branch around, for a change I could write on my hand in ballpoint. | 10:04 |
| thumper | vila: well, LP needs to be updated for it to work | 10:05 |
| vila | fullermd: ho, come on, the point is how that branch/bundle is handled *once* you have created it | 10:05 |
| vila | thumper: ha, right, | 10:05 |
| fullermd | I'm also still ill at ease with the fact that the LP merge requests go off to the team, not the list. | 10:05 |
| thumper | vila: merge@code.launchpad.net | 10:05 |
| vila | thumper: thnks for the reminder, sry for being lazy :) | 10:05 |
| fullermd | Maybe with internal stuff that's no difference, but with something like the DWIM revspecs, which is a user-visible change, I'd sure like the opportunity for users on the list to be able to see and comment on it before it lands or is rejected. | 10:06 |
| vila | fullermd: right, I keep forgetting that, because, in my case, all the mp related mails are filtered in the same mailbox than the list :-/ | 10:06 |
| fullermd | I feel like the move to LP reviews really cuts off a lot of the chance for community desirability discussion. Maybe that's intentional. | 10:06 |
| vila | fullermd: not intentional !!!! | 10:06 |
| fullermd | Well, it is for me too ('cuz otherwise it ends up in the -bugs mailbox. Have I mentioned how much I hate LP's mail sending stuff lately?) | 10:06 |
| vila | eeerk, how can you imagine that :-( | 10:06 |
| fullermd | I don't, quite, but nobody seems at all concerned that essentially all the code reviews are no longer seen by anybody other than the devs and a few non-dev masochists like me who joined the team... | 10:07 |
| vila | I had some troubles to define my filters correctly but it's all godd now and *I* am quite happy with lp mails... | 10:07 |
| vila | fullermd: that's a good point, I really think every dev has more or less handle the filtering and don't realize that ... | 10:08 |
| vila | fullermd: there were talks at one point about tagging the mails and let people tweak some preferences in their subscription, I think it's worth raising the point again | 10:09 |
| OllieR | modified system/application/models/select_model.php (I added one word to this file) | 10:09 |
| OllieR | [###############- ] 9211kB @ 26kB/s | Uploading data to master branch - Stage:Copying content texts:Copied record 178/196 | 10:09 |
| OllieR | It just seems crazy | 10:09 |
| vila | fullermd: Anyway, overall, I'm convinced there is value in your DWIM rev spec and that surely is worth discussing and get more exposure, I was trying to give my understanding on the apparent lack on feedback so far | 10:11 |
| fullermd | OllieR: What protocol are you talking across? | 10:11 |
| OllieR | sftp:// | 10:11 |
| fullermd | So it's presumably repacking something, which requires downloading N% of the repo, then re-uploading it. | 10:12 |
| OllieR | fullermd: ok so is there any way to speed this up? | 10:12 |
| fullermd | If you can use a smart protocol, that should all happen server-side, and not have to shuffle the data across the network twice. | 10:12 |
| vila | OllieR: keep in mind that if it's indeed a repack that is occuring, it shouldn't occur frequently (1 every 10 then 100 then 1000 commits) | 10:14 |
| vila | OllieR: another option is to issue 'bzr pack' on the server side, but that also requires bzr on the server | 10:15 |
| lifeless | OllieR: its bzr doing autocompaction | 10:16 |
| lifeless | OllieR: it will happen very rarely, and it keeps the repository performance good | 10:16 |
| OllieR | fullermd: how do you mean a smart protocol? | 10:18 |
| fullermd | OllieR: bzr[+something]:// | 10:18 |
| domas | I just wanted to share how I am pleased with 'bzr co' grabbing 600M of RAM on my virtual machine :-)) | 10:20 |
| lifeless | domas: do you have the C extensions? they can help a _lot_ | 10:22 |
| domas | I hope I do, um. :) I guess I'd use PPA builds | 10:22 |
| OllieR | This is think is the problem | 10:27 |
| OllieR | checkout of branch: /home/bazaar/mycompany/example.com/screenings/trunk | 10:27 |
| OllieR | shared repository: /home/bazaar | 10:27 |
| OllieR | so every tree uses a single shared repository dispite the fact that they are usually not related | 10:28 |
| OllieR | i.e. /home/bazaar/mycompany/example2.com/web/trunk is completely different code to /home/bazaar/mycompany/example.com/screenings/trunk | 10:28 |
| OllieR | http://bash.pastebin.com/m646edb67 - 7gb repo | 10:31 |
| OllieR | Could anyone advise on this setup? | 10:33 |
| fullermd | Well, it sounds like a situation where you (not necessarily you personally, but you somebody-associated) control the server. So using bzr+ssh instead of sftp probably wouldn't be all that hard. | 10:35 |
| fullermd | And it would certainly mitigate issues like this by not getting the network involved in stuff it doesn't have to be. | 10:35 |
| OllieR | i just ran a bzr pack on the server and then committed again from my local system and it was a lot faster | 10:37 |
| OllieR | I will look into bzr+ssh | 10:37 |
| lifeless | OllieR: the pack didn't make a difference :) | 10:37 |
| OllieR | fullermd: do you know if having one shared repo for all projects is a bad idea? I would assume I should have a shared repo for each project... | 10:38 |
| lifeless | OllieR: the previous commit had already done the tuning :) | 10:38 |
| OllieR | lifeless: I cancelled the commit, as it was taking forever | 10:38 |
| OllieR | then can a pack on the server | 10:38 |
| lifeless | ah | 10:38 |
| lifeless | ok | 10:38 |
| OllieR | then committed from local | 10:38 |
| fullermd | OllieR: Well... it doesn't _gain_ you much, in cases where there's no shared history. | 10:39 |
| OllieR | fullermd: but it could potential slow things down? | 10:40 |
| fullermd | And at some level, it will slow things down, since there's a lot of data there you can't possible care about at any given moment, you've got more to troll through to find the stuff you do. | 10:40 |
| fullermd | Now, whether that's significant, is an empirical question... | 10:40 |
| fullermd | I'd say that putting repos at project boundaries makes more sense, since that's where most of your sharing is. | 10:41 |
| OllieR | yeah everything on this dev box seems to all of a sudden slowed right down | 10:42 |
| fullermd | I think it's axiomatic that one-repo-for-everything is going to be slower. But how much slower? If it's 2% slower, who cares? If it's 20% slower, that may be another matter. | 10:42 |
| fullermd | It seems unlikely for it to have caused a sudden dropoff, unless you just put something new and huge into it. | 10:43 |
| fullermd | A 300 meg project in a 7 gig repo is going to be slower than a 300 meg project in its own 300 meg repo. | 10:43 |
| fullermd | But it'll still be way faster than a 7 gig project in its own 7 gig repo. | 10:43 |
| OllieR | ok thanks for the info | 10:45 |
| lifeless | generally we have log tree depth | 10:46 |
| lifeless | so it shouldn't matter much | 10:46 |
| lifeless | 200+ way fan out on a typically B+Tree index in recent repo foramts | 10:46 |
| lifeless | which is to say, you need 200 times as much data to add a single additional level to the index. | 10:47 |
| === beuno_ is now known as beuno | ||
| === vila is now known as vila-fud | ||
| === vila-fud is now known as vila | ||
| andrea-bs | Hello! How can I upgrade the working tree of a branch? | 13:04 |
| === mrevell is now known as mrevell-lunch | ||
| NEBAP|work | hi | 14:17 |
| NEBAP|work | I´m using bzr push to push the history to a location that is backed up daily | 14:17 |
| NEBAP|work | now using push with (X:\Folder\Folder) also uploads the working tree what I don´t need | 14:18 |
| NEBAP|work | what can I do to prevent doing this? | 14:18 |
| hmeland | See "bzr init-repo --no-trees". | 14:19 |
| NEBAP|work | so I should initialize the repo on the server at first? | 14:20 |
| hmeland | Yes, as a parent directory of wherever you're pushing your branch to. | 14:20 |
| hmeland | You can use e.g. a sftp:// URL to "bzr init-repo". | 14:21 |
| NEBAP|work | so sometimes push just pushes the history and sometimes it pushes the working tree, too, depending on the protocol? | 14:21 |
| hmeland | Depends on both the protocol you're pushing over (sftp, local file access, etc.) and how the destination has been set up prior to the push. | 14:23 |
| garyvdm | hmeland: you can also just do bzr remove-tree REMOTE_BRANCH | 14:23 |
| NEBAP|work | k | 14:24 |
| garyvdm | I meant NEBAP|work ^^ | 14:24 |
| garyvdm | NEBAP|work: I would do what hmeland suggested if you are pushing multiple branches. | 14:24 |
| NEBAP|work | so if I want to push to a non-existing local location without pushing the working tree, I should do: | 14:25 |
| NEBAP|work | bzr init-repo --no-trees | 14:25 |
| NEBAP|work | bzr push | 14:25 |
| NEBAP|work | ? | 14:25 |
| hmeland | You can use "bzr reconfigure --use-shared --with-no-trees X:\Folder\Folder" to convert your existing stand-alone branch to a shared repository without any working tree. | 14:25 |
| NEBAP|work | hmm | 14:26 |
| hmeland | NEBAP|work: Yes, with the appropriate target arguments. | 14:26 |
| NEBAP|work | using push with the ftp protocol automatically pushes only the history | 14:26 |
| NEBAP|work | does it create a shared repo automatically? | 14:26 |
| NEBAP|work | or is it still a standalone tree without the working tree? | 14:26 |
| hmeland | No, but updating the working tree over ftp isn't done, due to it being hard to detect whether there would be any conflicts. | 14:27 |
| NEBAP|work | k | 14:27 |
| NEBAP|work | so using ftp the push destination is still a standalone tree? | 14:28 |
| hmeland | Yes. You could then later do "bzr update" in a shell on the target host to update the working tree. | 14:29 |
| NEBAP|work | k | 14:29 |
| NEBAP|work | no that was just for info :) | 14:29 |
| NEBAP|work | just thinking which is the better solution, creating a shared repo and pushing to it | 14:30 |
| hmeland | Whereas that wouldn't do anything in a branch in a tree-less repo. | 14:30 |
| NEBAP|work | or deleting the working tree of the standalone puhs .. | 14:30 |
| NEBAP|work | s/puhs/push | 14:30 |
| NEBAP|work | would be good to offer an option to push without the working tree like "bzr push --no-trees" | 14:34 |
| jam | morning all | 14:42 |
| jam | fjalvingh: are you around? | 14:42 |
| jam | vila: how's it going? | 14:42 |
| vila | morning jam ! | 14:43 |
| fjalvingh | jam: morning, Jam | 14:43 |
| NEBAP|work | jam: morning | 14:43 |
| vila | going fine, but I reailzed time is running and I tsill haven't reviewed 1.19-merge_sort :-/ | 14:43 |
| jam | vila: I was wondering about that. as I made sure to submit it before you woke up, and yesterday you said "I'm ready to review" :) | 14:45 |
| vila | jam: yeah, went into balancing --parallel=fork and ran into bumps... mutli-thread debug is so fun ;) | 14:46 |
| vila | jam: and besides, when i said "ready to review", I had actually reviewed most of your commits, but you added ~15 more :-) | 14:58 |
| vila | jam: overall you added new implementations in tsort, leaving the old ones without deprecating them, right ? | 15:04 |
| vila | hmm, not really :-/ | 15:05 |
| jam | vila: I moved tsort.topo_sort, but not merge_sort | 15:05 |
| jam | I don't want to implement 'mainline_revs' | 15:05 |
| jam | and some other stuff | 15:05 |
| jam | because it is cruft | 15:05 |
| jam | And there is at least 1 place that needs to add a node to the graph | 15:05 |
| jam | before calling merge_sort | 15:06 |
| jam | so I need that functionality before I can completely deprecate the existing implementation. | 15:06 |
| vila | yeah, re-reading your cover letter, sorry for the noise | 15:06 |
| Stavros | hello | 15:07 |
| Stavros | i have a bunch of commits in my repo which I did, but different computers show different names. can i change them? | 15:07 |
| === abentley1 is now known as abentley | ||
| vila | abentley: welcome back ! | 15:10 |
| abentley | vila: Thanks! | 15:10 |
| Stavros | any idea how i can change my email address retroactively in commits? | 15:13 |
| vila | Stavros: short answer: you can't | 15:13 |
| Stavros | aw | 15:13 |
| Stavros | long answer? | 15:13 |
| vila | there were talks about 3 distinct solutions (none fully available yet AFAIK): | 15:14 |
| vila | 1) use some variation of bzr-rebase | 15:14 |
| vila | 2) handle some aliases in bzr so that the same user can be "credited" for all his emails | 15:15 |
| vila | 3) fast-export, hack hack, fast-import (this is rude :) | 15:15 |
| quicksilver | write a script which rebuilds your repo one commit at atime | 15:15 |
| quicksilver | saving commit messages but altering email addresses | 15:16 |
| quicksilver | and also changing your boss's name to BADGER BADGER BADGER BADGER BADGER, just because you can. | 15:16 |
| Stavros | hmm, can i export the repo in a format i can easily parse and substitute the emails? | 15:16 |
| luks | which is what the fast-import/export method does | 15:16 |
| Stavros | quicksilver: i am the boss :( | 15:16 |
| Stavros | so i'll go with MUSHROOM | 15:16 |
| vila | Stavros: LOL | 15:16 |
| Stavros | what's fast-export/import, btw? | 15:16 |
| Stavros | also, is bzr-rebase useful/mature/stable? | 15:17 |
| luks | http://bazaar-vcs.org/BzrFastImport | 15:17 |
| luks | and yes, it is | 15:17 |
| vila | https://edge.launchpad.net/bzr-fastimport | 15:17 |
| Stavros | oh aha, interesting | 15:18 |
| Stavros | let me get that | 15:18 |
| Stavros | hmm, i need to run something other than setup.py install? | 15:19 |
| fjalvingh | Stavros: you might just do bzr branch lp:bzr-fastimport fastimport into your bzr plugins dir | 15:21 |
| Stavros | ah right, thanks | 15:21 |
| Stavros | how can i get the branch without the repo? | 15:22 |
| fjalvingh | Stavros: lp: means get repo from Launchpad? | 15:22 |
| Stavros | yes, i mean get just the "clean" copy, without the .bzr dir | 15:23 |
| Stavros | i guess i can just delete it afterwards | 15:23 |
| fjalvingh | Stavros: just remove the .bzr afterwards. | 15:23 |
| Stavros | thanks | 15:23 |
| fjalvingh | Stavros: It won't hurt though and you can easily update later on | 15:23 |
| Stavros | that is true, i should redownload it | 15:24 |
| vila | Stavros: or you can use 'bzr export' to get a clean tree | 15:24 |
| fjalvingh | Stavros: just "bzr pull" inside the branch | 15:25 |
| vila | Stavros: but why do you want that ? | 15:25 |
| Stavros | vila: OCD :P | 15:26 |
| vila | Stavros: ha, good, fine, no problem, JDI :) | 15:26 |
| Stavros | what's jdi? | 15:27 |
| Stavros | also, i figure i can do bzr co lp:bzr-fastimport and then bzr up whenever i want to update | 15:27 |
| jam | Stavros: "just do it" | 15:27 |
| Stavros | ah | 15:28 |
| Stavros | hmm, this fast-export file is binary | 15:28 |
| Stavros | i was hoping for base64 encoding or something | 15:28 |
| Stavros | i can't edit this without breaking it.. | 15:29 |
| === abentley1 is now known as abentley | ||
| fjalvingh | Stavros: It is not really binary; it is text intermixed with blobs which can be binary | 15:29 |
| Stavros | fjalvingh: yes, but editing will break the blobs | 15:29 |
| fjalvingh | Stavros: Only if you edit inside them | 15:29 |
| Stavros | really? text editors can handle that sort of thing? | 15:30 |
| Stavros | should i use vim? | 15:30 |
| fjalvingh | Stavros: some can; you could also try something like sed or so | 15:30 |
| Stavros | ah, that should work very well | 15:30 |
| fjalvingh | Stavros: but before trying all this: be aware that this will make a new, idependent repo | 15:31 |
| fjalvingh | Stavros: so if you have other branches lying around merges will no longer work | 15:31 |
| Stavros | so i won't be able to push it to the parent repo any more? | 15:31 |
| jam | Stavros: well, you could push --overwrite, but otherwise no | 15:32 |
| fjalvingh | Stavros: only by overwriting. | 15:32 |
| Stavros | hmm | 15:32 |
| Stavros | that might be acceptable | 15:32 |
| Stavros | i will try | 15:32 |
| jam | Stavros: you basically say "this is the new ancestry, forget about the old" | 15:32 |
| Stavros | ah | 15:33 |
| Stavros | hmm | 15:33 |
| fjalvingh | Stavros: and one other thing: if you have renames followed by edits in the same commit (something common in Java) import will probably fail.. | 15:33 |
| Stavros | hmm, that shouldn't be the case, thanks for the heads up though | 15:34 |
| Stavros | it crashes with "cannot import name serializer", that's odd | 15:40 |
| Tak | hrm, is it normal for a pull to show all pulled changes as conflicts? | 15:40 |
| Stavros | Tak: not normal, but it can happen | 15:41 |
| Stavros | if you changed things, that is | 15:41 |
| igc | night | 15:42 |
| fjalvingh | igc: Good night | 15:42 |
| [1]reggie | bzr tag keeps giving me bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~mysql-clr-team/connectornet/6.1/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 15:43 |
| Tak | well, yeah, they're valid changes from upstream, but all the conflicts are empty for tree, with stuff in merge-source | 15:43 |
| Tak | so I'm not sure why they weren't just merged in | 15:43 |
| [1]reggie | I've done bzr lp-login <my login name> and then done bzr push --remember lp:<lp home of project> | 15:44 |
| [1]reggie | but bzr tag still is trying to use http instead of bzr+ssh | 15:44 |
| [1]reggie | what am I doing wrong? | 15:44 |
| Stavros | jesus, 1.17 is out? what am i doing with 1.13? | 15:45 |
| === mrevell-lunch is now known as mrevell | ||
| === abentley1 is now known as abentley | ||
| === cprov is now known as cprov-lunch | ||
| [1]reggie | nm, got it working | 16:00 |
| === wadesworld is now known as wade | ||
| === wade is now known as wadesworld | ||
| gus1 | So I just upgraded to jaunty ppa bzr (from normal jaunty bzr) and my stacked bzr-svn repo is complaining with "ERROR: SvnRepository(...) is not compatible with KnitPackRepository(...) different serializers". Is that some known problem? | 16:09 |
| === NfNitLoo` is now known as NfNitLoop | ||
| === deryck is now known as deryck[lunch] | ||
| === abentley1 is now known as abentley | ||
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| Etenil | Hello there | 17:43 |
| Etenil | I'm having a small problem with my repository | 17:44 |
| Etenil | I have a base code in the root directory | 17:44 |
| Etenil | and several independant applications that rely on the base code in sub-folders | 17:45 |
| Etenil | basically, I'd like to version the root directory and each sub-directory independently | 17:45 |
| Etenil | do you know how I could proceed? | 17:45 |
| fjalvingh | Etenil: You cannot, really. | 17:52 |
| Etenil | fjalvingh, really?? | 17:53 |
| Etenil | what should I do then? | 17:54 |
| Etenil | move my applications out of the common codebase? | 17:54 |
| fjalvingh | Etenil: In time there will be the nested trees extension. But it's progress is slow. | 17:56 |
| === beuno-lunch is now known as beuno | ||
| fjalvingh | What I did is just not to manage the root itself. | 17:56 |
| Etenil | yeah, that's what I did so far, but I need to have at least `index.php' in the root folder | 17:57 |
| fjalvingh | I created separate repositories/branches for the shared projects | 17:57 |
| === kiko is now known as kiko-fud | ||
| fjalvingh | Etenil: Hmm.. It might be that you can just branch /inside/ the root. | 17:58 |
| fjalvingh | So there are separate branches (not related) and the one is /inside/ the other | 17:58 |
| fjalvingh | The outer one has the directory for the inner one as .bzrignored | 17:58 |
| fjalvingh | Limitation would be that the inner branch always is a single directory which in turn contains the other dirs | 17:59 |
| Etenil | oh, so I could ignore each sub-folder that contains an app | 17:59 |
| fjalvingh | There is also something called the "config" extension/plugin but I don't use that one. | 17:59 |
| === cprov-lunch is now known as cprov | ||
| === Noldorin_ is now known as Noldorin | ||
| jenred | hello! Is it possible to revert a merge that hasn't been committed? | 18:21 |
| jenred | and if so how thx | 18:21 |
| beuno | jenred, yes, but theres no way to distinguish it from the changed you had that weren't committed yet (if you had any) | 18:22 |
| jenred | so I merged 2 branches and now I want to drop the branch that I just merged b/c their are too many conflicts | 18:23 |
| jenred | is there anything like a "unmerge" | 18:24 |
| beuno | jenred, jsut "bzr revert" should do it | 18:24 |
| jenred | ok I think that worked thanks! | 18:25 |
| garyvdm | jam: What does the "known" in KnownGraph refer to? | 18:44 |
| jam | garyvdm: we know the full ancestry | 18:46 |
| jam | versus Graph which tries to know as little as possible | 18:47 |
| garyvdm | jam: I see - So in that case It will work nicely for qlog :-) | 18:47 |
| jam | yep | 18:50 |
| vila | garyvdm: but keep in mind that it's a step (a significant one, but a step anyway), the final target is to make it lazy in the end :) | 19:04 |
| garyvdm | vila: Yes | 19:04 |
| garyvdm | jam, vila: Would a KnowGraph be mutable? I think for qlog to be lazy, It's going to run merge_sort every time it loads more of the graph. | 19:06 |
| jam | KnownGraph is not currently mutable | 19:07 |
| garyvdm | But it will have all of the graph that it wants merge_sort to look at loaded | 19:07 |
| vila | garyvdm: no, it's not intended to be mutable | 19:07 |
| jam | I plan to allow it to add new nodes on the end, probably not in the middle | 19:07 |
| garyvdm | jam: which end? | 19:07 |
| jam | also, the time for "KG.merge_sort()" is around 40ms for a bzr.dev tree | 19:07 |
| vila | garyvdm: I call it FullyKnownGraph in my head myself | 19:08 |
| jam | garyvdm: new revs, not old ones | 19:08 |
| garyvdm | jam: so if I load bits of the graph, just create a new KG every time some more is loaded? | 19:10 |
| garyvdm | Or us the old merge sort? | 19:10 |
| garyvdm | *ues | 19:10 |
| garyvdm | *use | 19:10 |
| jam | merge_sort won't give you the right answers without the whole graph | 19:12 |
| jam | new or old | 19:12 |
| jam | it needs all ancestors to know if a revision was merged earlier than now | 19:13 |
| garyvdm | jam: I plan to only do this if bzr-historycache is available. I will use merge_sort to just give me the info I need to lay out the graph, and get the revno from bzr-historycache. | 19:14 |
| jam | garyvdm: it gives wrong answers for the graph as well | 19:15 |
| jam | I can give specifics though it takes some drawing | 19:15 |
| garyvdm | If historycache is not available, I will only load the graph in 2 stages: mainline, and the whole graph | 19:15 |
| garyvdm | jam: in the order? | 19:16 |
| garyvdm | Loading the graph lazy is very complex! | 19:17 |
| jam | so, if you have a long lived branch, that gets merged at rev 10 and rev 20 | 19:17 |
| jam | the revs merged into 10 will show up underneath 20 | 19:17 |
| jam | if you haven't loaded the ancestry from 10 | 19:17 |
| jam | to know that they were first merged there | 19:17 |
| garyvdm | jam: I see. And there is know way to ensure that for rev a, you have loaded all the revisions that have rev a as a parent (other than loading everything :-() | 19:21 |
| jam | well there are ways, but nothing we store currently | 19:21 |
| * vila EODing by shaving 30% of selftest --parallel=fork execution time, YES :-) | 19:22 | |
| jam | gdfo is something that might work well here | 19:22 |
| * garyvdm goes to read up on what gdfo is | 19:22 | |
| jam | Greatest Distance From Origin | 19:22 |
| jam | it is part of the KnownGraph code | 19:22 |
| LarstiQ | not to be confused with Get The F Offline | 19:23 |
| jam | basically rev.gdfo = max(parents.gdfo) + 1 | 19:23 |
| jam | or Get The F Out | 19:23 |
| jam | but that is G*t*Fo | 19:23 |
| LarstiQ | jam: which is phonetically rather close when slurred in Dutch ;) | 19:24 |
| jam | it is pretty close in american english, too :) | 19:24 |
| jam | garyvdm: the idea is that if rev1.gdfo >= rev2.gdfo you know that rev1 cannot be an ancestor of rev2 | 19:24 |
| jam | we use it for the KnownGraph.heads() work | 19:25 |
| * garyvdm is digesting.. | 19:25 | |
| jam | anyway, it allows you to load some of the graph | 19:25 |
| jam | until you reach tips that have gdfo <= the one you have now | 19:25 |
| jam | since you know that the current one cannot be an ancestor of the others | 19:26 |
| jam | the main problem | 19:26 |
| jam | is that you need the whole graph to *compute* gdfo in the first place | 19:26 |
| jam | vila is trying to figure out how to record it properly | 19:26 |
| jam | as it interacts with ghosts ... poorly | 19:26 |
| garyvdm | And would need to be recomputed on merge? | 19:27 |
| jam | no | 19:27 |
| jam | the new revs change | 19:27 |
| jam | but gdfo is stable as long as *ancestors* don't change | 19:27 |
| garyvdm | I see | 19:27 |
| garyvdm | So I should hold of trying to make qlog graph lazy until that is done? | 19:28 |
| jam | i think you could lazily load a lot of things like revision info (I think you already do) | 19:29 |
| jam | but I wouldn't try to lazy load the graph itself | 19:29 |
| jam | I'll also note | 19:29 |
| jam | that in current circumstances, computing a node accurately seemed to take about 50% of the graph of bzr.dev anyway except in trivial cases | 19:29 |
| jam | stuff like 'brisbane-core' requires a lot of history to be searched | 19:30 |
| jam | though potentially that is easier with gdfo... not sure | 19:30 |
| jam | oh, and we have several cases where we merge in a plugin | 19:30 |
| jam | and a plugin's first rev is gdfo == 1 | 19:30 |
| jam | so we have to load the wholegraph again | 19:30 |
| jam | that said... | 19:31 |
| jam | I made loading the whole graph significantly cheaper | 19:31 |
| jam | OOo went from 33s => 10s | 19:31 |
| jam | bzr.dev from 1.5s => 300ms | 19:31 |
| garyvdm | Wow! | 19:31 |
| garyvdm | This was with KnownGraph? | 19:32 |
| garyvdm | Will that make it into 2.0? | 19:32 |
| garyvdm | jam: Yes - revisions are only loaded if they appear on screen. (Or if you do a search, all revisions are load.) | 19:32 |
| jam | just landed in bzr.dev | 19:33 |
| garyvdm | jam: :-) | 19:33 |
| jam | and merge sort is about 3x faster as well | 19:33 |
| jam | well, 8x if you don't count the time to build the KnownGraph | 19:48 |
| === kiko-fud is now known as kiko | ||
| lifeless | moin | 20:43 |
| lifeless | jam: I'm quite worried that this will regress shared repo cases | 20:46 |
| jam | lifeless: it does the same work we do now, just in a tighter loop | 20:46 |
| lifeless | jam: oh cool, so it doesn't load unreferenced nodes? | 20:46 |
| jam | lifeless: no | 20:47 |
| jam | it walks the ancestry, and just loops on ancestors present on the current btree page | 20:47 |
| lifeless | argh double negatives ;) | 20:47 |
| lifeless | jam: read your reply on the bug; thats really good | 20:55 |
| lifeless | jam: around? | 22:05 |
| jam | yeah, for now | 22:06 |
| lifeless | I need a quick incremental review, in about 3 minutes | 22:06 |
| lifeless | for landing 2a default | 22:06 |
| jam | k | 22:06 |
| lifeless | its stacking [again] | 22:07 |
| === oubiwann_ is now known as obiwann | ||
| RenatoCaelum | verterok: hi | 22:16 |
| james_w | Is there a value I could cache to know if the contents of the working tree have changed at all? | 22:17 |
| james_w | does the wt have a testament? | 22:18 |
| lifeless | james_w: tree.has_changes() | 22:19 |
| james_w | but I don't have the old tree | 22:20 |
| james_w | I was just watching my commit hook run the tests after I had just done a full test suite run | 22:20 |
| lifeless | I'll need more context here | 22:20 |
| james_w | it would be nice if my test runner could write something about the state out | 22:20 |
| james_w | then the hook could not bother running if the tree it was committing matched that state | 22:20 |
| james_w | would also solve an issue I have with package maintenance | 22:21 |
| lifeless | you can make a testament of any inventory; however the working tree inventory may not match disk at all | 22:21 |
| james_w | caching? | 22:22 |
| lifeless | reality | 22:22 |
| james_w | or wouldn't match the inventory of the revision tree it became? | 22:22 |
| lifeless | neither | 22:22 |
| james_w | ok | 22:22 |
| james_w | I'll ponder some more | 22:22 |
| lifeless | fields like size | 22:22 |
| lifeless | sha1 etc | 22:22 |
| lifeless | in a working inventory aren't synced with disk, and even if they were they could become dated asynchronously | 22:23 |
| james_w | well, it could force a disk scan couldn't it? | 22:24 |
| james_w | it's racy, but... | 22:25 |
| lifeless | even if it did, it can skew | 22:25 |
| lifeless | jam: ugh, I'm having to fix a totally unrelated bug to make this work :( | 22:27 |
| lifeless | jam: how would you feel about me landing this with the test_repository_clone_preserves.. test made KnownFailure | 22:27 |
| jam | james_w: not to mention partial commits, etc | 22:28 |
| jam | lifeless: "landing this" ? | 22:28 |
| lifeless | default 2a | 22:28 |
| jam | I don't see a 'test_repository_clone_preserves", do you mean "per_workingtree...test_clone_preserves" ? | 22:29 |
| lifeless | line 944 in per_repo/test_repo | 22:29 |
| james_w | jam: yeah, I would compare to the testament of the revision tree being committed, which should account for that sort of thing | 22:30 |
| lifeless | james_w: myself, I'd made the test suite faster to run | 22:30 |
| jam | :) | 22:31 |
| jam | james_w: I think you could generate a testament from the WT, but the internal code wouldn't do that. | 22:31 |
| james_w | I'm just seeing a version tracking system on one hand, and repeated work from not knowing whether something has changed on the other | 22:31 |
| jam | easier to stage a commit, and then validate off of that revision | 22:31 |
| lifeless | james_w: for an off the wall approach | 22:31 |
| lifeless | james_w: make all your test runs do a commit | 22:31 |
| lifeless | and uncommit if they fail | 22:31 |
| james_w | could work :-) | 22:32 |
| james_w | doesn't really help the packaging case, but neat idea anyway | 22:32 |
| james_w | as for faster to run, that solves it for one project, but not other cases | 22:32 |
| jam | lifeless: so I've at least tracked down the test. How is it failing? | 22:33 |
| jam | as it is actually a fairly common case we've run into because "bzr upgrade repo" doesn't upgrade the branches | 22:33 |
| lifeless | jam: firstly the whole thing is testing off stuff | 22:33 |
| james_w | thanks for your time | 22:34 |
| lifeless | """Cloning an unstackable branch format to a somewhere with a default | 22:34 |
| lifeless | stack-on stack-on branch upgrades branch and repo to match the target | 22:34 |
| lifeless | and honour the policy. | 22:34 |
| lifeless | """ | 22:34 |
| lifeless | my updated docstring | 22:34 |
| jam | lifeless: what would happen is your local repo was stackable, but the branch format was too old | 22:34 |
| jam | then pushing that to lp would fail | 22:34 |
| jam | because it tried to auto-upgrade the repo to abad format | 22:34 |
| lifeless | yes | 22:34 |
| lifeless | but | 22:34 |
| lifeless | that is still broken in trunk | 22:34 |
| lifeless | its just that the test happens to fail closed | 22:34 |
| lifeless | what we want is that when there is a policy pointing at a stackable branch, and the source repo-or-branch isn't stackable, that its upgraded to match | 22:35 |
| lifeless | further, when the source repo is incompatible (e.g. 2a) and the stacked-on is (say) 1.9, we want to not stack | 22:36 |
| lifeless | but there is a separate bug that it currently aborts | 22:36 |
| jam | so how is it failing at this point? versus the test passing today | 22:41 |
| lifeless | the test is changed slightly in my branch, but not enough | 22:42 |
| lifeless | the thing is that its broken today | 22:42 |
| lifeless | we actually use the default format /somewhere/ and so the target is often unstackable | 22:42 |
| lifeless | and the test doesn't notice | 22:42 |
| lifeless | when the default is changed, we end up with stackable much more often | 22:43 |
| lifeless | and the test against whether repo is stackable suddenly blows up | 22:43 |
| jam | lifeless: so last I checked, BzrDir.initialize_on_transport_ex() would create the repo format you requested, but always uses the default branch format. | 22:43 |
| lifeless | well, init_ex doesn't make a branch | 22:44 |
| jam | lifeless: it *does* use the default branch for the format and stacking checks | 22:44 |
| jam | which was a source of bogus "this format doesn't support stacking" messages in the past | 22:44 |
| lifeless | yes | 22:45 |
| lifeless | so, there is a broken code path | 22:45 |
| lifeless | we can either fix it, then land this default branch. or vice verca :) | 22:46 |
| lifeless | so | 22:46 |
| lifeless | specifically, there are 7 formats that don't update | 22:46 |
| lifeless | don't upgrade | 22:46 |
| lifeless | and the test was simply not noticing that they don't | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit3) | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit4) | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack1) | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack4) | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack3) | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit1) | 22:47 |
| lifeless | FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormat7) | 22:47 |
| jam | lifeless: so I'm not going to make you block forever on it. But I'll note things tend not to get fixed once they are marked KnownFailure | 22:50 |
| jam | I suppose for my balance point.... I'd probably go ahead | 22:51 |
| lifeless | I think I have a hacked up version | 22:51 |
| lifeless | its a bit heinous | 22:51 |
| lifeless | jam: re: KF - I know, but we can file bugs that are critical :) | 22:54 |
| lifeless | jam: | 22:56 |
| lifeless | http://paste.ubuntu.com/255402/ | 22:56 |
| lifeless | thats the change vs the branch you reviewed last night. | 22:56 |
| lifeless | I think it captures what we want more accurately. | 22:57 |
| jam | lifeless: you've got some serious typos in the docstring, one not introduced by you | 22:57 |
| jam | "to a somewhere" | 22:57 |
| jam | and then "stack-on stack-on branch" | 22:58 |
| lifeless | fixed | 22:58 |
| jam | the "if stack_on_format in... elif..." seems like it could really use a final "else" clause causing an exception | 23:00 |
| lifeless | mm | 23:00 |
| lifeless | you need a long list of formats that just work if you do that | 23:00 |
| jam | I don't quite understand why you don't just grab the BzrDir format and pass that in | 23:00 |
| jam | I suppose you are intentionally using a diff format? | 23:01 |
| lifeless | yes | 23:01 |
| lifeless | a stackable one matching the serializer | 23:01 |
| lifeless | the unlisted formats are already stackable | 23:01 |
| lifeless | and thus its a no-op really. | 23:01 |
| jam | lifeless: k, probably a comment then | 23:01 |
| lifeless | done | 23:02 |
| jam | lifeless: good enough then | 23:02 |
| lifeless | DoIt? | 23:02 |
| jam | yep | 23:02 |
| lifeless | thanks! | 23:03 |
| goneri | igc: Hi! Can I have you opinion on the branch I did against bzr-fastexport to fix #347729 ? | 23:18 |
| lifeless | igc s likely still asleep | 23:20 |
| lifeless | give him a couple of hours | 23:20 |
| goneri | lifeless: oh ok :) | 23:21 |
| lifeless | \o/ onto ascii | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!