BasicOSXhmm, test suite core dumping00:34
BasicOSXtrying pristine pbuilder to make sure my environment isn't the problem00:34
thumperhi guys00:39
thumperif I have a branch that is stacked on another00:39
thumperhow can I confirm (in a unit test) that the branch that is stacked doesn't have all the revisions?00:39
thumpera simple count of revisions in the branch's repository would suffice for the test case I guess00:40
thumperlifeless: ta00:42
lifelessset and difference kgo00:42
lifelessspiv: ping00:42
spivlifeless: pong00:44
lifelessso jam and vila seem to not be fixed by the bug fix00:45
lifelesssee last night around 1100:45
abentleythumper: yes.00:49
* spiv tries to reproduce00:53
spivlifeless: 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
lifelessspiv: then I blame 'they didn't use the new branch'01:07
spivlifeless: that's my guess.01:07
spivIt'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
lifelessvila: ping01:12
lifelessjam: ping01:12
skip_mhello - is this the place for bzr help?01:30
lifelessits a place ;)01:30
skip_manyone will do - thanks ;-)01:30
skip_mI'm a *complete* bzr naif.  Here's my problem. (Sorry if my terminology is wrong.)01:34
skip_mI branched mailman 2.1 awhile ago and made changes to one file, .../cron/gate_news.01:34
skip_mI then pushed that to launchpad.  Now I want to make a mailman 2.2 branch and01:34
skip_mtransfer all my changes to that branch.  How do I do that?  I have my mailman 2.101:34
skip_mbranch and a pristine mailman 2.2 branch.  My first change was at rev 1135.  My01:34
skip_mlast was at rev 1139.  Do I just get a diff and apply it with patch or is there a more01:34
skip_mbzr-ish way to do that?01:35
lifelesscd mailman2.2; bzr merge $path_to_mailman2.101:35
james_wyou could first try "bzr merge <your 2.1 branch with changes>"01:35
james_wdepending on how mailman 2.1 and 2.2 are maintained this may do more than you want01:35
james_wif it's small things such as the version number you can revert them and commit01:36
skip_mYeah, I just want *my* changes to the 2.1 branch01:36
james_wif it's huge then you want to cherry-pick01:36
lifelessskip_m: start by trying the simplest thing01:36
lifelessskip_m: if that grabs too much, use merge -r branch:lp:mailman/2.1.. $your-mailman2.1-branch01:37
skip_mThe 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_mliefless: I don't understand the merge -r branch... thing.01:38
lifelessskip_m: it would figure out the 1134..1139 for you01: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_mAnd 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_mok  - skip holds his breath and gingerly types 'bzr merge -r 1134..1139 ../mailman2.1' RET01:41
lifelesshave you tried just 'bzr merge ../mailman2.1' ?01:43
skip_mnot 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_mlifeless: no, i'll try that next.01:43
lifelessskip_m: huh, no need to rm -rf01:43
lifelesswhat did bzr revert do?01:43
skip_mit was ugly:01:44
skip_m% bzr revert01:44
skip_m-   cron/01:44
skip_m-D  cron/gate_news.OTHER01:44
skip_m-D  cron/spambayes.ini01:44
skip_mConflict: can't delete cron because it is not empty.  Not deleting.01:44
skip_mAnd I wound up with a mailman2.2 which had a 2.2 directory and an empty cron directory.01:44
skip_mIt's all gone now.01:44
skip_m(should I be using pastebin or something for these little snippets?)01:45
lifelessskip_m: no, its fine01:45
lifelessanyhow, if you ever feel the need to rm -rf, just ask; you shouldn't ever get that wedged with bzr01:45
lifelessso, try 'bzr merge ../mailman2.1'01:45
skip_mlifeless: 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
lifelessits the simplest, and often the right command to use01:46
Ursinhahey beuno :)01:46
Ursinhado you know if there's an equivalent in bzr to rebase in git?01:47
lifelessso 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 directory01:47
lifelessUrsinha: 'rebase'01:47
Ursinhasimple as that :)01:47
Peng_It's a plugin, though, bzr-rebase.01:47
Ursinhaoh, now I understand why I couldn't find it right away01:48
Ursinhathanks Peng01:48
UrsinhaPeng_, even01:48
Ursinhaand lifeless01:48
lifelessskip_m: so, bzr doesn't delete cron and lets you decide how to handle the situation01:48
lifelessskip_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_mok - 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
lifelessspiv: it does, but revert can conflict itself01:52
skip_m% bzr merge ../mailman2.101:52
skip_m+N  cron/spambayes.ini01:52
skip_m M  cron/gate_news01:52
skip_mText conflict in cron/gate_news01:52
skip_m1 conflicts encountered.01:52
skip_mI'm sure I can fix the gate_news conflict with no problem.01:52
skip_mThanks 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
spivlifeless: any case that "bzr merge SOMETHING; bzr revert" doesn't Just Work smells odd to me.01:53
lifelessspiv: I agree; skip_m hadn't done that though :)01:54
lifelessthe .orig file causing the conflict was the output of patch01:54
lifelessigc: could I bother you to get usertest to tell us if trunk has regressed in performance at all01:55
lifelessigc: what with the big merges yesterday01:55
igclifeless: sure. I'm working on exactly that (great mind think alike)02:11
igclifeless, spiv: some pain though ...02:11
igcbzr.dev 4266 can't branch Bob's 1.14rc branch :-(02:11
igcthe AbsentContentFactor get_bytes_as bug02:12
spivigc: grab it via http rather than bzr+ssh02:12
spivas a workaround02:12
igcspiv: cool. I was about to try that02:13
igcspiv: just a reminder about how bad that bug is (not that you needed reminding)02:13
igcso spiv: how do I find http address for an lp branch? It's no longer in the UI?02:24
igcjml: ^02:24
spivigc: lp:~aa/bb/cc -> http://bazaar.launchpad.net/~aa/bb/cc02:24
thumperigc, 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
thumperlifeless: you around?02:59
thumperlifeless: I have a stacking question02:59
=== timchen1` is now known as nasloc__
lifelessthumper: ask the question :)03:07
thumperlifeless: skype would be easier I believe03:08
lifelessspiv: I reckon land that fix03:08
lifelessthumper: ok03:08
spivlifeless: hmm, yeah03:15
davidstraussAny major bzr folks in the Bay Area?03:18
lifelessdavidstrauss: thats SF right?03:31
davidstrausslifeless: yes03:31
davidstrausslifeless: I'm in SF for the week for Drupal.org sprinting, and I'm always looking to see friendly free software faces :-)03:31
lifelessdavidstrauss: uhm, dunno :). robey pointer is there I think, but he's paramiko/loggerhead and other things, not so much a regular bzr person03:32
davidstrausslifeless: I met with Aaron when I was in Toronto03:32
lifelessdavidstrauss: I'd drop a mail to the list TBH03:32
lifelessor twitter or whatever03:32
davidstrausslifeless: TBH?03:32
davidstrausslifeless: I'll tweet it03:32
lifelessto be honest03:32
davidstrausslifeless: thans03:32
davidstrausslifeless: thanks03:32
rockstarigc, ping03:49
igchi rockstatr03:53
igcthumper: sure, planning to review it RSN03:53
* spiv -> lunch03:54
igcthumper: just running some performance tests first so we know when 1.14 is better than 1.13 and --development is better than --1.903:54
Peng_jelmer: Yay, you upgraded bzr-svn to btrees. :)03:55
thumperigc: great03:59
* igc lunch - bbiab04:00
rockstarigc, hi, for some reason, your response didn't turn my tab blue.04:04
davidstraussIf 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
davidstraussAnd, if so, how would I perform such a merge?04:05
rockstarigc, I'm integrating your revnocache into loggerhead.04:07
rockstarigc, and I'm can't think of a single use case for RevnoCache.04:07
rockstarigc, but I can see a use case of the opposite graph: {revid: revno}04:11
rockstarEr, I mean {revno: revid}04:16
rockstarigc, 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
igcrockstar: so the secret to integrating revnocache is this: make sure loggerhead is getting the graph by using Branch.iter_merge_sorted_revisions()04:38
igcrockstar: there is no step 2 :-)04:38
igcrockstar: revnocache is about to be superceded by bzr-historycache btw04:39
rockstarigc, :(04:39
igcbzr-historycache will do the same thing but more04:39
davidstraussIs --reference being dropped as an option to "join"?04:40
thumperdavidstrauss: the nested tree stuff is actively being changed right now04:40
rockstarigc, so my RevGraphCache gets created with Branch.iter_merge_sorted_revisions()04:40
thumperdavidstrauss: abentley is the man to ask04:41
igcrockstar: 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 not04:41
davidstraussthumper: Currently, if I join a branch, I lose "common history" with the branch I joined from04:41
igcrockstar: yes04:41
davidstraussthumper: I'll ask abentley04:41
igcand the next call to it (or the next call to a dotted revno lookup) uses that cache04:41
rockstarigc, 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
igcrockstar: you want graph caching, I think it's called "revgraph" or something like that in revnocache04:42
rockstarigc, yea, RevGraphCache.04:43
igcignore the others04:43
rockstarigc, yea.04:43
igcrockstar: I'm about a week away from releasing historycache04:44
rockstarigc, 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
igcI 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
igcrockstar: I'll look, but something like tuple(revnostr.split('.')) ought to go close04:46
rockstarigc, yeah, that's similar to what I was thinking.04:46
igcrockstar: so it turns out to be slightly more complex ...04:49
igcgrab parse_revno from revnocache/revnocache.py04:49
thumperif I have an open branch, how do I get the transport for that branch?04:49
igcit would be nice to have that in the core I guess, so put up a patch if you get a moment04:50
igcrockstar: ^04:50
igcrockstar: any other questions for now? I'm about to head into the other room where my desktop is for a while04:51
pooliehello igc04:51
igchi poolie - welcome back!04:51
igcpoolie: hope you had a great break04:52
rockstarigc, I don't believe so.  I'm already pretty far along.04:52
poolieit was great, thanks04:52
igcrockstar: if you do, just put a message into IRC or email and I'll check back later04:52
rockstarigc, thanks for the help.04:53
=== release is now known as samurai
sohailhow can I update my working tree to a specific revision?05:27
BasicOSXI'm not finding the "Register a release" under the 1.14 series, perms problem? vila ? poolie ?05:31
pooliehi BasicOSX05:31
BasicOSXhi, attempting to register 1.14rc1 and upload the .zip and tar.gz, but do not see the "Register a release" for 1.14 series05:32
pooliesohail: 'bzr pull -r 123 .'05:32
poolieBasicOSX: hm me either05:32
BasicOSXdon't see it for 1.13 either :-(05:33
poolieBasicOSX: i think this changed in the last release of lp05:33
BasicOSXhmm, once I figure it out, I'll need to update the releasing documentation05:33
BasicOSXI see your Code for this series now05:34
poolieBasicOSX: maybe you need to add a milestone?05:34
pooliethere was some work on fusing releases and milestones05:35
BasicOSXThere is a 1.14rc1 milestone there already, let me look at it05:35
lifelessBasicOSX: you could ask in #launchpad05:38
lifelesssome devs idle there ;)05:38
skip_mI get this message from bzr status: 'Text conflict in cron/gate_news'05:39
skip_mI took care of the conflicts in the source and deleted the cron/gate_news.<STUFF> files. Still the05:39
skip_mconflict message is there. How do I get rid of it?05:39
SKArfaceGClong 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
lifelessSKArfaceGC: 'bzr resolve'05:40
lifelessskip_m: ^05:40
lifelessSKArfaceGC: sure it is05:40
lifelessbut not from me right, now05:40
* lifeless heads to the shops ;)05:40
SKArfaceGCDon't have any at the moment.  just lurking05:40
skip_mlifeless: thanks05:40
skip_mIn my mailman2.1 repo I have this push branch:05:42
skip_mCan I just push to it from my mailman2.2 branch without creating problems?05:42
AfCSKArfaceGC: 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 esoteric05:42
SKArfaceGCI write large security software for a living.  I can deal with esoteric.  :)05:45
sohailpoolie, thank you!05:46
skip_mI used bzr push --overwrite ... which seemed to work.  If that was a bad thing, speak now or forever hold your peace. :-)05:46
spivskip_m: push --overwrite will overwrite the history in that branch to be the same as the branch you are pushing from05:59
spivskip_m: so if that's what you wanted to happen, then that's fine :)05:59
skip_mspiv: 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 about06:00
skip_mmm 2.1.06:00
spivlifeless: btw, my fix branch failed because it adds one more get_parent_map call the stacked push acceptance test.06:00
spivskip_m: sounds good then.06:00
spivskip_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
SKArfaceGChrm. . . are there any karma granting/branch locking hooks available?  Something like sheila for CVS06:03
skip_mspiv: 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
lifelessspiv: as it stands it has to06:07
lifelessspiv: so +1 to increasing the ratchet06: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/
spivlifeless: that's my feeling too.  Glad you agree :)06:08
Peng_BasicOSX: Congrats on the release (candidate). :)06:11
BasicOSXlong road traveled on this one.. thank you though06: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
BasicOSXThat's the 2nd time I've heard that. Seems to be only to mailing lists.06:15
Peng_Oh, nice.06:15
BasicOSXFirst time was a user on Win32, so I, well, kinda ignored them06:16
BasicOSXtbird doesn't have the best pgp hooks06:16
BasicOSX(not that mail.app is any better)06:16
* Peng_ is using Thunderbird + Enigmail06:17
BasicOSXOn windows? :-)06:17
Peng_No, an out-of-date Ubuntu box. :D06:17
BasicOSXsheesh bug reports coming in on 1.14rc1 already06: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
spivlifeless: btw, I'm using ec2test.06:29
BasicOSXPQM playing 1.14rc1 back into bzr.dev, afk for dinner06:43
lifelessspiv: liking it ?06:45
spivlifeless: it's neat, but it'll be much more likeable with the rough edges smoothed off :)06:53
lifelessspiv: thats true06:53
lifelessspiv: feel free to shave :)06:56
igclifeless: any thoughts on bug 357478?06:57
ubottuLaunchpad bug 357478 in bzr "development6-rr vs gc-chk255-big regressions" [Undecided,New] https://launchpad.net/bugs/35747806:58
lifelessigc: none beyond my reply06:58
igcoh, I didn't see that - I'll look06:58
vilahi all06:58
lifelesshmm, I may not have disabled tree references enough06:59
igchi vila07:06
lifelessspiv: +1 on any changes to ec2.test07:14
lifelessspiv: possibly we should ask the source, or more-local of the repositories for the parents.07:17
lifelessspiv: or something07:17
spivlifeless: 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
spivIt's a desire that comes up occasionally.07:18
sabdflhello all, congrats on landing brisbane-core in trunk08:18
sabdfltwo observations08:18
sabdflcommit after status seems really quick (delta over status is low)08:19
lifelessthat was one of the key things we were removing overhead on08:19
lifelessand thanks08:19
sabdflexplicit commit (commit file file file) seems slower than normal commit, which i don't understand since it doesn't have to check as much dirstate08:19
sabdfland commit after add seem much slower than it used to be08:19
lifelessexplicit 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 commit08:20
lifelessthis is one of the things we'll polish while its a beta format08:21
lifelessso you're seeing the older commit codepath when you do commit [paths..]08:21
lifelessdoing commit -x path  will trigger that too, as iter_changes hasn't been taught to do excludes08:21
lifelesscommit after add: is it slower for both the initial commit, and later commits after adds, or just the initial one?08:23
lifelessthe 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
lifelessso another item of polish is to work on making that initial tree operation faster08:25
lifelessThe 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
lifelessBasicOSX: please do update NEWS in bzr.dev :) its in the process I thought..08:46
BasicOSXI merged bzr.dev into my local branch, fixed up the conflicts, PQM'd it back, got a success08:47
BasicOSXmerge lp:~tanner/bzr/1.14rc1 http://bazaar-vcs.org/bzr/bzr.dev08:48
BasicOSXCommand was successful.08:48
vilalifeless: ec2 fix BB:approved, lowering (but not zeroing !) ec2 setup priority :)08:48
BasicOSXI did merge my lp branch "merged" so it doesn't show08:48
BasicOSXand a fresh branch of bzr.dev show my merge08:48
lifelessI've just not pulled in the last 40 minutes :P08:49
BasicOSXhmm, patch succeeded at 1:22am CDT08:50
lifelessfsvo 4008:50
vilaBasicOSX: bzr version now shows 1.14rc1 in bzr.dev !08:51
* BasicOSX hides08:51
BasicOSXI'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
lifelessBasicOSX: when you merge back you need to preserve bzr.devs concept of being bzr.dev08:52
lifelessso its merge, tweak NEWS bzr bzrlib/__init__.py08:53
BasicOSXyes, my mistake08:53
vilaBasicOSX: visual inspection bzr diff -c 4267 doesn't reveal anything else, you're doing good !08:53
vilaBasicOSX: 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 it08:55
BasicOSXsadly, my free time is 11pm-3am, so the documentation is my double check when I'm sleepy08:57
lifelesswell, the docs used to say to do this08:57
lifelessbut perhaps lost at some point08:57
BasicOSXIf 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
BasicOSXI read that as advance it from 1.13final to 1.14rc108:58
lifelessthat line lies08:58
lifelessis overly brief08:58
BasicOSXI got notes now, need to make sure it's 'dev'08:58
lifelessso advance means 'change 1.14dev to 1.15dev'08:59
BasicOSXok, just need branch, it's 1,14,0,'dev',0,09:00
lifelesslater all09:00
BasicOSXdo I need to update bzr's _script_version too ?09:01
vilaBasicOSX: yes, it's even surprising it isn't mentioning dev...09:06
* BasicOSX winks09:15
BasicOSXlifeless:  beat me to pqm09:15
BasicOSX  lp:~tanner/bzr/bzr.dev has my fix in it, if someone wants to verify09:16
BasicOSXv$ ./bzr --version09:16
BasicOSXBazaar (bzr) 1.15dev09:16
BasicOSX3:17am, sleep, email me if I need to work on other stuff I messed up :-)09:17
vilaBasicOSX: good night !09:18
* igc dinner09:47
johnfspiv:  you about?09:50
pooliehello johnf10:11
johnfpoolie: howdy10:12
Mezusing 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
BluehornMez: PQM is here: https://launchpad.net/pqm11:13
Bluehorn*: Is there a way to aggregate multiple changes into a single revision in bzr?11:14
BluehornBackground: I was messing around with bzr-gtk (not having used pygtk for a while) and would like to post the patch.11:14
BluehornBut 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
lifelessMez: sure use a pre_branch_tip_change_hook11:16
lifelessMez: (see bzr help hooks)11:16
lifelessMez: pqm is not easy ;P11:17
Bluehornlifeless: but it looks like an interesting concept ;-)11:17
lifelessBluehorn: it is, and it works well, its just not easy ;)11:17
Mezlifeless: only through p1m?11:48
Mezlifeless: never mind, was reading something els.e11:48
MezI'm actually looking for a post-hook, but something easy11:48
lifelessmail the list, its late for me, I'll whip one up for you tomorrow11:49
Mezthanks lifeless11:49
ormandjHi, 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 chang12:41
ormandjthe documentation didn't make this clear what I should expect12:41
lifelessormandj: you haven't committed your changes12:55
lifelessormandj: you need to commit after you make a change to a branch12:55
ormandjlifeless: the documentation example didn't show the commits that's why i was confused about this12:55
ormandjit shows running the merge *before* committing12:55
ormandjie: merge from the trunk to my new branch, then commit the merged changes along with my updates12:56
ormandj(i'm doing the distributed style setup described)12:57
lifelesswell, 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
xnevermoreHey. 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
lifelessit would look like a main branch, a development branch, and your public_html folder a third branch :)13:51
lifelessor you could use bzr-upload for deployment13:51
xnevermoreso the main folder used to serve web pages to apache would be a bzr branch itself? or a mirror? or something else?13:52
lifelessmost people seem to use bzr-upload for that folder13:53
lifelessits a plugin13:53
LarstiQthat is what I would advise13:53
xnevermorei'll check that out13:54
xnevermorethank you13:54
lifelessvila: I've just sent a new [MERGE] request14:37
lifelessvila: which has the other stuff I was muttering about14:37
vilalifeless: ok, will have a look (by the way, the tests *were* passing here ;-)14:40
lifelessvila: not with my print intend change14:41
lifelessvila: your write() call wasn't indented14:41
vilalifeless: indeed, because I just copy/paste from my branch :)14:41
lifelesssee ;)14:41
vilalifeless: doesn't really matter, it's just that we talked about it but it was never merged14:42
lifelessI think you'll like it14:42
lifelessvila: if you wanted to review it now, I could land it immediately ;)14:46
vilalifeless: I am14:46
lifelessthank :)14:47
vilaBB: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
vilaor did I miss the tests ?14:50
lifelessI moved code14:50
lifelessnothing 'new' really :) so existing tests should suffice14:51
lifelessif nothing was testing the output, then I haven't reduced the coverage; if it was tested, then I preserved the behaviour14:51
vilanothing 'new' but startTests() and done() just want to be extended/overriden :0)14:51
lifelesswhat sort of tests would you like to see?14:52
vilasimplest ones: they are called once14:52
vilaseeing the modification of InstrumentedTestResult made me think they should be trivial to add14:53
jammorning lifeless, shouldn't you be sleeping by now :)14:53
lifelessjam: yes14:54
lifelessvila: cut you a deal :) add some tests, land it ? :)14:54
lifelesscool - thanks14:54
vilaMore often than not I feel I want to do that for many reviews...14:54
lifelesswith this, the output from selftest --parallel=forked looks like normal14:55
vilaerr, I hope you haven't addressed the tracebacks *during* execution :-)14:57
lifelessoh, you'll want https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/534614:57
lifelessfor obvious reasons14:57
lifelesswhat tracebacks?14:57
vilalifeless: when tests errors out, the tracebacks is output directly *and* when selftest finish14:58
vilaI know it's a bug, but I like it :)14:59
lifelessthats normal15:00
abentleyjam: I have tried to use py_memory_dump, but the files it creates are truncated at 128MiB15:00
lifelessvila: its done by the ExtendedTestResult15:03
lifelessI'm off to sleep15:13
lifelessvila: jam has plain tweaked :) - but I'll leave it in your capable hands15:14
jamabentley: I've got 200+ MB ones here.15:46
abentleyjam: What python are you using?15:47
abentleyI'm using 2.6, though I'd be surprised if that was the difference.15:47
jammwhudson was using it with 64-bit python 2.4 and it worked for ~140MB ones, IIRC15:47
jamabentley: I'm just using fprintf() I don't see why that would be truncating anything15:47
abentleyjam: Hey, all I know is that it's truncated.15:47
jamabentley: what platform?15:48
abentleyI'm doing "bzr selftest", then using ^\ to get a pdb, and then calling dump_gc_objects15:49
abentleyjam: Jaunty15:49
jamabentley: can you try adding a file.flush() in memory_dump/scanner.py ?15:49
abentleyjam: sure.15:50
abentleyjam: I tried twice.  Both were truncated; one at 120 MiB and one at 123 MiB.15:54
jamabentley: 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
abentleyjam: 92 G left16:23
jamabentley: 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
abentleybzr.dev selftest is not crashing.16:24
abentleyThe function is returning None.16:24
abentleyjam: Have you tried it from pdb like me?16:25
jamabentley: I generally was using it via ^|, which drops you into pdb, yes16:26
jamI wasn't doing it for selftest, more for 'bzr branch'16:26
jami'll try something again16:26
abentleyjam: I tried it with bzr branch, and that also truncated it.16:30
jamabentley: does "python setup.py build_ext -i && python run_tests.py" work for you?16:33
jamI just found it starting to fail on a different platform, which is a bit strange, but I'll try to sort it out16:33
abentleyjam: no: http://pastebin.ubuntu.com/147034/16:35
jamhmm... seems to be a negative integer problem here16:35
jamabentley: you are running that in the 'runsnakerun' branch, not the memory_dump branch16:35
abentleyjam: 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
jamnot that it would have anything to do with what you were seeing16:36
abentleyjam: still borked: http://pastebin.ubuntu.com/147035/16:36
jamabentley: yeah, it seems that under Linux you get more malloc() in the upper memory segment16:37
jamso I just need to handle the high bit being set16:37
jamabentley: 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
jamI just dumped 262MB...16:44
jammaybe a 2.6 issue?16:44
jamthough 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
abentleyjam: I get two errors about expected sizes now.16:46
jamabentley: can you paste that?16:46
jamIt is possible that objects changed size in 2.6 from 2.516:46
jamyeah, it looks like type objects have a different size...16:47
jamso not something that means the code isn't working16:47
abentleyjam: The new version still truncates, though.16:51
abentleyjam: The ones I've done with branch were both truncated at 28016640 bytes.16:52
abentleykfogel: I've updated http://bazaar-vcs.org/NestedTreesDesign with comparisons to other systems.  Would value your input, especially wrt SVN.16:54
SKArfaceGCare there any tools for bzr that can handle granting/revoking commit privs to a central repo?  (similar to shiela in CVS)16:54
SKArfaceGCI did some looking and didn't see anything.16:55
=== sabdfl1 is now known as sabdfl
kfogelabentley: will look over today (it's on my calendar, actually) thx17:48
abentleykfogel: great17:50
abentleyGit submodule docs: "If you want to make a change within a submodule and you have a detached head..."17:51
kfogelabentley: 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
ekahi all21:26
ekashouldnt bzr diff /myoriginalbranch/ do a diff between current and that original one?21:27
ekainstead I use bzr diff --old /myoriginalbranch/ to see the differences21:28
LarstiQit used to be that way, I believe it changed to --old because bzr diff /myorginalbranch/some/file is ambigious21:34
* SamB_irssi leaves a question at https://answers.launchpad.net/bzr-bisect/+question/6689321:38
ekaLarstiQ: But what I ment is to compare both branches, and not a file. I thought that bzr diff /otherbranch/ was intuitive :P21:45
LarstiQeka: hey, I'm in the same camp :)21:46
ekaLarstiQ: oks... still I'm new to bzr so I thought that there was something wrong21:47
SKArfaceGCare 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 ideal21:48
LarstiQeka: it is a concious decision to do it this way. The exact reasoning would take some digging up.21:48
ekacould be a bug?21:48
ekaah ok21:49
SKArfaceGC<- still very new with bzr.21:50
nirHow can I merge various small projects branches into single branch without loosing the history of each branch?22:13
mwhudsonnir: the merge-into plugin, perhaps?22:13
nirperhaps :-)22:15
lifelessvila: pin22:21
=== _thumper_ is now known as thumper
plastik9Hi. What's the best way to manage a web site with bzr (locally, the server is located on the same machine)?22:34
lifelessplastik9: 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 mistake22:34
plastik9lifeless: does that work the same way as a lightweight checkout?22:35
lifelessnot really22:37
lifelessyou 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
plastik9ok, cool. thank you.22:39
plastik9i 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 yet22:40
lifelessthat often happens with wikis :)22:40
nirI 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
nire.g. project-a + project +b -> project-c with all history of a and b.22:45
lifelessnir: it should; why do you say it doesn't ?22:46
nirI don't see any log except the merge in22:46
lifelesswhat bzr version are you using?22:46
bob2was the log format change a speed thing?22:47
lifelessyou *should* be seeing all the commits of the branch you merged in, nested in the commit that you made after the merge in22:47
lifelessnir: are you seeing any nested commits at all? If you're not try 'log --log'22:48
lifelesslog --long22:48
lifelessjam: ping; I do have merge-into correct don't I? ^22:48
jmllifeless: thanks for pushing done() out there.22:48
lifelessjml: needed doing; I'm thinking of actually doing it as startTestRun and endTestRun22:49
nirI don't see any nesting in this case22:49
lifelessjml: and saying 'whoever creates the result is responsible for calling both these methods'22:49
lifelessbecause otherwise its asymmetrical22:50
jmllifeless: in some cultures, asymmetry is the cornerstone of beauty22:50
lifelessjml: This is true; I will leave the asymettrising of python code beauty appraisal to other hands than mine22:51
lifelessin fact, a german research group has disproved the 'beauty is symmetrical' theory22:52
lifelesssummary 'the same face made more symmetrical is perceived as more beautiful, but only by a small amount'22:53
nirMore info: I do see all the history when I merge in another branch.22:54
lifelessnir: I'm not sure whats going on. I suggest filing a bug or askig on the list if jam: doesn't reply here soon23:02
lifelessnir: you have committed the merge-into right?23:02
nirI did this:23:03
nirmkdir test; cd test; bzr merge-into /path-to-branch; bzr commit; bzr log23:03
nirThe first merged-in branch comes without history. The second with history.23:04
nirThird also ok23:04
nirAnyway 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
nirWith merge-into, I have only 2 revisions.23:07
lifelessIs there something special or different about your first merged-in branch?23:08
nirEach branch may be created on different platform with different bzr version23:09
nirbzr log --short show that I have revisions -101 to 323:12
lifelesswow, thats odd :)23:12
nirrevisions -101 to 0 are seems like the revisions of the first branch23:13
lifelesscould you file a bug please23:13
jamlifeless: are you guys now off of daylight savings time?23:13
lifelessjam: yes, its 080823:13
lifelessjam: this probably interferes with your evenings23:14
pooliehello jam, lifeless23:14
lifelesshi poolie23:14
jamlifeless: yeah. We're probably going to have to work something else out for standup calls.23:19
jamhey poolie23:20
pooliejam, because this is the time when lena's coming home etc?23:20
jampoolie: yeah, stopping my work day at 6pm+ doesn't work very well.23:20
jamI might be able to do a split shift, where I come back around 8-923:20
jambut then that is in the middle of your day23:20
jamI could probably do 1 standup per-week, or something like that23:21
jambut every day is a bit much23:21
lifelessjam: does my reply about uses_deltas make sense?23:25
nirlifeless: see #35805923:27
lifelessbug 35805923:27
ubottuLaunchpad bug 358059 in bzr-merge-into "merge-into merge a branch using negative revnos" [Undecided,New] https://launchpad.net/bugs/35805923:27
nirnice bot23:28
jelmerlifeless: moin23:29
lifelessmoin moin23:29
jamlifeless: 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
jampoolie: ^^ as well23:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!