| BasicOSX | hmm, test suite core dumping | 00:34 |
|---|---|---|
| lifeless | :( | 00:34 |
| BasicOSX | trying pristine pbuilder to make sure my environment isn't the problem | 00:34 |
| thumper | hi guys | 00:39 |
| thumper | if I have a branch that is stacked on another | 00:39 |
| thumper | how can I confirm (in a unit test) that the branch that is stacked doesn't have all the revisions? | 00:39 |
| thumper | a simple count of revisions in the branch's repository would suffice for the test case I guess | 00:40 |
| lifeless | stacked_branch.bzrdir.open_repository().all_revision_ids() | 00:42 |
| thumper | lifeless: ta | 00:42 |
| lifeless | stacked_branch.repository.all_revision_ids() | 00:42 |
| lifeless | set and difference kgo | 00:42 |
| lifeless | spiv: ping | 00:42 |
| spiv | lifeless: pong | 00:44 |
| lifeless | so jam and vila seem to not be fixed by the bug fix | 00:45 |
| lifeless | see last night around 11 | 00:45 |
| spiv | Hmm. | 00:48 |
| abentley | thumper: yes. | 00:49 |
| * spiv tries to reproduce | 00:53 | |
| spiv | lifeless: I can't reproduce; if I push that same bbc-1.14 branch with bzr.dev I get the error on pull, and if I push it with the fix branch I don't get the error. | 01:06 |
| lifeless | spiv: then I blame 'they didn't use the new branch' | 01:07 |
| spiv | lifeless: that's my guess. | 01:07 |
| spiv | It's possible that at the time vila pushed up the bzr.dev in LP was a bit different so as to tickle subtly different case, but that strikes me as unlikely. | 01:08 |
| lifeless | agreed | 01:12 |
| lifeless | vila: ping | 01:12 |
| lifeless | jam: ping | 01:12 |
| lifeless | ^^^^ | 01:12 |
| skip_m | hello - is this the place for bzr help? | 01:30 |
| lifeless | its a place ;) | 01:30 |
| skip_m | anyone will do - thanks ;-) | 01:30 |
| skip_m | I'm a *complete* bzr naif. Here's my problem. (Sorry if my terminology is wrong.) | 01:34 |
| skip_m | I branched mailman 2.1 awhile ago and made changes to one file, .../cron/gate_news. | 01:34 |
| skip_m | I then pushed that to launchpad. Now I want to make a mailman 2.2 branch and | 01:34 |
| skip_m | transfer all my changes to that branch. How do I do that? I have my mailman 2.1 | 01:34 |
| skip_m | branch and a pristine mailman 2.2 branch. My first change was at rev 1135. My | 01:34 |
| skip_m | last was at rev 1139. Do I just get a diff and apply it with patch or is there a more | 01:34 |
| skip_m | bzr-ish way to do that? | 01:35 |
| lifeless | cd mailman2.2; bzr merge $path_to_mailman2.1 | 01:35 |
| james_w | you could first try "bzr merge <your 2.1 branch with changes>" | 01:35 |
| james_w | depending on how mailman 2.1 and 2.2 are maintained this may do more than you want | 01:35 |
| james_w | if it's small things such as the version number you can revert them and commit | 01:36 |
| skip_m | Yeah, I just want *my* changes to the 2.1 branch | 01:36 |
| james_w | if it's huge then you want to cherry-pick | 01:36 |
| lifeless | skip_m: start by trying the simplest thing | 01:36 |
| lifeless | skip_m: if that grabs too much, use merge -r branch:lp:mailman/2.1.. $your-mailman2.1-branch | 01:37 |
| skip_m | The simplest thing for me is 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' but is that the correct way to do things? | 01:38 |
| skip_m | liefless: I don't understand the merge -r branch... thing. | 01:38 |
| lifeless | skip_m: it would figure out the 1134..1139 for you | 01:39 |
| lifeless | 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' is better written as 'bzr merge -r 1134..1139 ../mailman2.1' | 01:39 |
| skip_m | And if that merge command doesn't do what I want is there a way to easily revert it or do I just blow away my mailman2.2 repo and branch again? | 01:40 |
| lifeless | 'bzr revert' | 01:40 |
| skip_m | ok - skip holds his breath and gingerly types 'bzr merge -r 1134..1139 ../mailman2.1' RET | 01:41 |
| lifeless | have you tried just 'bzr merge ../mailman2.1' ? | 01:43 |
| skip_m | not so good. Something about 34 conflicts. To many files I didn't touch. bzr revert looks bad too. Time for 'rm -rf ; bzr branch ...' | 01:43 |
| skip_m | lifeless: no, i'll try that next. | 01:43 |
| lifeless | skip_m: huh, no need to rm -rf | 01:43 |
| lifeless | what did bzr revert do? | 01:43 |
| skip_m | it was ugly: | 01:44 |
| skip_m | % bzr revert | 01:44 |
| skip_m | - cron/ | 01:44 |
| skip_m | -D cron/gate_news.OTHER | 01:44 |
| skip_m | -D cron/spambayes.ini | 01:44 |
| skip_m | Conflict: can't delete cron because it is not empty. Not deleting. | 01:44 |
| skip_m | And I wound up with a mailman2.2 which had a 2.2 directory and an empty cron directory. | 01:44 |
| skip_m | It's all gone now. | 01:44 |
| skip_m | (should I be using pastebin or something for these little snippets?) | 01:45 |
| lifeless | skip_m: no, its fine | 01:45 |
| lifeless | anyhow, if you ever feel the need to rm -rf, just ask; you shouldn't ever get that wedged with bzr | 01:45 |
| lifeless | so, try 'bzr merge ../mailman2.1' | 01:45 |
| skip_m | lifeless: that's what people tell me about mercurial too. I think it probably boils down to me being an old fart. CVS and Subervsion are probably about all my feeble brain can handle. :-/ | 01:46 |
| lifeless | its the simplest, and often the right command to use | 01:46 |
| Ursinha | hey beuno :) | 01:46 |
| Ursinha | do you know if there's an equivalent in bzr to rebase in git? | 01:47 |
| lifeless | so all the conflict means is that there was a file (gate_news.OTHER) that bzr didn't put in cron, that would be permanently lost if bzr deleted the cron directory | 01:47 |
| lifeless | Ursinha: 'rebase' | 01:47 |
| Ursinha | hahaha | 01:47 |
| Ursinha | simple as that :) | 01:47 |
| Peng_ | It's a plugin, though, bzr-rebase. | 01:47 |
| Ursinha | oh, now I understand why I couldn't find it right away | 01:48 |
| Ursinha | thanks Peng | 01:48 |
| Ursinha | Peng_, even | 01:48 |
| Ursinha | and lifeless | 01:48 |
| lifeless | np | 01:48 |
| lifeless | skip_m: so, bzr doesn't delete cron and lets you decide how to handle the situation | 01:48 |
| lifeless | skip_m: how did 'bzr merge ../2.1' go for you ? | 01:50 |
| lifeless | (and when we say ../2.1, we mean the path to your patched copy of 2.) | 01:51 |
| spiv | (although, IIUC, it seems like a bug that revert doesn't implicitly mark conflicts as resolved, thus removing the conflict files, thus removing one common source of irritating and confusing "can't delete some_dir" conflicts) | 01:51 |
| skip_m | ok - i figured out what went wrong. I had INSTALL, FAQ, cron, ... in my mailman2.1 dir. When I branched in my mailman2.2 dir it created a 2.2 dir containing INSTALL, FAQ, cron, ... Doing a bzr merge there failed miserably. Next time around I mv'd 2.2/* and 2.2/.bzr* to . which then made mailman2.1 and mailman2.2 proper siblings. The merge worked *much better*: | 01:52 |
| lifeless | spiv: it does, but revert can conflict itself | 01:52 |
| skip_m | % bzr merge ../mailman2.1 | 01:52 |
| skip_m | +N cron/spambayes.ini | 01:52 |
| skip_m | M cron/gate_news | 01:52 |
| skip_m | Text conflict in cron/gate_news | 01:52 |
| skip_m | 1 conflicts encountered. | 01:52 |
| skip_m | I'm sure I can fix the gate_news conflict with no problem. | 01:52 |
| skip_m | Thanks for the help folks. Right now I'm off to the pool (swim, swim, swim - sure beats typing at the keyboard every now and then!!!) | 01:52 |
| skip_m | ciao | 01:52 |
| spiv | lifeless: any case that "bzr merge SOMETHING; bzr revert" doesn't Just Work smells odd to me. | 01:53 |
| lifeless | spiv: I agree; skip_m hadn't done that though :) | 01:54 |
| lifeless | the .orig file causing the conflict was the output of patch | 01:54 |
| lifeless | igc: could I bother you to get usertest to tell us if trunk has regressed in performance at all | 01:55 |
| lifeless | igc: what with the big merges yesterday | 01:55 |
| igc | lifeless: sure. I'm working on exactly that (great mind think alike) | 02:11 |
| igc | lifeless, spiv: some pain though ... | 02:11 |
| igc | bzr.dev 4266 can't branch Bob's 1.14rc branch :-( | 02:11 |
| igc | the AbsentContentFactor get_bytes_as bug | 02:12 |
| spiv | igc: grab it via http rather than bzr+ssh | 02:12 |
| spiv | as a workaround | 02:12 |
| igc | spiv: cool. I was about to try that | 02:13 |
| igc | spiv: just a reminder about how bad that bug is (not that you needed reminding) | 02:13 |
| igc | so spiv: how do I find http address for an lp branch? It's no longer in the UI? | 02:24 |
| igc | jml: ^ | 02:24 |
| spiv | igc: lp:~aa/bb/cc -> http://bazaar.launchpad.net/~aa/bb/cc | 02:24 |
| igc | thanks | 02:24 |
| thumper | igc, spiv, poolie: can we get some reviews of abentley's big branch for nested trees please? We don't want it to go stale again. | 02:38 |
| thumper | lifeless: you around? | 02:59 |
| thumper | lifeless: I have a stacking question | 02:59 |
| === timchen1` is now known as nasloc__ | ||
| lifeless | thumper: ask the question :) | 03:07 |
| thumper | lifeless: skype would be easier I believe | 03:08 |
| lifeless | spiv: I reckon land that fix | 03:08 |
| lifeless | thumper: ok | 03:08 |
| spiv | lifeless: hmm, yeah | 03:15 |
| davidstrauss | Any major bzr folks in the Bay Area? | 03:18 |
| lifeless | davidstrauss: thats SF right? | 03:31 |
| davidstrauss | lifeless: yes | 03:31 |
| davidstrauss | lifeless: I'm in SF for the week for Drupal.org sprinting, and I'm always looking to see friendly free software faces :-) | 03:31 |
| lifeless | davidstrauss: uhm, dunno :). robey pointer is there I think, but he's paramiko/loggerhead and other things, not so much a regular bzr person | 03:32 |
| davidstrauss | lifeless: I met with Aaron when I was in Toronto | 03:32 |
| lifeless | davidstrauss: I'd drop a mail to the list TBH | 03:32 |
| lifeless | or twitter or whatever | 03:32 |
| davidstrauss | lifeless: TBH? | 03:32 |
| davidstrauss | lifeless: I'll tweet it | 03:32 |
| lifeless | to be honest | 03:32 |
| davidstrauss | ok | 03:32 |
| davidstrauss | lifeless: thans | 03:32 |
| davidstrauss | lifeless: thanks | 03:32 |
| rockstar | igc, ping | 03:49 |
| igc | hi rockstatr | 03:53 |
| igc | rockstar^ | 03:53 |
| igc | thumper: sure, planning to review it RSN | 03:53 |
| * spiv -> lunch | 03:54 | |
| igc | thumper: just running some performance tests first so we know when 1.14 is better than 1.13 and --development is better than --1.9 | 03:54 |
| Peng_ | jelmer: Yay, you upgraded bzr-svn to btrees. :) | 03:55 |
| thumper | igc: great | 03:59 |
| * igc lunch - bbiab | 04:00 | |
| rockstar | igc, hi, for some reason, your response didn't turn my tab blue. | 04:04 |
| davidstrauss | If I branch a library into a subdirectly of tree and "bzr join" it, will I still be able to merge in upstream changes from the library's original branch? | 04:04 |
| davidstrauss | And, if so, how would I perform such a merge? | 04:05 |
| rockstar | igc, I'm integrating your revnocache into loggerhead. | 04:07 |
| rockstar | igc, and I'm can't think of a single use case for RevnoCache. | 04:07 |
| rockstar | igc, but I can see a use case of the opposite graph: {revid: revno} | 04:11 |
| rockstar | Er, I mean {revno: revid} | 04:16 |
| rockstar | igc, so I guess I have two questions: (1) how is RevnoCache supposed to be used, and (2) why use a tuple to describe a dotted revno? | 04:27 |
| igc | rockstar: so the secret to integrating revnocache is this: make sure loggerhead is getting the graph by using Branch.iter_merge_sorted_revisions() | 04:38 |
| igc | rockstar: there is no step 2 :-) | 04:38 |
| igc | rockstar: revnocache is about to be superceded by bzr-historycache btw | 04:39 |
| rockstar | igc, :( | 04:39 |
| igc | bzr-historycache will do the same thing but more | 04:39 |
| davidstrauss | Is --reference being dropped as an option to "join"? | 04:40 |
| thumper | davidstrauss: the nested tree stuff is actively being changed right now | 04:40 |
| rockstar | igc, so my RevGraphCache gets created with Branch.iter_merge_sorted_revisions() | 04:40 |
| thumper | davidstrauss: abentley is the man to ask | 04:41 |
| igc | rockstar: so revnocache had multiple ways of caching revnos - history will use just the best of those and be configurable as to whether it's on or not | 04:41 |
| davidstrauss | thumper: Currently, if I join a branch, I lose "common history" with the branch I joined from | 04:41 |
| igc | rockstar: yes | 04:41 |
| davidstrauss | thumper: I'll ask abentley | 04:41 |
| thumper | :) | 04:41 |
| igc | and the next call to it (or the next call to a dotted revno lookup) uses that cache | 04:41 |
| rockstar | igc, ah, so I was using all three types of cache, but it seems like RevGraphCache and a mapping of revno->revid should be all I need. | 04:41 |
| igc | rockstar: you want graph caching, I think it's called "revgraph" or something like that in revnocache | 04:42 |
| rockstar | igc, yea, RevGraphCache. | 04:43 |
| igc | ignore the others | 04:43 |
| rockstar | igc, yea. | 04:43 |
| igc | rockstar: I'm about a week away from releasing historycache | 04:44 |
| rockstar | igc, so, I also need to convert a stringified revno to a tuple revno for that graph. Is there a helper function for that, or do I create my own? | 04:44 |
| igc | I have some other things ahead of it in my queue, e.g. confirming the NG format is performing well on all use cases, reviewing nested trees, etc. | 04:44 |
| igc | rockstar: I'll look, but something like tuple(revnostr.split('.')) ought to go close | 04:46 |
| rockstar | igc, yeah, that's similar to what I was thinking. | 04:46 |
| igc | rockstar: so it turns out to be slightly more complex ... | 04:49 |
| igc | grab parse_revno from revnocache/revnocache.py | 04:49 |
| thumper | if I have an open branch, how do I get the transport for that branch? | 04:49 |
| igc | it would be nice to have that in the core I guess, so put up a patch if you get a moment | 04:50 |
| igc | rockstar: ^ | 04:50 |
| igc | rockstar: any other questions for now? I'm about to head into the other room where my desktop is for a while | 04:51 |
| poolie | hello igc | 04:51 |
| igc | hi poolie - welcome back! | 04:51 |
| poolie | thanks | 04:51 |
| igc | poolie: hope you had a great break | 04:52 |
| rockstar | igc, I don't believe so. I'm already pretty far along. | 04:52 |
| poolie | it was great, thanks | 04:52 |
| igc | rockstar: if you do, just put a message into IRC or email and I'll check back later | 04:52 |
| rockstar | igc, thanks for the help. | 04:53 |
| thumper | nm | 04:58 |
| === release is now known as samurai | ||
| sohail | how can I update my working tree to a specific revision? | 05:27 |
| BasicOSX | I'm not finding the "Register a release" under the 1.14 series, perms problem? vila ? poolie ? | 05:31 |
| poolie | hi BasicOSX | 05:31 |
| BasicOSX | hi, attempting to register 1.14rc1 and upload the .zip and tar.gz, but do not see the "Register a release" for 1.14 series | 05:32 |
| poolie | sohail: 'bzr pull -r 123 .' | 05:32 |
| poolie | BasicOSX: hm me either | 05:32 |
| BasicOSX | don't see it for 1.13 either :-( | 05:33 |
| poolie | BasicOSX: i think this changed in the last release of lp | 05:33 |
| BasicOSX | hmm, once I figure it out, I'll need to update the releasing documentation | 05:33 |
| BasicOSX | I see your Code for this series now | 05:34 |
| poolie | BasicOSX: maybe you need to add a milestone? | 05:34 |
| poolie | there was some work on fusing releases and milestones | 05:35 |
| BasicOSX | There is a 1.14rc1 milestone there already, let me look at it | 05:35 |
| poolie | http://blog.launchpad.net/coming-features/linking-project-releases-in-launchpad-to-milestones | 05:35 |
| lifeless | BasicOSX: you could ask in #launchpad | 05:38 |
| lifeless | some devs idle there ;) | 05:38 |
| skip_m | I get this message from bzr status: 'Text conflict in cron/gate_news' | 05:39 |
| skip_m | I took care of the conflicts in the source and deleted the cron/gate_news.<STUFF> files. Still the | 05:39 |
| skip_m | conflict message is there. How do I get rid of it? | 05:39 |
| SKArfaceGC | long time cvs user. . . been reading about and playing with bzr. Seems v.cool, is this an appropriate place to ask questions if I need help? (after researching first) | 05:39 |
| lifeless | SKArfaceGC: 'bzr resolve' | 05:40 |
| lifeless | sorry | 05:40 |
| lifeless | skip_m: ^ | 05:40 |
| SKArfaceGC | :) | 05:40 |
| lifeless | SKArfaceGC: sure it is | 05:40 |
| SKArfaceGC | cool. | 05:40 |
| lifeless | but not from me right, now | 05:40 |
| * lifeless heads to the shops ;) | 05:40 | |
| SKArfaceGC | Don't have any at the moment. just lurking | 05:40 |
| skip_m | lifeless: thanks | 05:40 |
| skip_m | In my mailman2.1 repo I have this push branch: | 05:42 |
| skip_m | bzr+ssh://smontanaro@bazaar.launchpad.net/%7Esmontanaro/mailman/SpamBayes/ | 05:42 |
| skip_m | Can I just push to it from my mailman2.2 branch without creating problems? | 05:42 |
| AfC | SKArfaceGC: you may want to know that both this channel and the project's mailing list are used jointly for user[s of bzr] as well as hacker[s working on the tool] discussion. So sometimes it can get a little esoteric | 05:42 |
| SKArfaceGC | I write large security software for a living. I can deal with esoteric. :) | 05:45 |
| sohail | poolie, thank you! | 05:46 |
| skip_m | I used bzr push --overwrite ... which seemed to work. If that was a bad thing, speak now or forever hold your peace. :-) | 05:46 |
| spiv | skip_m: push --overwrite will overwrite the history in that branch to be the same as the branch you are pushing from | 05:59 |
| spiv | skip_m: so if that's what you wanted to happen, then that's fine :) | 05:59 |
| skip_m | spiv: Thanks - that's fine. Mailman 2.1 is a dead end. I was asked to port my changes to Mailman 2.2. I officially no longer care about | 06:00 |
| skip_m | mm 2.1. | 06:00 |
| spiv | lifeless: btw, my fix branch failed because it adds one more get_parent_map call the stacked push acceptance test. | 06:00 |
| spiv | skip_m: sounds good then. | 06:00 |
| spiv | skip_m: (normally in that situation I would have merged 2.2 into my branch and committed that, in which case a regular push would work just as well as there is no divergence of history) | 06:02 |
| SKArfaceGC | hrm. . . are there any karma granting/branch locking hooks available? Something like sheila for CVS | 06:03 |
| skip_m | spiv: i know nothing about the possibly divergent histories of mm 2.1 and 2.2 (and don't really care). I just wanted to get my little enhancement out there for people to use. | 06:03 |
| lifeless | spiv: as it stands it has to | 06:07 |
| lifeless | spiv: so +1 to increasing the ratchet | 06:07 |
| === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14rc1 released 07 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| spiv | lifeless: that's my feeling too. Glad you agree :) | 06:08 |
| Peng_ | BasicOSX: Congrats on the release (candidate). :) | 06:11 |
| BasicOSX | long road traveled on this one.. thank you though | 06:11 |
| Peng_ | On a different subject, is it just me or do some of BasicOSX's gpg-signed emails fail verification? Like the 1.14rc1 announcement on the announce list. | 06:13 |
| BasicOSX | That's the 2nd time I've heard that. Seems to be only to mailing lists. | 06:15 |
| Peng_ | Oh, nice. | 06:15 |
| BasicOSX | First time was a user on Win32, so I, well, kinda ignored them | 06:16 |
| BasicOSX | tbird doesn't have the best pgp hooks | 06:16 |
| BasicOSX | (not that mail.app is any better) | 06:16 |
| * Peng_ is using Thunderbird + Enigmail | 06:17 | |
| BasicOSX | :-P | 06:17 |
| BasicOSX | On windows? :-) | 06:17 |
| Peng_ | No, an out-of-date Ubuntu box. :D | 06:17 |
| BasicOSX | sheesh bug reports coming in on 1.14rc1 already | 06:18 |
| Peng_ | I think several of you have been to bed and gotten up again while I've been awake. :\ | 06:20 |
| Peng_ | (Well, if you haven't, then you should be getting more sleep!) | 06:21 |
| spiv | lifeless: btw, I'm using ec2test. | 06:29 |
| BasicOSX | PQM playing 1.14rc1 back into bzr.dev, afk for dinner | 06:43 |
| lifeless | spiv: liking it ? | 06:45 |
| spiv | lifeless: it's neat, but it'll be much more likeable with the rough edges smoothed off :) | 06:53 |
| lifeless | spiv: thats true | 06:53 |
| lifeless | spiv: feel free to shave :) | 06:56 |
| igc | lifeless: any thoughts on bug 357478? | 06:57 |
| ubottu | Launchpad bug 357478 in bzr "development6-rr vs gc-chk255-big regressions" [Undecided,New] https://launchpad.net/bugs/357478 | 06:58 |
| lifeless | igc: none beyond my reply | 06:58 |
| igc | oh, I didn't see that - I'll look | 06:58 |
| vila | hi all | 06:58 |
| lifeless | hmm, I may not have disabled tree references enough | 06:59 |
| igc | hi vila | 07:06 |
| lifeless | spiv: +1 on any changes to ec2.test | 07:14 |
| lifeless | .txt | 07:14 |
| lifeless | spiv: possibly we should ask the source, or more-local of the repositories for the parents. | 07:17 |
| lifeless | spiv: or something | 07:17 |
| spiv | lifeless: yeah. It would be nice to have a good way of saying "get these {parents,revisions,whatever} from a set of repositories, but try the most local first". | 07:18 |
| spiv | It's a desire that comes up occasionally. | 07:18 |
| sabdfl | hello all, congrats on landing brisbane-core in trunk | 08:18 |
| sabdfl | two observations | 08:18 |
| sabdfl | commit after status seems really quick (delta over status is low) | 08:19 |
| lifeless | excellent | 08:19 |
| lifeless | that was one of the key things we were removing overhead on | 08:19 |
| lifeless | and thanks | 08:19 |
| sabdfl | explicit commit (commit file file file) seems slower than normal commit, which i don't understand since it doesn't have to check as much dirstate | 08:19 |
| sabdfl | and commit after add seem much slower than it used to be | 08:19 |
| lifeless | explicit commit: we can't use the new commit code path in all cases yet; we have to teach our core diff logic (iter_changes) to report parent directories in some cases, or you end up with a broken commit | 08:20 |
| sabdfl | aha | 08:21 |
| lifeless | this is one of the things we'll polish while its a beta format | 08:21 |
| lifeless | so you're seeing the older commit codepath when you do commit [paths..] | 08:21 |
| lifeless | doing commit -x path will trigger that too, as iter_changes hasn't been taught to do excludes | 08:21 |
| lifeless | commit after add: is it slower for both the initial commit, and later commits after adds, or just the initial one? | 08:23 |
| lifeless | the split inventory structure requires more calculation to create the initial tree than the old flat-file xml format (but it wins massively on subsequent commits as you're seeing) | 08:24 |
| lifeless | so another item of polish is to work on making that initial tree operation faster | 08:25 |
| lifeless | The old format just wants everything in the tree appended to a list, whereas the brisbane-core format builds a dictionary. That said, there is plenty of room for optimisation. | 08:28 |
| lifeless | BasicOSX: please do update NEWS in bzr.dev :) its in the process I thought.. | 08:46 |
| BasicOSX | I merged bzr.dev into my local branch, fixed up the conflicts, PQM'd it back, got a success | 08:47 |
| BasicOSX | merge lp:~tanner/bzr/1.14rc1 http://bazaar-vcs.org/bzr/bzr.dev | 08:48 |
| BasicOSX | Command was successful. | 08:48 |
| vila | lifeless: ec2 fix BB:approved, lowering (but not zeroing !) ec2 setup priority :) | 08:48 |
| BasicOSX | I did merge my lp branch "merged" so it doesn't show | 08:48 |
| BasicOSX | and a fresh branch of bzr.dev show my merge | 08:48 |
| lifeless | ok | 08:48 |
| lifeless | I've just not pulled in the last 40 minutes :P | 08:49 |
| BasicOSX | hmm, patch succeeded at 1:22am CDT | 08:50 |
| lifeless | fsvo 40 | 08:50 |
| lifeless | :P | 08:50 |
| vila | BasicOSX: bzr version now shows 1.14rc1 in bzr.dev ! | 08:51 |
| * BasicOSX hides | 08:51 | |
| lifeless | lol | 08:51 |
| BasicOSX | I'm bring down fresh, I'm sure I forgot something :-( last part of releasing documentation isn't very detailed (I'm fixing that) | 08:52 |
| lifeless | BasicOSX: when you merge back you need to preserve bzr.devs concept of being bzr.dev | 08:52 |
| lifeless | so its merge, tweak NEWS bzr bzrlib/__init__.py | 08:53 |
| BasicOSX | yes, my mistake | 08:53 |
| vila | BasicOSX: visual inspection bzr diff -c 4267 doesn't reveal anything else, you're doing good ! | 08:53 |
| vila | BasicOSX: I suspect you're bumping into many "it's so obvious it's not documented" points due to previous RMs being more experienced and you did a good job already updating the release process documentation, so, it's just part of it | 08:55 |
| BasicOSX | sadly, my free time is 11pm-3am, so the documentation is my double check when I'm sleepy | 08:57 |
| lifeless | well, the docs used to say to do this | 08:57 |
| lifeless | but perhaps lost at some point | 08:57 |
| BasicOSX | If it's not already done, advance the version number in bzr and bzrlib/__init__.py. Submit this back into pqm for bzr.dev. | 08:57 |
| BasicOSX | I read that as advance it from 1.13final to 1.14rc1 | 08:58 |
| lifeless | that line lies | 08:58 |
| lifeless | or | 08:58 |
| lifeless | is overly brief | 08:58 |
| BasicOSX | I got notes now, need to make sure it's 'dev' | 08:58 |
| lifeless | so advance means 'change 1.14dev to 1.15dev' | 08:59 |
| BasicOSX | ok, just need branch, it's 1,14,0,'dev',0, | 09:00 |
| lifeless | yup | 09:00 |
| lifeless | later all | 09:00 |
| BasicOSX | do I need to update bzr's _script_version too ? | 09:01 |
| vila | BasicOSX: yes, it's even surprising it isn't mentioning dev... | 09:06 |
| * BasicOSX winks | 09:15 | |
| BasicOSX | lifeless: beat me to pqm | 09:15 |
| BasicOSX | lp:~tanner/bzr/bzr.dev has my fix in it, if someone wants to verify | 09:16 |
| BasicOSX | v$ ./bzr --version | 09:16 |
| BasicOSX | Bazaar (bzr) 1.15dev | 09:16 |
| BasicOSX | 3:17am, sleep, email me if I need to work on other stuff I messed up :-) | 09:17 |
| vila | BasicOSX: good night ! | 09:18 |
| * igc dinner | 09:47 | |
| johnf | spiv: you about? | 09:50 |
| poolie | hello johnf | 10:11 |
| johnf | poolie: howdy | 10:12 |
| Mez | using the central repository model, is there an easy way to get the server to run a test suite every time something is checked inot the branch (or merged in, etc) | 10:55 |
| * Kinnison uses a pqm for that, perhaps a server-side commit hook? | 10:57 | |
| Bluehorn | Mez: PQM is here: https://launchpad.net/pqm | 11:13 |
| Bluehorn | *: Is there a way to aggregate multiple changes into a single revision in bzr? | 11:14 |
| Bluehorn | Background: I was messing around with bzr-gtk (not having used pygtk for a while) and would like to post the patch. | 11:14 |
| Bluehorn | But I don't think anybody would like to see the debugging code I originally had in there and the bzr misuse I did (created a conflict due to bzr push not updating the working copy). | 11:15 |
| lifeless | Mez: sure use a pre_branch_tip_change_hook | 11:16 |
| lifeless | Mez: (see bzr help hooks) | 11:16 |
| lifeless | Mez: pqm is not easy ;P | 11:17 |
| Bluehorn | lifeless: but it looks like an interesting concept ;-) | 11:17 |
| lifeless | Bluehorn: it is, and it works well, its just not easy ;) | 11:17 |
| Mez | lifeless: only through p1m? | 11:48 |
| Mez | lifeless: never mind, was reading something els.e | 11:48 |
| Mez | I'm actually looking for a post-hook, but something easy | 11:48 |
| lifeless | mail the list, its late for me, I'll whip one up for you tomorrow | 11:49 |
| Mez | thanks lifeless | 11:49 |
| ormandj | Hi, I am attempting to follow: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style however, I am unclear about the setting up the shared repository step. I did the setup mentioned at the "Starting a central branch" section a bit higher up, then followed the distributed setup, but after I make my feature branch, and try to merge ../trunk/ to the feature branch, it complains I have uncommitted chang | 12:41 |
| ormandj | es | 12:41 |
| ormandj | the documentation didn't make this clear what I should expect | 12:41 |
| lifeless | ormandj: you haven't committed your changes | 12:55 |
| lifeless | ormandj: you need to commit after you make a change to a branch | 12:55 |
| ormandj | lifeless: the documentation example didn't show the commits that's why i was confused about this | 12:55 |
| ormandj | it shows running the merge *before* committing | 12:55 |
| ormandj | ie: merge from the trunk to my new branch, then commit the merged changes along with my updates | 12:56 |
| ormandj | (i'm doing the distributed style setup described) | 12:57 |
| lifeless | well, the new branch has no changes in it when its just made; if you are getting told you have changes something odd is happening :) | 13:07 |
| === abentley1 is now known as abentley | ||
| xnevermore | Hey. I want to use bzr on my web server to keep web development projects organized. I'd like to have a main branch and a development branch, then my main public_html folder where i would pull from the main branch for deployment. What would this kind of workflow look like? | 13:50 |
| lifeless | it would look like a main branch, a development branch, and your public_html folder a third branch :) | 13:51 |
| lifeless | or you could use bzr-upload for deployment | 13:51 |
| xnevermore | so the main folder used to serve web pages to apache would be a bzr branch itself? or a mirror? or something else? | 13:52 |
| lifeless | most people seem to use bzr-upload for that folder | 13:53 |
| lifeless | its a plugin | 13:53 |
| LarstiQ | that is what I would advise | 13:53 |
| xnevermore | cool | 13:54 |
| xnevermore | i'll check that out | 13:54 |
| xnevermore | thank you | 13:54 |
| lifeless | vila: I've just sent a new [MERGE] request | 14:37 |
| lifeless | vila: which has the other stuff I was muttering about | 14:37 |
| vila | lifeless: ok, will have a look (by the way, the tests *were* passing here ;-) | 14:40 |
| lifeless | vila: not with my print intend change | 14:41 |
| lifeless | vila: your write() call wasn't indented | 14:41 |
| vila | lifeless: indeed, because I just copy/paste from my branch :) | 14:41 |
| lifeless | see ;) | 14:41 |
| vila | lifeless: doesn't really matter, it's just that we talked about it but it was never merged | 14:42 |
| lifeless | sure | 14:42 |
| lifeless | I think you'll like it | 14:42 |
| lifeless | vila: if you wanted to review it now, I could land it immediately ;) | 14:46 |
| vila | lifeless: I am | 14:46 |
| lifeless | thank :) | 14:47 |
| vila | BB:tweak, I think there is another atexit.register() you may want to get rid off, the one that delete the /tmp dir, plus some tests for done, startTests() :) | 14:50 |
| vila | or did I miss the tests ? | 14:50 |
| lifeless | well | 14:50 |
| lifeless | I moved code | 14:50 |
| lifeless | nothing 'new' really :) so existing tests should suffice | 14:51 |
| lifeless | if nothing was testing the output, then I haven't reduced the coverage; if it was tested, then I preserved the behaviour | 14:51 |
| vila | nothing 'new' but startTests() and done() just want to be extended/overriden :0) | 14:51 |
| lifeless | what sort of tests would you like to see? | 14:52 |
| vila | simplest ones: they are called once | 14:52 |
| vila | seeing the modification of InstrumentedTestResult made me think they should be trivial to add | 14:53 |
| jam | morning lifeless, shouldn't you be sleeping by now :) | 14:53 |
| lifeless | jam: yes | 14:54 |
| lifeless | vila: cut you a deal :) add some tests, land it ? :) | 14:54 |
| vila | deal | 14:54 |
| lifeless | cool - thanks | 14:54 |
| vila | More often than not I feel I want to do that for many reviews... | 14:54 |
| lifeless | with this, the output from selftest --parallel=forked looks like normal | 14:55 |
| vila | err, I hope you haven't addressed the tracebacks *during* execution :-) | 14:57 |
| lifeless | oh, you'll want https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/5346 | 14:57 |
| lifeless | for obvious reasons | 14:57 |
| lifeless | what tracebacks? | 14:57 |
| vila | lifeless: when tests errors out, the tracebacks is output directly *and* when selftest finish | 14:58 |
| vila | I know it's a bug, but I like it :) | 14:59 |
| lifeless | thats normal | 15:00 |
| abentley | jam: I have tried to use py_memory_dump, but the files it creates are truncated at 128MiB | 15:00 |
| lifeless | vila: its done by the ExtendedTestResult | 15:03 |
| lifeless | I'm off to sleep | 15:13 |
| lifeless | vila: jam has plain tweaked :) - but I'll leave it in your capable hands | 15:14 |
| jam | abentley: I've got 200+ MB ones here. | 15:46 |
| abentley | jam: What python are you using? | 15:47 |
| jam | 2.5 | 15:47 |
| abentley | I'm using 2.6, though I'd be surprised if that was the difference. | 15:47 |
| jam | mwhudson was using it with 64-bit python 2.4 and it worked for ~140MB ones, IIRC | 15:47 |
| jam | abentley: I'm just using fprintf() I don't see why that would be truncating anything | 15:47 |
| abentley | jam: Hey, all I know is that it's truncated. | 15:47 |
| jam | abentley: what platform? | 15:48 |
| abentley | I'm doing "bzr selftest", then using ^\ to get a pdb, and then calling dump_gc_objects | 15:49 |
| abentley | jam: Jaunty | 15:49 |
| jam | abentley: can you try adding a file.flush() in memory_dump/scanner.py ? | 15:49 |
| abentley | jam: sure. | 15:50 |
| abentley | jam: I tried twice. Both were truncated; one at 120 MiB and one at 123 MiB. | 15:54 |
| jam | abentley: you aren't running out of disk space, or something weird like that (sorry for the delay, I was on the phone with Vincent) | 16:22 |
| abentley | jam: 92 G left | 16:23 |
| jam | abentley: is the program crashing, or returning just fine, and the file is just clearly truncated? | 16:24 |
| jam | (I certainly don't do anything like truncate.... so something strange is happening) | 16:24 |
| abentley | bzr.dev selftest is not crashing. | 16:24 |
| abentley | The function is returning None. | 16:24 |
| abentley | jam: Have you tried it from pdb like me? | 16:25 |
| jam | abentley: I generally was using it via ^|, which drops you into pdb, yes | 16:26 |
| jam | I wasn't doing it for selftest, more for 'bzr branch' | 16:26 |
| jam | i'll try something again | 16:26 |
| abentley | jam: I tried it with bzr branch, and that also truncated it. | 16:30 |
| jam | abentley: does "python setup.py build_ext -i && python run_tests.py" work for you? | 16:33 |
| jam | I just found it starting to fail on a different platform, which is a bit strange, but I'll try to sort it out | 16:33 |
| abentley | jam: no: http://pastebin.ubuntu.com/147034/ | 16:35 |
| jam | hmm... seems to be a negative integer problem here | 16:35 |
| jam | abentley: you are running that in the 'runsnakerun' branch, not the memory_dump branch | 16:35 |
| abentley | jam: No, I'm just running it in the wrong branch. | 16:35 |
| jam | (I *do* have a negative integer problem here, which I'm going to fix just now) | 16:36 |
| jam | not that it would have anything to do with what you were seeing | 16:36 |
| abentley | jam: still borked: http://pastebin.ubuntu.com/147035/ | 16:36 |
| jam | abentley: yeah, it seems that under Linux you get more malloc() in the upper memory segment | 16:37 |
| jam | (>2GB) | 16:37 |
| jam | so I just need to handle the high bit being set | 16:37 |
| jam | abentley: I just pushed revno 59, can you see if that gets the tests to pass for you? | 16:39 |
| jam | (just an 'unsigned long' versus 'long' fix) | 16:39 |
| jam | I just dumped 262MB... | 16:44 |
| jam | maybe a 2.6 issue? | 16:44 |
| jam | though I guess now loading that dump is giving me "long int too large to convert to int", but I'll sort that out, too :) | 16:46 |
| abentley | jam: I get two errors about expected sizes now. | 16:46 |
| jam | abentley: can you paste that? | 16:46 |
| jam | It is possible that objects changed size in 2.6 from 2.5 | 16:46 |
| abentley | http://pastebin.ubuntu.com/147043/ | 16:46 |
| jam | yeah, it looks like type objects have a different size... | 16:47 |
| jam | so not something that means the code isn't working | 16:47 |
| abentley | jam: The new version still truncates, though. | 16:51 |
| abentley | jam: The ones I've done with branch were both truncated at 28016640 bytes. | 16:52 |
| abentley | kfogel: I've updated http://bazaar-vcs.org/NestedTreesDesign with comparisons to other systems. Would value your input, especially wrt SVN. | 16:54 |
| SKArfaceGC | are there any tools for bzr that can handle granting/revoking commit privs to a central repo? (similar to shiela in CVS) | 16:54 |
| SKArfaceGC | I did some looking and didn't see anything. | 16:55 |
| === sabdfl1 is now known as sabdfl | ||
| kfogel | abentley: will look over today (it's on my calendar, actually) thx | 17:48 |
| abentley | kfogel: great | 17:50 |
| abentley | Git submodule docs: "If you want to make a change within a submodule and you have a detached head..." | 17:51 |
| kfogel | abentley: well, does that describe our users? :-) | 17:53 |
| * SamB_irssi wonders why "Bazaar Bisect Plugin does not use Launchpad as its bug tracker." | 21:22 | |
| eka | hi all | 21:26 |
| eka | shouldnt bzr diff /myoriginalbranch/ do a diff between current and that original one? | 21:27 |
| eka | instead I use bzr diff --old /myoriginalbranch/ to see the differences | 21:28 |
| LarstiQ | it used to be that way, I believe it changed to --old because bzr diff /myorginalbranch/some/file is ambigious | 21:34 |
| * SamB_irssi leaves a question at https://answers.launchpad.net/bzr-bisect/+question/66893 | 21:38 | |
| eka | LarstiQ: But what I ment is to compare both branches, and not a file. I thought that bzr diff /otherbranch/ was intuitive :P | 21:45 |
| LarstiQ | eka: hey, I'm in the same camp :) | 21:46 |
| eka | LarstiQ: oks... still I'm new to bzr so I thought that there was something wrong | 21:47 |
| eka | s/ment/meant | 21:48 |
| SKArfaceGC | are there any tools to handle granting/revoking commit permissions per branch? I know it can be done at the OS level, but automating user group changes seems less than ideal | 21:48 |
| LarstiQ | eka: it is a concious decision to do it this way. The exact reasoning would take some digging up. | 21:48 |
| eka | could be a bug? | 21:48 |
| eka | ah ok | 21:49 |
| eka | thx | 21:49 |
| SKArfaceGC | <- still very new with bzr. | 21:50 |
| SKArfaceGC | :) | 21:50 |
| nir | How can I merge various small projects branches into single branch without loosing the history of each branch? | 22:13 |
| mwhudson | nir: the merge-into plugin, perhaps? | 22:13 |
| nir | perhaps :-) | 22:15 |
| lifeless | vila: pin | 22:21 |
| lifeless | g | 22:21 |
| === _thumper_ is now known as thumper | ||
| plastik9 | Hi. What's the best way to manage a web site with bzr (locally, the server is located on the same machine)? | 22:34 |
| lifeless | plastik9: probably just use bzr-upload to upload to the directory of the website, because bzr-upload doesn't include the bzr history and metadata that you may not want people downloading by mistake | 22:34 |
| plastik9 | lifeless: does that work the same way as a lightweight checkout? | 22:35 |
| lifeless | not really | 22:37 |
| lifeless | you would have a separate branch or checkout that you edit in, then when you want to deploy a new version just do 'bzr upload' | 22:38 |
| plastik9 | ok, cool. thank you. | 22:39 |
| plastik9 | i noticed there is a section of the wiki devoted to these sorts of questions (http://bazaar-vcs.org/Scenarios), but I was disappointed to see that it hasn't been completed yet | 22:40 |
| lifeless | that often happens with wikis :) | 22:40 |
| nir | I tried to use merge-into plugin - but it does not keep the history of the merged-in branch. Is it possible to to do this? | 22:45 |
| nir | e.g. project-a + project +b -> project-c with all history of a and b. | 22:45 |
| lifeless | nir: it should; why do you say it doesn't ? | 22:46 |
| nir | I don't see any log except the merge in | 22:46 |
| lifeless | what bzr version are you using? | 22:46 |
| nir | 1.10 | 22:47 |
| bob2 | was the log format change a speed thing? | 22:47 |
| lifeless | you *should* be seeing all the commits of the branch you merged in, nested in the commit that you made after the merge in | 22:47 |
| lifeless | nir: are you seeing any nested commits at all? If you're not try 'log --log' | 22:48 |
| lifeless | erm | 22:48 |
| lifeless | log --long | 22:48 |
| lifeless | jam: ping; I do have merge-into correct don't I? ^ | 22:48 |
| jml | lifeless: thanks for pushing done() out there. | 22:48 |
| lifeless | jml: needed doing; I'm thinking of actually doing it as startTestRun and endTestRun | 22:49 |
| nir | I don't see any nesting in this case | 22:49 |
| lifeless | jml: and saying 'whoever creates the result is responsible for calling both these methods' | 22:49 |
| lifeless | because otherwise its asymmetrical | 22:50 |
| jml | lifeless: in some cultures, asymmetry is the cornerstone of beauty | 22:50 |
| lifeless | jml: This is true; I will leave the asymettrising of python code beauty appraisal to other hands than mine | 22:51 |
| jml | :) | 22:51 |
| lifeless | in fact, a german research group has disproved the 'beauty is symmetrical' theory | 22:52 |
| lifeless | http://www.uni-regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/Psy_II/beautycheck/english/symmetrie/symmetrie.htm | 22:53 |
| lifeless | summary 'the same face made more symmetrical is perceived as more beautiful, but only by a small amount' | 22:53 |
| nir | More info: I do see all the history when I merge in another branch. | 22:54 |
| lifeless | nir: I'm not sure whats going on. I suggest filing a bug or askig on the list if jam: doesn't reply here soon | 23:02 |
| lifeless | nir: you have committed the merge-into right? | 23:02 |
| nir | I did this: | 23:03 |
| nir | mkdir test; cd test; bzr merge-into /path-to-branch; bzr commit; bzr log | 23:03 |
| nir | The first merged-in branch comes without history. The second with history. | 23:04 |
| nir | Third also ok | 23:04 |
| nir | Anyway the merge is not what I expected - I want the same history in the new branch. For example, If I have branch a with 10 revisions, and branch b with 20 revisions, I want the merged branch to have 30 revisions. | 23:06 |
| nir | With merge-into, I have only 2 revisions. | 23:07 |
| lifeless | Is there something special or different about your first merged-in branch? | 23:08 |
| nir | Each branch may be created on different platform with different bzr version | 23:09 |
| nir | bzr log --short show that I have revisions -101 to 3 | 23:12 |
| lifeless | wow, thats odd :) | 23:12 |
| nir | revisions -101 to 0 are seems like the revisions of the first branch | 23:13 |
| lifeless | could you file a bug please | 23:13 |
| nir | ok | 23:13 |
| jam | lifeless: are you guys now off of daylight savings time? | 23:13 |
| lifeless | jam: yes, its 0808 | 23:13 |
| lifeless | jam: this probably interferes with your evenings | 23:14 |
| poolie | hello jam, lifeless | 23:14 |
| lifeless | hi poolie | 23:14 |
| jam | lifeless: yeah. We're probably going to have to work something else out for standup calls. | 23:19 |
| jam | hey poolie | 23:20 |
| poolie | jam, because this is the time when lena's coming home etc? | 23:20 |
| jam | poolie: yeah, stopping my work day at 6pm+ doesn't work very well. | 23:20 |
| jam | I might be able to do a split shift, where I come back around 8-9 | 23:20 |
| jam | but then that is in the middle of your day | 23:20 |
| jam | I could probably do 1 standup per-week, or something like that | 23:21 |
| jam | but every day is a bit much | 23:21 |
| lifeless | jam: does my reply about uses_deltas make sense? | 23:25 |
| nir | lifeless: see #358059 | 23:27 |
| lifeless | bug 358059 | 23:27 |
| ubottu | Launchpad bug 358059 in bzr-merge-into "merge-into merge a branch using negative revnos" [Undecided,New] https://launchpad.net/bugs/358059 | 23:27 |
| nir | nice bot | 23:28 |
| jelmer | lifeless: moin | 23:29 |
| lifeless | moin moin | 23:29 |
| jam | lifeless: anyway, I think I understand your point, and responded. I'm off for now, but I'll try to be back around later, as we haven't really chatted in a while. | 23:34 |
| jam | poolie: ^^ as well | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!