/srv/irclogs.ubuntu.com/2009/03/06/#bzr.txt

bob2pfanelli: might have more luck on the mailing list00:03
pfanellibob2: thx. I got this channel off of the bzr web site. I also checked for answers on LP.  Do you know how to subscribe to the mailing list? (this is probably a stupid ? :) ). Also, I was gonna' ask a question on LP. Do you think i should also do this?00:11
bob2pfanelli: https://lists.ubuntu.com/mailman/listinfo/bazaar - dunno about lp00:12
pfanellibob2:  heh, i just looked up the mailing list on the bzr site (duh - my bad, lol)  thanks!00:13
bob2pfanelli: no worries00:14
=== salgado is now known as salgado-afk
* igc offline for an hour or so while travelling00:24
spivI've just submitted 3 of Robert's approved patches to PQM, given that he's offline today.01:12
jelmeris there any chance of the 30+ patches currently in BB landing before 1.13?01:14
=== Wowbagger is now known as UdontKnow
jfroyjelmer: I just got a "Could not determine revno for ... because its ancestry shows a ghost at ..." error, thoughts?01:47
jfroywhile trying to commit to a svn branch01:47
spivjelmer: of all of them landing?  I'd estimate that at near 0.01:47
spivjelmer: there's a good chance that some of them will, though...01:48
spivPerhaps even most?01:48
phinzeis there a location alias for the "checkout of" branch?02:03
lifelessspiv: thanks02:07
tallenanyone seen any integration with Visual Studio and Bazaar?02:22
tallenI see this https://launchpad.net/bzr-visualstudio but it doesnt seen active02:24
* igc is back online02:40
igcjam, if you're still around, the groupcompress tests are failing02:48
igcI think I know the fix but I'm not sure ...02:49
igcadd "start = entry.start" around line 236 in groupcompress.py?02:49
lifelessspiv: ping02:58
pooliehi lifeless03:00
jelmerjfroy, please file a bug03:05
jfroywill do if I see it again03:05
jelmerspiv, most would be nice03:05
jfroyI wiped the cache and tried the operation again (a commit), and it worked03:06
jelmerjfroy, it's not reproducible?03:06
jfroy(well, also made a clean checkout)03:06
jfroyI haven't seen the same error again yet03:06
lifelesspoolie: hi03:06
jfroyI always try a "wipe cache, get a clean checkout" while tracking bzr-svn top of tree.03:06
jfroyIt's not unreasonable for changes to invalidate existing branches or the cache03:07
jelmerjfroy, unless there is a bug that's been fixed no changes should be invalidating existing branches/cache03:07
jelmerjfroy, was this the same branch we fixed a bug in yesterday?03:08
jfroyyes I believe so03:10
jfroyactually no03:10
jfroywell, yes and no :p03:10
jfroysame subversion branch03:10
jfroybut much older local branch (my actual daily work branch)03:11
spivlifeless: pong03:13
lifelessspiv: about to send in a tags fix03:19
spivlifeless: hooray.  ratchet improvement? :)03:19
lifelessspiv: surprisingly, not yet. 4 verbs in and still equilibrium03:19
spivlifeless: I'd love a review of my fetch with search patch (http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090306005950.GD7819%40steerpike.home.puzzling.org%3E)03:20
spivlifeless: huh, odd.  What's the current culprit?03:20
lifelessspiv: tags03:21
lifelessso get_parent_ was equilibrium03:21
lifelessten tags - first _should_merge,03:21
lifelessbut .tags needed real03:21
lifelessthen branch._transport needed real03:22
lifelesswhich is what I'm working on at the moment03:22
lifelessoh, open_branchV2 is in there too, to get the format03:22
lifelessspiv: also there is an oddity on decod of responses03:32
lifelessspiv: '' -> ()03:32
jamigc: something like that. I think I fixed it in a different branch by using 'entry.start' in place of 'start', but either should be fine03:33
lifelessspiv: or more clearly, ('',)03:33
lifelessspiv: and, ratchet -> 1103:33
hackedheadi'm about to travel, and i have a small class projec that i'm using bzr to track on my deskop, i'm the only 'developer' and it's not public anywhere. i'd like to move the working tree to my laptop while i travel... can i simply copy the directory over? or is there better way?03:38
pooliesure just03:38
poolieon your laptop,03:38
pooliebzr branch bzr+ssh://desktop/~/what/ever03:38
poolieoh, and make a repo in the right place on your laptop first03:38
igcjam: yeah, it looked like start was being set in the if branch but not the else branch03:38
hackedhead'make a repo' meaning a directory for it to live in, i assume03:39
spivlifeless: I fixed some bugs in your get_parent branch to be able to land it, btw03:40
lifelessspiv: ok, I'll pull now03:40
spivlifeless: where you were passing 'foo' rather than ('foo',) as a response03:40
igcjam: the unclear bit was knowing what start ought to be set to - and entry.start looked a likely option :-)03:40
pooliehackedhead: i mean, in your home directory, do03:41
pooliebzr init-repo myproject03:41
spivlifeless: you had some tests and code that had (x) rather than (x,), happily other tests noticed :)03:41
jamigc: yeah, inside that if, entry.start is set to start03:41
poolieor whatever name you want to use03:41
lifelessspiv: yes, I've just been cleaning that up here too03:41
pooliethis will make a directory to hold all your branches03:41
jamit is outside the if that already has it03:41
igcjam: another minor quibble, the groupcompress branch had a heap of bzr tags in it referencing missing revisions03:42
igcjam: I'm not sure if they're gone know but my concern was how they got there03:42
lifelessigc: root cause: pull not propogating tags03:42
hackedheadpoolie: okay, and when i get back i can do a merge from the desktop, using ssh again, in the other direction?03:43
poolieyes, or just push to the desktop03:43
hackedheadoh, right, okay03:43
pooliepresumably no other work will have happened there while you're away03:43
poolieso just a push will do03:43
hackedheadyes. =]03:43
pooliehth03:43
hackedheadyeah,much, ty03:43
igclifeless: I'm not sure I understand - why would a 'bzr-0.15' tag exist in the groupcompress repo at all?03:43
poolieyou're welcome03:43
lifelessigc: oh, that? blame jam :P03:44
hackedheado/03:44
igcmaybe the orginal branch shared a repo with bzr.dev or something?03:44
jamfunny, I don't remember ever trying to merge my jam-integration branch into groupcompress03:45
jamI honestly don't have any idea why the tags would have spread to GC03:45
jammaybe I did a 'bzr merge' with a bad path once?03:46
jamigc: It shares a repo, but it shouldn't have shared a branch03:46
lifelessspiv:03:52
lifeless[BzrDir.open, BzrDir.open_branchV2, BzrDir.find_repositoryV3, Branch.get_stacked_on_url, Branch.last_revision_info, BzrDir.cloning_metadir, Repository.get_parent_map, Repository.get_stream, Branch.get_parent, Branch.get_tags_bytes, Branch.get_tags_bytes]03:52
lifelessspiv: clear as day now.03:52
lifelessspiv: also note: VFS-free!03:53
lifelessspiv: I'm going to ignore the duplicate call [for now]03:53
lifelessspiv: as caching coherency requires a little care, and this is already somewhat better03:53
poolielifeless, jam, this branch was originally going to set the format to 1.9-rich-root03:55
poolieto get it over with03:55
lifelesspoolie: which branch03:55
poolieto set the default format for 1.13 to 1.903:55
pooliei'm inclined now to stick with plain 1.903:56
lifelessworks for me03:56
lifelessspiv: reviewing your patch about fetch paramaters03:57
spivlifeless: nice04:02
lifelessspiv: so, I want to combine the first three calls04:03
lifelessspiv: with a lock_read() we could optimistically ask for the next two or even three04:04
spivlifeless: a lock_read on which object?04:04
lifelessspiv: Branch04:04
spivHmm.  If we opened branches read-locked, then get_stacked_on_url and last_revision_info are obvious things to fetch.04:05
lifelessyes04:05
lifelessbut api clarity does still matter :)04:05
spivRight.04:06
lifelessBranch.open().unlock().lock_write() blows04:06
spivThere is definitely some friction with the current API here.04:06
jampoolie: I wouldn't do rr04:06
jamgiven the 5-hour conversion times04:06
lifelessI could buy into Branch.open_read_locked()04:06
spivlifeless: me too04:06
poolieme three04:07
pooliejam, ok04:07
jamwait for something like CHK, which gives a real benefit04:07
lifelessspiv: reviewed04:11
lifelessspiv: in short; some smoke tests for the new capabilities; and some naming changes04:12
lifelessspiv: also please review my tags patch :)04:12
poolielifeless/spiv: changing the default format to 1.9 bumps test_branch_from_trivial_branch_streaming_acceptance to 1804:12
lifelesspoolie: tsk!04:12
poolieputting just a number there makes it hard to see what actually was added04:12
lifelesspoolie: yes, thats true. OTOH its very easy to work with for us04:13
lifelesspoolie: when some of the ratches are still > 10004:13
poolieyes that's the tradeoff04:13
pooliei know i know04:13
lifeless:)04:13
pooliebeen there too04:13
lifelessspiv: oh bah, ignore the self.debug() call I left in04:15
spivlifeless: was already reviewing :)04:16
lifelesspoolie: it stays at 11 for me04:16
lifelessspiv: K, I'll wait for your feedback and remove the debug call at the same time04:17
lifelesspoolie: I see:04:18
lifeless[BzrDir.open, BzrDir.open_branchV2, BzrDir.find_repositoryV3, Branch.get_stacked_on_url, Branch.last_revision_info, BzrDir.cloning_metadir, Repository.get_parent_map, Repository.get_stream, Branch.get_parent, Branch.get_tags_bytes, Branch.get_tags_bytes]04:18
lifelesspoolie: however, I do see an increase in blackbox.test_branch.TestSmartServerBranching.test_branch_from_trivial_branch_to_same_server_branch_acceptance, which is from 65 to 6604:18
poolielifeless: http://pastebin.ubuntu.com/127042/04:21
spivlifeless: reviewed04:22
lifelesspoolie: yeah, most of those will be tags04:23
lifelesspoolie: print self.hpss_calls[8].stack04:23
pooliei guess it's also reading the stacking control file04:23
lifelesspoolie: will show you the cause04:23
pooliethat's nice04:25
pooliewell it's http://pastebin.ubuntu.com/127042/04:25
pooliemeh04:25
poolie    format_string = transport.get(".bzr/branch-format").read()04:25
lifelesspoolie: right, but look higher :)04:26
lifelesspoolie: _ensure_real is generally a symptom04:27
lifelessyou'll find something like merge_tags_if_needed04:27
pooliesure, of get_parent04:27
lifelessor get_parent :)04:27
lifelessget_parent as landed though04:27
pooliejust recently?04:28
lifelesstoday04:28
spivYes, a couple of hours ago.04:28
poolieso maybe that didn't reduce the rpc count, but it did eliminate vfs access here?04:28
spivRight.04:29
lifelessyes get_parent_map was no improvements in round trips, but one less cause of vfs04:29
lifelessthe next patch removes the last cause04:29
spivlifeless: s/get_parent_map/get_parent/ :)04:29
lifelessbah yes04:29
spivPerhaps it should be called get_parent_location to reduce confusion?  Not that the wire API is the same as bzrlib's API...04:30
lifelessspiv: see thursday's chat:)04:30
lifelessspiv: _run_with.. should show the transform04:30
poolie?04:30
poolieon staying on the main game?04:30
poolieat a guess04:30
lifelesspoolie: no, about verb names04:31
spivlifeless: oh, _run_with... was self-explanatory to me :)04:31
lifelessspiv: I can't tell if  I need a lambda or not04:31
lifelessspiv: for instance04:31
spivlifeless: please feel free to extend the docstring; the transform for the given example is just "return _run_with_write_locked_target(callable, *args, **kwargs)"04:32
lifeless(what if _transport is only defined in the lock_written state? for instance)04:32
spivTypically if a function takes *args/**kwargs then lambdas are unneccessary.04:32
poolieok so that one's still failing after merging bzr.dev...04:34
pooliebecause now tags() is forcing a real repository...04:35
spivpoolie: so the problem is that _ensure_real of a BzrBranch7 is one VFS call more expensive than of Branch6?04:37
lifelessspiv: your cloning_metadir looks odd04:37
lifelessspiv: sometimes you return a tuple04:37
pooliei think so04:37
lifelessspiv: sometimes you return a string, for branch_name04:37
lifelessspiv: is this deliberate?04:37
spivlifeless: do I?  Hmm.04:37
pooliethat would be consistent with it having to read its stacking url over the vfs04:37
spivlifeless: IIRC I meant to always return a tuple.04:37
spivlifeless: ugh, so I do.04:38
lifelessspiv: adjusting04:38
poolietherefore i think it's correct for that count to go up by 1 given the level of technology in this branch04:38
spivlifeless: thanks.04:38
lifelessspiv: and letting pqm handle the fallout04:38
spivpoolie: what's odd to me is that 1.6 has stacking URLs too...04:39
lifelessspiv: current default is 0.9204:39
spivOh, ok.04:39
spivIn that case, it all makes perfect sense :)04:39
lifelesspoolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1236311834.10834.1.camel%40lifeless-64%3E04:40
spivpoolie: given that lifeless is about to land get_tags_bytes, which should get rid of the VFS from that case, a temporary +1 bump sounds ok to me.04:40
lifelesspoolie: ^ is about to land04:40
lifelesspoolie: and it will conflict on that line04:40
spivpoolie: but as lifeless says maybe just merging in that branch will be easier?04:40
pooliek, i'll look at some other failures first04:42
lifelesspoolie: so the other acceptance test in test_branch.py *will* go up for 1.9 as default, with my branch04:45
lifelesspoolie: and thats fine04:45
lifeless(65->66 for me - you have +1 on that change)04:54
pooliei wish, again, we printed stack traces as soon as they occurred...05:05
seb_kuzminskyis it bad if "bzr check" says "2 inconsistent parents"?05:08
seb_kuzminskyon the repo where it says that, i can't push changes in05:08
seb_kuzminskyi made that repo with "git-fast-export | bzr fast-import", and it seems to work fine locally, but not in branches i've made off it...05:08
poolieseb_kuzminsky: it may be a bzr-fastimport bug then05:09
poolieseb_kuzminsky: ideally someone would run bzr reconcile on that repo05:09
* seb_kuzminsky reads about reconcile05:10
poolielifeless or spiv, one of you might want http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480903052104k63c85898t88ed90dcccdc7715%40mail.gmail.com%3E05:10
pooliealso  spiv is http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E now obsolete?05:10
seb_kuzminsky"Reconciliation complete."05:11
seb_kuzminskybzr check is clean now :-)05:11
seb_kuzminskybut it still doesnt work :-(05:13
spivpoolie: not obsolete, but it does need another look to figure out how it should interact with vila's http network activity05:14
seb_kuzminskyi removed ran reconcile on the "master" repo, removed the remote branch, re-branched to the remote machine, committed on the remote machine, and tried to push05:14
seb_kuzminskybzr: ERROR: Revision {set([('null:',)])} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(<bzrlib.btree_index.BTreeGraphIndex object at 0x18a5a90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x16518d0>)), <bzrlib.knit._DirectPackAccess object at 0x16033d0>)".05:14
seb_kuzminskyboth repos are 1.9-rich-root, in case that matters05:14
seb_kuzminskyboth 'check' clean05:14
spivseb_kuzminsky: which version of bzr?  I think this bug was fixed in bzr.dev about a week ago.05:15
seb_kuzminsky"1.13dev" on the remote machine05:15
seb_kuzminsky"1.12" on the master server05:15
seb_kuzminskyupgrade the server?05:15
seb_kuzminskyremote is on the bzr intrepid ppa05:16
spivseb_kuzminsky: upgrade the 1.12 to bzr.dev if you can, IIRC05:16
seb_kuzminskyserver is intrepid's 1.12-1~bazaar1~intrepid105:16
seb_kuzminskyspiv: do i need the nightly ppa?  or is beta good enough?05:20
seb_kuzminskylooks like i need beta05:20
seb_kuzminskys/beta/nightly/05:20
spivseb_kuzminsky: nightly, I think.05:20
spivseb_kuzminsky: https://launchpad.net/bugs/317654 is the bug, btw05:21
ubottuUbuntu bug 317654 in bzr "error about null revision not present pushing to server" [High,Fix committed]05:21
spivseb_kuzminsky: also, you may be able to workaround it by using sftp:// rather than bzr+ssh://05:22
seb_kuzminskyhmm05:22
seb_kuzminskyyes, sftp:// pushed successfully05:23
seb_kuzminskybut it didnt run the hooks (bzr-email, bzrbuildbot)05:23
spivYeah.05:23
seb_kuzminskythose only run with ssh, right?05:23
spivThat's right.05:23
seb_kuzminskyok05:24
* seb_kuzminsky adds bzr-nightly-ppa to sources.list.d/bzr.list05:24
lifelessspiv: I've just forwarded you a pqm failure05:25
spivlifeless: ok05:25
lifelessspiv: I'd like to ask a favour05:25
lifelessspiv: land my http://people.ubuntu.com/~robertc/baz2.0/integration branch05:26
spivlifeless: ok05:26
lifelessspiv: its likely that ^^^^[log from bzrlib.tests.branch_implementations.test_hooks.TestOpen.test_open(RemoteBranchFormat-default)] is one of several failures with hooks05:26
* spiv nods05:27
lifelessso running hooks.* RemoteBranchFormat should flush them out05:27
lifelessI *think* at a glace that the branch is being opened remotely in more cases05:28
=== jfroy_ is now known as jfroy
lifelessso trivially adjusting may be sufficient05:28
seb_kuzminskyserver is on 4083 (latest in bzr.dev), remote machine is on 405805:29
seb_kuzminskyremote still can't push, same error05:29
seb_kuzminskyupgrading remote to 4083 now05:30
spivseb_kuzminsky: remote needs to be at least 406105:30
spivseb_kuzminsky: "missed it by *that* much" ;)05:31
seb_kuzminskyheh05:31
seb_kuzminskythat's what i get for hopping off of the nightlies and down to the boring old stuff in the "release" ppa  ;-)05:31
spivseb_kuzminsky: also, the network protocol is in a fair bit of flux in bzr.dev atm.  So until 1.13rc1 is out, you may need to keep client and server on the same version of bzr.dev to avoid weird smart server failures.05:32
seb_kuzminskyok thanks for the heads up05:32
spiv(but on the plus side it ought to be noticeably faster)05:32
seb_kuzminskyooh, thanks!05:33
spivseb_kuzminsky: if you *do* get weird failures though, please let us know :)05:33
seb_kuzminskyoh you'll know05:33
seb_kuzminsky;-)05:34
spiv:)05:34
seb_kuzminskylooks like it worked05:35
spivseb_kuzminsky: great05:35
seb_kuzminskyaw yea05:35
seb_kuzminskythanks spiv!05:35
seb_kuzminskyyeah that's all working just fine :-)05:36
seb_kuzminskyyay, thanks again!05:36
seb_kuzminskyok i'll be back when it breaks next time ;-)05:36
spivseb_kuzminsky: good :)05:37
spivlifeless: the three calls are [server] open_branchV2, [client] open, [server] get_stacked_on_url05:42
lifelessspiv: right,05:42
lifelessopen_branch didn't open the branch05:42
spivRight.05:43
lifelessspiv: I need to go06:11
lifelessspiv: good luck with the branch06:11
spivlifeless: not a problem06:11
spivlifeless: happy travels06:11
poolieyes bye lifeless06:15
pooliespiv, i have a failure now in test_clone_unstackable_branch_preserves_stackable_repo_format06:25
pooliebecause RemoteBranchFormat, at least in the version of trunk that i've merged, claims not to support stacking06:26
pooliewhereas with this change it will06:26
pooliedoes this ring any bells?06:26
spivpoolie: hmm06:28
spivpoolie: that does ring some bells, in that a recent landing touched that code.06:30
pooliei think in general robert was going to make tags be handled by making teh format depend on the particular branch06:30
poolienot sure that's a great idea06:30
poolieat the moment it says it always supports tags06:30
poolieso i'm going to make it consistent with that and hope :)06:30
spivpoolie: but IIRC the change was that it was going to rely on the underlying format to decide06:30
spivRight, that's what Robert's patch for tags does.06:31
spiv(make the format of the branch handle it)06:31
spivNot sure what the overlap with tags and stacking is here though?06:31
pooliewell, they're both capabilities that are determined by the real on disk format06:37
=== mike is now known as indy34
Peng_So now that the 'authors' revision property has been added, 'author' is no longer written, right? Isn't that bad for backwards compatibility with older clients?08:01
Peng_I mean, it's not a big deal, but still.08:01
* igc dinner08:05
pooliei thought that we changed it to write out only the additonal authors?08:06
pooliebut you should raise that on the list?08:06
Peng_jelmer: You mean LP's email notifications? I don't know. I know they work for lp:~jelmer/bzr-svn/0.5-mirrored.08:13
spivpoolie: regarding the repository acquisition policies, yes, it is a bit weird.08:15
pooliespiv, i'm going to try to move it08:16
spivpoolie: lifeless lands some changes to allow Branch.clone and others to accept a repository_policy kwarg08:16
spivFor similar reasons.08:16
pooliehm i remember seeing that but i can't find the mail08:22
poolieah ok08:28
poolieso, i'd like to clean it up but it's not all that bad08:28
pooliewe always create a bzrdir there before we think about stacking08:29
Peng_poolie: You thought it was changed to what?08:29
pooliebut it doesn't really matter because there's only one relevant bzrdir format, and we can choose to make a different branch format before the branch is created08:30
pooliei'd say it's not great though08:30
Peng_Oh, it only uses 'authors' when multiple authors were passed. That's not so bad, then.08:30
pooliePeng_, i thought the issue had been taken into account08:30
Peng_Wait, never mind.08:31
Peng_poolie: ISTM commit only sets 'authors' now.08:31
Peng_beuno: Will Loggerhead try to perform syntax highlighting on gigantic files? IIRC, Mercurial limited it to smallish files.08:41
pooliespiv if you're still here08:56
poolieor anyone really08:56
pooliethese likes look backward to me08:56
poolie233                  require_stacking = True08:56
poolie234                  result._format.require_stacking()08:56
poolieuups08:56
poolie232              if not require_stacking and repository_policy._require_stacking:08:57
poolie233                  require_stacking = True08:57
poolie234                  result._format.require_stacking()08:57
poolieoh i see08:57
=== montywi|zzz is now known as montywi|talk
Peng_poolie: Mailing list message sent, fwiw.09:20
Mezhey, anyone have any idea why all of a sudden, I can do a bzr up but not a bzr st (permission denied)09:38
pooliewhat's in the traceback in ~/.bzr.log?09:38
Mezone sec09:39
Mezpoolie: nothing sinister09:42
Mezhttp://rafb.net/p/EMHVs538.html09:42
Mezand an strace sees it trying to find files, but getting ENOENTs back09:42
pooliebut it says permission denied?09:42
Mezyep09:42
pooliehow strange09:42
pooliehow about bzr -Derror st09:42
Mezrunning selftest .09:43
pooliehuh?09:43
Mezone sec09:43
Mezpoolie: http://rafb.net/p/qMF0NF83.html09:45
poolieok09:47
pooliethis is probably because there's a directory in your working tree that you can't read09:47
poolietry just ls -laR09:48
Mezah, gnupg09:48
Mezhttp://rafb.net/p/6yTDaq68.html09:48
poolieyep09:49
Mezo_O09:50
pooliealso, bug 33865309:50
ubottuLaunchpad bug 338653 in bzr "OSError is printed without a useful filename" [Medium,Confirmed] https://launchpad.net/bugs/33865309:50
Mezthe permissions are set to the user though09:50
Mezah, no execute on the directory09:50
Mezok, now getting "no handlers found for logger "bzr"09:51
pooliewith which version?09:51
Mez1.1209:51
Mez(on intrepid)09:51
Mezthanks for the help mpool09:54
igcvila: do you have some time to give CHKInventory some test love?10:20
igcI think we need tests across both Inventory & CHKInventory for *all* the read-only APIs10:21
igcthe mutation APIs need to be tested separately of course10:21
igcwe then need to test all of the above for each of the serializer combinations, e.g. chk16, chk25510:23
AfCDamn mutants! They're everywhere! Oh, wait...10:23
igcvila: what do you think?10:24
awilkins Blimey, DVCS 4tw11:03
awilkins svn working copy of 4 branches : 713 MB on disk11:03
awilkins bzr checkouts, plus the full history of the entire project : 484 MB total11:03
Peng_awilkins: Eh. svn's lack of working copy compression FTL. They could do better than 484 MB if they wanted to.11:54
awilkinsYeah, and the 17,840 files vs 5,864 isn't too hot either11:59
awilkinsGnnnnargh my frickin mother-in-law has put all the cardboard in the recycling bin even though there is a fricking sign on the lid that says not to12:32
awilkinsNow I'll have to empty the fricking thing out or get fined or something12:32
* awilkins is sorry for the noise12:32
ToksyuryelI thought cardboard was recyclable o.O12:33
Toksyuryelare you sure the sign says not to put that in there?12:34
awilkinsYes, there is a separate pickup for cardboard/paper12:34
Toksyuryelah12:34
awilkinsThis is the plastic/cans bin12:34
Toksyuryelahhhh, I get it12:34
* Toksyuryel 's place just has one bin for all the recycling, heh12:35
* awilkins wonders if they take organic waste, like dismembered^W old meat.12:35
Toksyuryelnah, those go to the soylent green facility :P12:41
workthrickhiya12:54
workthrickso, has anyone thought about getting something like darcs's patch algebra for bzr? Darcs is absolutely neat in that branches sort of magically fall out of related changes, and that you can freely change past patches in non-conflicting ways, but the UI they add to it that tries to pass for a VCS is unbelievably shitty12:57
lukshard to do something like that in bzr where each revision has it's parents (the history forms a graph), so the order can't be changed12:59
workthrickI guess, that was also a question of "how very hard would it be to do?"12:59
workthrickbecause the patch algebra has some really cool consequences (at least as long as you don't get into exponential time corner cases :)13:00
luksby hard I meant impossible :)13:00
workthricklike the fact that darcs is the only VCS that gets merges right where a series of patches reverts changes textually, but not semantically13:01
luksthe patch theory is based on the fact that you can manupulate the order of patches, which in bzr you can't13:01
workthrickI know, so bzr would have to be hacked quite badly. I supposed as much. But would it really be completely impossible to allow reordering them?13:02
luksusing the DAG model bzr uses, yes13:03
workthrickdarcs has ordering too. It just has rules for generating a new order from the old one13:03
lukshistory in the DAG model is immutable, every state (=revision) strictly depends on everything that happened before13:04
luksif you change one piece, everything breaks13:04
workthrickso what is the model darcs uses? As far as I understand things, it's DAG + algebra for generating new, semantically equivalent DAGs13:04
luksthe main difference is that it's main object are patches13:05
workthrickoh13:05
luksin bzr it's states (revisions)13:05
luksthe fact that data are delta compressed is just implementation detail13:06
workthrickhmm13:06
luksyou can see it as if you had one full directory of files for each revision13:06
workthrickyeah, I get that13:07
davidocAnother question: is it possible to discard old revisions before a specified revision? I split a tree and I want to get rid of the revisions before the split.13:14
luksjust a few lines above I explained that something like that is not possible :)13:17
workthrickhehe13:18
luksyou can make a new branch, without the revisions13:18
luksbut the revisions you want to keep will not be identical, they will just look similar13:18
davidocoops!13:18
davidocSo how would I do that?13:19
luksI don't know of any straightforward way, unfornatunatelly13:20
pigmejis there any way to get from python api revisions where single file was changed ?13:21
davidocOh well. I suppose I can manually create a new repo with the files as they were at the time of the split.13:21
Takpigmej: yes13:22
Taklog.find_touching_revisions()13:23
pigmejTak: hmmm13:24
luksI wouldn't use log for that, but on the other hand I don't know what's the currently used API for that13:24
pigmejlog is for whole branch ?13:24
TakI'm sure it can be done by walking the revision tree if you prefer13:24
Takpigmej: it also accepts a file id13:25
luksTak: it can be done without walking the whole tree, every file has it's own tree stored13:25
luksI just don't know the current API13:26
Peng_What the? My Loggerhead instance is freaking out. "built revision graph cache: 3762.8832850456238 secs", and it's out of idle workers.13:26
Peng_It's good to know that condition doesn't melt my VPS. :)13:26
pigmejbecouse i'm afraid that checking whole tree will be wrong idea ( becouse of performance )13:26
Peng_It doesn't want to shut down, either, but that hardly makes it worse... :P13:27
DrHalanhey, i want to check out a PPA in launchpad with olive. What url do i have to use for "branch"?13:29
lukslp:bzr-gtk13:30
luksoh wait, PPA?13:30
luksdo you want to install olive from PPA or get the developmnent branch of olive?13:30
DrHalanno i want to modify a package in an PPA using olive. Isn't that possible?13:31
luksnot sure if I understand, sorry13:31
luksPPA is a way to build ubuntu packages, it has nothing to do with olive13:32
pigmejHmm in docs I find only logs method...13:32
DrHalanah okay thanks luks13:33
pigmejthe fastest way to get revision message ( commit message )13:44
pigmejrevtree=repo.revision_tree(rev_id)13:44
pigmejrevision=revtree.inventory13:44
pigmejrevision.message ?13:44
luksrepo.get_revision(rev_id).message13:49
luksor get_revisions if you need more of them13:49
lukscalling get_revision multiple times is way slower than get_revisions13:50
Peng_D'oh, I think I killed Loggerhead at the exact time when it started killing the hung threads itself.13:53
=== jelmer_ is now known as Guest87629
pigmejluks: thanks13:58
pigmeji need to call it more than one time13:58
mattionsjelmer: I've upgraded bzr to the latest released and also the bzr-svn14:23
mattionsbut still my svn password is not cached14:23
mattionsI checkout the repository directly with bzr, not svn14:23
jelmermattions: Did you force svn to cache the password?14:23
mattionscan be that the problem?14:23
mattionsI run svn ls <url>14:24
mattionsbut it doesn't ask for the password14:24
mattionsis it correct?14:24
jelmermattions, ah, you only need passwords for committing?14:24
mattionsyeah14:25
jelmermattions: So I guess you would have to do a commit with svn first14:25
mattionsbut the problem is the directory is not a working copy of svn14:26
jelmermattions: That's a workaround unfortunately14:26
mattionsok, so you suggest14:26
mattionswipe out everything14:26
jelmermattions: There's a bug in bzr itself that makes it doesn't support password caching14:26
mattionscheckout with svn14:26
jelmermattions, no, just make a temporary checkout with svn and do a commit therre14:26
jelmermattions, then remove that temporary svn checkout14:27
jelmerand everything should work14:27
mattionsor right, I'll give a go14:27
mattionsno, it doesn't work14:29
mattionsit is normal that ask the password 4 times?14:29
msoulotHi, I try to download with this command "bzr branch lp:bpierre-config-vim .vim" and I get this error message "You have not informed bzr of your launchpad login. If you are attempting a14:43
msoulotwrite operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.14:43
msoulotbzr: ERROR: Target directory ".vim" already exists."14:43
msoulotsomeone can explain me what does it mean, please ?14:44
jpdsmsoulot: Try backing up your current vim configuration: mv .vim .vim-backup14:44
msoulotok thanks but what this sentence means "You have not informed bzr of your launchpad login. If you are attempting a write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again."14:46
jpdsmsoulot: If you have a Launchpad ID, you have register it with bzr doing: bzr launchpad-login <lp-id>14:46
jpdsIt probably comes up because you're branching from lp:14:47
jelmermattions, sorry14:48
jelmermattions, doing a "svn commit" in a svn working copy didn't work?14:48
jelmerOr it didn't cache the password?14:48
msoulotI got an account on launchpad and i tried "bzr launchpad-login msoulot@gmail.com" and i got this error message "bzr: ERROR: The user name msoulot@gmail.com is not registered on Launchpad."14:49
Takdo more recent versions of bzr-svn support externs?14:49
=== montywi|talk is now known as montywi
jelmerTak: no - it technically can't14:49
jelmerTak, since bzr doesn't support externs14:49
Takever?14:50
mattionsjelmer: it didn't cache the password14:50
mattionsit worked14:50
jelmermattions, do you maybe have you svn set up to not cache passwords?14:50
mattionswell, how I can discover that?14:52
jelmer~/.subversion/config IIRC14:52
mattionswith gnoem svn the password is cached14:52
jelmerah14:52
jelmerwe may not be loading that yet for bzr-svn14:52
mattionsdefault is yes14:53
mattionsso yes is able to cache that14:54
mattionsactually bzr ask me the password 4 times when I do a commit14:54
mattions2 times when I do an update14:54
jelmerso I should fix subvertpy/bzr-svn to also use the gnome keyring svn auth provider14:55
mattionsbut here I am using another subversion14:55
mattionsnot GNOME related14:56
mattionsI never tried to use bzr with GNOME svn14:56
jelmeryou're using svn 1.6?14:56
jelmermattions, so bzr asks for a password when updating and svn does not?14:58
mattionsyes14:58
mattionssvn 1.5.114:58
jelmermattions: Can you access the root of the svn repository without a password?15:00
mattionsno, I need to authenticate to access the svn15:01
mattionsis not public15:01
jelmerhmm, so the password *is* cached by svn but not found by bzr?15:03
mattionsexactly15:06
mattionsanother interg ont eh temporary checkout if I use bzr to update or commit15:07
mattionsthe password is not requested15:07
SamBhey ... does anyone know of an (unofficial) debian package for baz-import ?15:09
luksisn't baz-import in bzrtools?15:10
SamBseems to be omitted :-(15:10
luksare you sure? because I see it in http://packages.debian.org/sid/all/bzrtools/filelist15:11
mattionsops, I've seen the sentence I wrote before is a little bit mispelled15:11
Peng_msoulot: Use your LP username (like in https://launchpad.net/~username), not your email address.15:11
mattionsI wanted to say that from the temp checkout the password is not requested for the update or the commit15:11
SamBhuh ... I guess that's what I get for using experimental :-(15:13
SamB... but pybaz is apparantly not available anymore anyway?15:14
* SamB doesn't use experimental for much, just a package here and there15:14
jelmermattions, can you check where the password is cached?15:14
jelmerluks, SamDB: It's no longer in bzrtools15:15
jelmerwas removed recently15:15
lukswell, it is in 1.5 :)15:15
jelmerluks, yes, aaron split it out15:15
luksand (sane) debian has 1.515:15
jelmersqueeze won't15:15
jelmermattions, I would expect ~/.subversion/auth15:16
mattionsyes is there15:16
jelmermattions, what version of subvertpy are you using?15:17
mattions(0, 6, 1)15:18
mattionsjelmer: on synaptic the package (python-subversion) shows up as 1.5.1dsfg1-1ubuntu15:22
jelmermattions, python-subversion is not used by bzr-svn15:22
jelmerand not the same thing as subertpy15:22
SamBtry looking at the bzr-svn package in synaptic?15:22
SamBthen go from there?15:22
mattionsI installed bzr from the PPa15:23
mattionsbut if I search for the subvertpy I can't find the package15:24
joem86hello everyone.15:24
SamBhmm, bzr-svn used to depend on python-subersion15:24
jelmermattions, python-subvertpy15:24
jelmerSamB, no longer as of 0.4.1015:24
joem86I installed bzr-gtk on ubuntu 8.10 from the default repository. Do I need to logoff and login to use nautilus-bzr?15:24
SamBjelmer: that's odd15:24
SamB0.4.10-2 seems to ...15:24
jelmerSamB, maybe 0.4.1115:25
mattionsjelmer: 0.6.1-1~ppa1~intrepid115:27
jelmermattions, Hmm, no idea then sorry15:28
jelmergtg15:28
mattionsk, no probl15:28
SamBjelmer: it looks like the BzrTools wiki page needs to be updated to point at the new home of baz-import15:32
SamB(since a number of other pages link there in connection with baz-import)15:33
SamBhmm, what I'd *really* like is support for foreign tla/baz branches15:34
SamBI actually want to look at emacs' history including merges without having to use tla *shudder*15:34
=== montywi is now known as montywi|food
=== montywi|food is now known as montywi|weekend
SamBis there a nice way to do git-style branch-switching ?16:27
awilkinsSamB: There's the switch command16:27
awilkinsWorks best in a checkout of a branch in a no-trees repository16:28
awilkins(lightweight for preference)16:28
SamBhuh.16:28
awilkinsIt will locate siblings so you can do16:28
awilkinsbzr switch foo  # my repo contains foo and bar and I am in a checkout of bar16:28
awilkinsIt doesn't have the "branches hidden inside your clone" thing16:29
awilkinsThis is a point of contention for some.16:29
awilkinsI myself don't mind it but think it would silence many critics if there was a way of supporting either method16:29
SamBis there a howto somewhere?16:31
awilkinsOff the top of my head, I can't recall. It goes.... i) make a no trees repo (with bzr init-repo) ii) branch something you are interested in into it iii) make a branch for a feature iv) use bzr co --lightweight to grab a working tree of it v) switch that at will16:36
=== ubott2 is now known as ubottu
gnomefreakwhat bzr app includes bzr-handle-patch? I'm guessing what ever one it is causes my context menu to have "open" on top(nothing ever opens and than have "open with"(is all i want to use open for)16:46
gnomefreakah bzr-gtk16:47
SamBpeculiar! the wiki is making empty <span class="anchor" id=...> elements instead of using <a id=...> or <a name=...> ...17:01
jpdsGoes anyone know where the error at http://paste.ubuntu.com/127303/ could be from?17:09
awilkinsA proxy? The web server?17:10
=== gorozco is now known as p4tux
SamBawilkins: I made a wikipage at http://bazaar-vcs.org/GitStyleBranches -- I wonder if the HOWTO I desire will magically appear ?17:35
gnomefreakhere is the command and output. it should not try to grab upstream tarball since i already have it. looked in changelog nad it is how it should be. http://pastebin.mozilla.org/63100718:13
ignashi18:13
ignascan I make a stacked branch  when branching from a branch stored in a shared repository?18:14
Peng_ignas: Sure?18:15
ignasPeng_: then why am I getting18:16
ignasSource format does not support stacking, using format: '1.6'18:16
ignas  Packs 5 (adds stacking support, requires bzr 1.6)18:16
ignaswhile on the server i am getting: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.18:16
Peng_Does it still work?18:16
Peng_And when are you getting that error? When you try to "bzr upgrade"? That's because the default format is pack-0.92. 1.6 is newer.18:16
Peng_I don't know about stacking, so I can't help much. Does the source repository have to support it?18:17
ignasoh, so if I want the newer format I must upgrade to the newer format explicitly?18:17
ignassomething is weird, both the stacked branching and lightweight checkout (i am doing it through http) are trying to download the full repository18:18
ignasand i don't really want to have to do that (it's 70 megabytes)18:18
Peng_I doubt it will download the entire repository, but it will have to download quite a bit of it to pull out all of the data it needs.18:21
=== bac is now known as bac_afk
ignasPeng_: kind of annoying, as that bit is like 20 megabytes, but it's downloading it at 30 kb/s, while checking out does 70mb at 200kb/s so I kind of don18:29
ignasdon't know what I am gaining ;)18:30
ignasok, seriously, bzr co --lightweight took 6 minutes and takes up 18 mb, bzr co took 5 minutes and takes up 51 mb (got 200kb max download speed)18:48
ignasseems like lightweight checkouts are of any use only if you are very very bandwith constrained, and will do only 1 checkout ever18:49
ignasif you want to get a branch of the same project too - shared repository will be both more space and bandwith and time efficient than 2 lightweight checkouts...18:50
Peng_What about "bzr branch --stacked"?18:51
Peng_1.) Like I said, I don't know much about lightweight checkouts or stacking. 2.) This really sounds atypical. What version of bzr are you using? It's probably been improved (especially in the release coming up next).18:52
ignasit is doing at least as much work as lightweight, but I don't want to spend the 6 minutes to find out for sure18:52
ignasbzr 1.1218:52
ignasand my project has a looong history18:52
Peng_Huh.18:52
Peng_Well, I'm surprised, but I don't have anything else to add.18:53
ignasit's quite sad, but I am not surprised18:53
Peng_Erm, how did you count how much bandwidth was used?18:53
ignasbzr has a progress bar that shows how much was downloaded18:53
ignasalso du -sh matches that number18:54
ignasfor a lightweight checkout at least18:54
ignasmostly matches ;)18:54
=== Mez_ is now known as Mez
ericvwTo any developers available, will Bazaar be participating in Google Summer of Code?19:31
=== bac_afk is now known as bac
BasicOSXAny bazaar developer launchpad team members online? I volunteered to be  the manager for 1.13 and I need a developer to push the changes into PQM20:25
jfroywhoa, there seems to be some issue with adding large files in bzr.dev20:31
jfroyI just added a 166 MB file to a branch, and Python shot upward of 1 GB of real memory before completing20:31
=== _thumper_ is now known as thumper
jammorning igc21:26
pooliehello21:26
jamhi poolie21:28
jamI'm a bit surprised to see you around on your weekend21:29
jamtrying to get the 1.9 patch finished?21:29
igchi jam, poolie21:29
poolieand to help bob tanner21:29
pooliei have to go out so i don't know if i can finish it today :/21:29
jamigc: I responded to a couple of your bbc patches21:29
igcjam: thanks very much for working on the chk-map bug. I'm testing it now21:29
pooliei was kinda hoping someone would look at the traceback and say "oh, obviously you just need x" :-)21:30
jamI also have a proposed patch which might help your performance21:30
jamas InventoryDirectory.children() didn't seem to be using _entries_cache properly.21:30
jampoolie: well I did see you return unconditionally true for Remote*21:30
jamwhich seemed a bit fishy to me21:30
poolieit was previously unconditionally false :/21:31
pooliesince that class inherited the default21:31
pooliethat seems so strange though21:31
jamjudging by the test name21:31
jamit looks like we should be using an old-format21:32
jamand have it not try to stack *at all*21:32
jamand it is checking, and naturally failing21:32
jamdid we get rid of a 'clone_on_transport' implementation?21:32
igcjam: so I got two patches with the same name - one at 7.20 and one at 7.23 (it's 7.34 now)21:34
jamigc: one is against bzr.dev21:34
jamthe other against brisbane-core21:34
igcjam: do I just apply the last one then?21:35
jammailman thoughtfully noticed that the first patch was 800k+21:35
jamigc: yeah21:35
igcto brisbane-core?21:35
jamthey are the same content21:35
igcok21:35
jam(bazaar@ rejected my first post as being too big)21:35
pooliejam, yep, in trunk RemoteBranch definitely always says it doesn't stack21:40
jampoolie: So _ensure_real() seems the right trick, but in the end, I think that would require doing "bzr branch lp:XX lp:YY" for it to ever come into play21:42
pooliei think this test is actually branching one remote branch to another21:43
pooliehm21:43
pooliei guess it would be better to avoid ensure_real and to use the network name, if we know it, to find the equivalent local format object and then ask that21:43
jampoolie: isn't that what _custom_format is about?21:44
jamAnyway, to get things *landed* I would go with _ensure_real()21:44
jamrather than spending a lot of time, the day of an RC21:44
jamOr set it back to False if that doesn't cause other problems21:44
jampoolie: ah you know what... that sort of makes sense. We are testing that if the source format is too old, we don't try to stack.21:45
jamAnd then it is layering RemoteBranch on top of that21:45
jamand by changing False => True21:45
jamit is now trying to stack, even though the real format doesn't support it21:45
jamand thus the test is failing21:45
poolieyou're talking about test_clone_ignores_policy_for_unsupported_formats?21:51
jampoolie: that is the test you showed was failing, yet21:51
jamyes21:51
ftaanyone working on a fix for the md5/sha Deprecation Warnings /w python 2.6 in jaunty?21:52
jamfta: I thought vila had a fix for that a while back21:53
jamfta: specifically, I see code like:http://paste.ubuntu.com/127469/21:54
jamIt may just be that the version in Jaunty is older than that patch21:54
jamfta: what version is there?21:54
jam(It could also be that there is other code that is importing md5/sha1 that we missed)21:54
fta!info bzr jaunty21:54
ubottubzr (source: bzr): easy to use distributed version control system. In component main, is optional. Version 1.12-1build1 (jaunty), package size 5077 kB, installed size 17328 kB21:54
jambzr --version21:54
jamI would have thought 1.12 had that... :(21:55
pooliethere are a couple of them with similar failures21:55
pooliebut all i think to do with the intersection of policy with old formats21:55
pooliehm, i should have checked what that test does in trunk21:55
pooliemaybe it just skips21:55
poolieah ok, i see now what you meant about ensure_real21:55
pooliepossibly it should fall back to ensure_real if it doesn't know the custom_format21:55
jamfta: though I also saw some discussion about things like bzr-pqm causing the problem21:55
pooliebut the thing is this is called on the format, not the branch21:55
jamand that just required another jaunty update21:55
jambecause it was an old python package21:55
jampoolie: so punt and just continue to return False21:56
pooliefta, i have a bug about it in python-crypto21:56
jamRC is *today* anyway :)21:56
pooliejam, i'll try it21:56
poolieif it actually works its fine but i think i had more failures that way21:56
igcjam: your patches have improved things a lot thanks21:58
jamigc: /cheer21:58
jamIf the directory cache helps21:58
jamgo ahead and land it21:58
jamI just wanted someone to actually run the code before I did21:58
igcjam: *but* we're still slow - 1m6s vs 40s for gc-chk255  vs 1.9 over 1k revision in wordpress21:59
jamigc: If you are having to call iter_entries()21:59
jamthen you are going to probably be slower21:59
jamwhy do you need to read the whole inventory?21:59
igcthat's with all your patches ad my iter_non_root_entries() which is still a big win21:59
jam(That kind of code is what got us into trouble in the first place)21:59
igcwell, the inventory layer is now ok22:00
igcThe time is evenly spread around chkmap.apply_delta22:00
jamigc: If you want, you can try setting _FAST = True in groupcompress.py22:01
jamAnd see how much that effects things22:01
igcjam: tell me about parent_id_basename_to_file_id is a good idea22:01
igcjam: I see you're planning to make it non-optional22:01
jamigc: it is already non optional22:02
jamall formats have it22:02
jam--dev3 was the only one that didn't22:02
jamand robert and I agreed it could just go22:02
igcthinking out loud, do we really need it for 1000s of historical revisions or could we generate it the first time it was required?22:02
jamigc: it changes only when you have a rename/add/delete22:02
jamso for 1000s of revisions, you get 10 changes22:02
jamnot a lot of overhead22:02
igcjam: well every revision has one of those doesn't it?22:03
jamigc: every revision has one, but they are all the *same*22:03
igcjam: how does it speed lookups?22:03
jamthe root chk pointer doesn't change22:03
jamunless the tree shape changes22:03
jam(rename/add/delete)22:03
jamigc: for a specific example, the python 40k revisions, has about 300k entries in id_to_entry, but only 12,000 in parent_id...22:04
jamigc: it speeds up mapping "path" => file_id22:05
jamid_to_entry is purely file_id => entry22:05
jamso you have to find an entry22:05
jamthen load its parent22:05
pooliejam, ok, changing it back to return false from supports_stacking seems to be making things pass22:05
pooliefingers crossed22:05
jametc22:05
poolieprobably by just not running those tests :/22:05
jamMore importantly, to go from a parent to its children22:05
jamyou have to iterate the *whole* inventory22:06
jampoolie: no, it says "clone ignores stacking"22:06
jamand it passes22:06
jampoolie: because you said it doesn't support stacking22:06
jamthus we ignore the stacking policy22:06
igcjam: path2id for CHKInventory is currently a copy of the code in Inventory?22:06
poolieok so not literally TestSkipped22:06
pooliebut it's not testing the real case which is that the remote branch may in fact be stacked22:06
jamigc: The issue is *specifically* InventoryDirectory.children()22:07
jamif you look at the code path I "removed"22:07
jamit walked the whole inventory22:07
jamlooking for "entry.parent_id == self.file_id"22:07
jambecause we don't have that info stored any other way22:07
jamwithout the parent_id_basename_to_file_id map22:07
jampoolie: I don't know what other tests you are looking at, but the one you posted as failing22:08
jamisn't doing that22:08
jamI'm sure there are others that probably fit what you describe22:08
jamand I think it would be great to address them in 1.14 :)22:08
igcjam: ok  - children lookup certainly needs to be fast22:09
igcjam: I'll land your chkinventory-children patch now22:09
jamigc: I keep forgetting to ask... How's the weather in brisbane?22:21
Turlhi22:22
TurlI'm getting some warnings about md5 and sha python modules, I thought you would like to know22:22
igcjam: absolutely beautiful right now22:23
Turlthat modules are deprecated (the warning says that) and you should use 'hashlib' now22:23
jampoolie: I just tried to update the BrisbaneCore page with some ideas about "major blockers". I don't know that I got everything, and it probably isn't fully polished. But that is what I've thought of so far22:23
jamTurl: there seem to be some issues with the python-crypto package in Jaunty22:24
jamwhich we depend on22:24
jamhopefully that will get resolved soon22:24
jamigc: What's the temp? (So I know what clothes to pack)22:24
igcjam: looks like there's some rain on the way but otherwise nice: http://www.bom.gov.au/products/IDQ10095.shtml22:25
Turlok jam, I thought I would let you know about this :)22:25
jamigc: I should also mention that jelmer found brisbane-core to be *vastly* faster for bzr-svn converting OOo. Something like 30hrs to do a full conversion, versus 30hrs for the first 10k revisions.22:25
jamTurl: thanks. It is a known issue, though I haven't personally followed closely.22:26
pooliegreat22:26
Turlnp jam22:27
pooliethat was bug 33707322:27
ubottuLaunchpad bug 337073 in python-crypto "python-crypto uses sha module that's deprecated in python2.6" [Medium,Confirmed] https://launchpad.net/bugs/33707322:27
igcam: I saw that result from jelmer - it's very promising22:27
igcjam: ^^^22:27
jamigc, poolie: have a good day. I'm done for now. I may sign on later tonight just to do a quick review before I leave tomorrow, but no guarantees22:27
jamigc: so that brings back the question of why you ever have to deal with the whole inventory.22:27
jamigc: I should also mention that "time bzr fast-export" of my mysql-525 stuff was down around 1 minute. which is == git fast-export on the same data22:28
jamigc: that said, "time bzr repository-details" which extracts everything to fultexts, and analyzes chk pages22:28
jamis 15s22:28
jamso there is still some room22:28
jam(just extracting the texts, with no sha sums, etc, is around 6s)22:28
igcjam: yes, fast-export seems pretty good and I've done zero profiling/tuning on it22:28
abadger1999Is there someway to turn off ensure_config_dir() ?22:28
abadger1999ensure_config_dir_exists()22:28
igcjam: I'm only dealing with the whole inventory when loading texts. I'll see what the latest repo code does there22:29
pooliejam, ok, have a good night22:29
pooliei have to go and run some errands22:29
pooliethat test is still failing22:30
poolie i may poke at it later but it may miss at least rc1 as i expect bob will do that soon22:30
abadger1999we're working on a server that submits to a bazaar repo.  It runs as apache.22:31
abadger1999When we run this: work_tree.smart_add([self.path]) It tries to create a .bazaar directory in apache's home dir.22:31
igcjam: _install_revision still walks the whole inventory via iter_entries()22:31
igcjam: fast-import uses a parameterized version of that code22:32
jamigc: consider how InterDifferingSerializer does it22:32
jamwhich is able to use _make_delta etc and not need full inventories22:32
jamI don't know what you need, I just know that if you have to walk the whole inventory22:32
jamthings will be slow22:32
jamso we need to think if there is a way around it22:32
igcjam: right. I'm not sure whether jelmer was going via repo.install_revisions() or not22:34
igcif he was, he would have hit the iter_entries() speed issue that existed until just now?22:35
jelmerigc: no, I'm not using repo.install_revisions()22:37
jelmerigc, I'm using add_revision(), create_by_apply_delta() and directly accessing the texts VFs22:38
igcjelmer: so IIUIC, install_revisions() is walking the inventory to build the per-file-graph? Are you doing that some smarter way?22:42
jelmerigc: bzr-svn stores the per-file graph22:43
jelmerand for non-round-tripped revisions, subversion provides the necessary data22:43
igcso the OOo conversion to development5 only works if bzr-svn is used?22:44
jelmerigc: Not sure I understand22:48
rockyjelmer: ping22:49
jelmerigc: The conversion doesn't require round-tripped-revisions or anything, it works with a vanilla OOo SVN repo22:49
jelmerrocky, pong22:49
rockyjelmer: i decided in an effort to force myself to understand things more i would rewrite get_history() for BzrFileNode in TracBzr (ti's currently what's breaking on bzr 1.12 anyways) ... and i've getting a better understanding such that i can populate the log view properly...22:50
rockybut my revision identifiers are nasty ... they are branchpath,fileid22:51
rockyand in the trac log view that looks horrible22:51
jelmerrocky, branchpath,revid?22:51
rockysorry yes22:51
rockythe branch path is fairly long, and the revision_id is huge22:51
rockyso it really messes up the log view display22:52
rockyis there a more sane way to reference a rev?22:52
igcjelmer: I'm trying to work out how you converted the OOo repo so quickly to development5-subtree format22:54
igcjelmer: fast-export is currently slower on the new formats22:55
igcs/export/import/22:55
jelmerigc, ah22:55
jelmerigc, yes, bzr-svn would be required for the improved performance22:55
jelmerrocky, path,revno?22:55
=== UdontKnow is now known as UdrunKnow
rockywhat's the diff between a revno and a revision_id ?22:56
jelmerigc, I was also using an improved version of brisbane-core, with another patch22:56
jelmerrocky, a revno is smoething like "2"22:56
jelmerrocky, a revision id is something like "jelmer@samba-org-20083424782362386-0fjksdhgfkjsdh"22:56
=== UdrunKnow is now known as uDrunkNow
rockyjelmer: right, i understand that they look different but what i mean is what limits one versus the other... why have a revno and a revid ?22:58
jelmerrocky, revno is more human readable22:59
jelmerrocky, it's only unique to a particular branch though22:59
jelmerrevid is used internally in Bazaar and globally unique22:59
jelmeralso, revno's are sortable23:00
jelmerso revno 42 is always older than revno 4323:00
rockyso revid's are meant to be actual uuid's ?23:00
jelmerrocky, they are globally unique but not like RFC412223:01
rockydefine "global" :)\23:01
jelmerrocky, e.g. bzr-svn uses the UUID of the svn repository and the revision number of the subversion commit for the bzr revid23:02
jelmerrocky, global as in the same revid is supposed to always point at the same revision23:02
jelmerindependent of what branch or repository it is in23:02
jelmerrocky, e.g. try running "bzr log --show-ids" in one of your branches23:03
rockyah cool23:03
rockyjelmer: ok, in any event, the log view works now and doing diff between revs on log view works and clicking on a rev link works... bt clicking on a changeset link doesn't yet work23:13
jelmercool23:14
rockyjelmer: here's a question... in a branch, does revno *have* to start with 1 and is it guaranteed not to skip revno's ?23:15
jelmerrocky, there are functions in bzr for looking up the revno23:15
jelmerrocky, ideally you should be using those rather than calculating them yourself23:15
jelmerthat would also do caching when it's available23:16
rockyi'm only asking because i found code inside bzrlib that is adding up it's revno's by itself ;)23:16
rockyin bzrlib.log23:16
jelmerthey can also get quite complex if they're not on the mainline23:16
rockythe whole dotted revno thing right?23:17
jelmeryeah23:17
jelmerigc: This is all the more reason to move this logic into a Importer object in bzrlib :-)23:45
igcjelmer: Agreed! Once I get this version working fast, I'll do that. Next week's sprint will be a good time to talk to lifeless and jam about it23:50

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