/srv/irclogs.ubuntu.com/2010/05/04/#bzr.txt

flutherbenHi all. Hope someone can help me here. I upgraded my box, and now I'm having trouble deploying. When I run "bzr revno http://mydomain/myrepos" I get a transport error01:34
flutherbenspecifically: bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)01:34
flutherbennevermind--this is a capistrano error01:38
lifelessspiv: hai03:04
mkanatOkay, if a merged merge proposal didn't fix an issue, do I submit a new one or just update the existing merge proposal?03:07
lifelessnew one03:07
lifelessreference the old if discussion in it is still relevant03:07
mkanatlifeless: Okay, thanks.03:08
awmcclainI have a pending merge; I've bzr reverted a file because i needed to temporarily get rid of it. Is there a way to now fetch that file again from the other branch without checking in beforehand?03:10
lifelessawmcclain: yesish03:11
awmcclainoh, i like ish.03:11
lifelessawmcclain: first, a note - if you want to temporarily get rid of things like that, use 'shelve'03:11
spivlifeless: hey03:11
lifelesse.g. bzr shelve filename --all03:11
awmcclainlifeless: Interesting. Even on a pending merge?03:11
lifelessawmcclain: if the file on the other branch wasn't changed in your current branch, you can do 'bzr revert -r branch:pathtootherbranch filename'03:11
awmcclainlifeless: That's correct. The file is a new file.03:12
awmcclainIntroduced by the merge03:12
lifelessawmcclain: if it *was* changed in your branch, you can't trivially get the merge back, but donig the revert above and then looking at the diff would let you figure things out03:12
awmcclainNo, it wasn't changed. Just added. Ok. Great! Thanks03:12
lifelessawmcclain: yes; shelve filename == revert filename, except you can get it back more easily.03:12
awmcclain good to know!03:13
lifelessawmcclain: where shelve != revert, is when you just do 'bzr revert', because that discards the pendnig merge.03:13
awmcclainDidn't shelve use to be a plugin?03:13
lifelessawmcclain: yes03:13
awmcclainAnd now is part of bzr?03:13
lifelessyes03:13
awmcclainWonderful. Thank you!03:13
lifelessspiv: fud ? early avo perhaps ?03:14
spivHmm, could work.  Here or there?03:15
awmcclainlifeless: That revert command worked perfectly. Thank you03:15
lifelessspiv: sure03:15
lifelessspiv: mt colah's food facilities are, uhm, limited ;)03:16
lifelessawmcclain: my pleasure03:16
spivlifeless: ok, so Hornsby somewhere.  Maybe name a time to meet at the fountain?03:17
lifelessspiv: looking @ train timetables03:18
lifelessdear chityrail, your website is terrible03:19
lifeless1:30 ?03:20
spivSounds good!03:20
lifelessjames_w: patch done03:59
lifelessspiv: omw04:09
lifelessbe there in 10-1504:09
mkanatmwhudson: https://code.edge.launchpad.net/~mkanat/loggerhead/synchronize-lru_cache/+merge/2465104:10
lifelessspiv: do you need a review on that patch?06:44
spivOh yeah.  Just a sec.06:45
spivlifeless: <https://code.edge.launchpad.net/~spiv/bzr/repo-refresh-data-574236/+merge/24653>06:46
lifelessspeaking of cameras06:52
lifelesshttp://gizmodo.com/5529710/59-fiercely-focus-stacked-photos06:52
spivCute!06:56
lifelessspiv: reviewed.06:59
lifelessI wants tweak.06:59
spivlifeless: ok07:03
lifelessyou may find (I hope not) that when you add the all_revision_ids call (and presumably one after or something :P) that it breaks.07:05
lifelessspiv: I didn't say this in the review, but hopefully its obvious, that you'll want a commit already present, so actual data merging happens.07:05
spivFair enough.07:06
spivI did consider constructing a more evil test where I make stream sink and source, and then arrange for refresh_data (and the concurrent fetch) to be done part-way through inserting the stream.07:07
spivBut the effort involved didn't seem justified.07:08
lifelessI don't expect that to be interesting07:08
lifelessbecause the disk atomicity is well established07:08
lifelessand the various bits are pretty well established07:09
lifelessbut still - nice thinking ;)07:09
spivRight :)07:10
vilahi all07:37
spmyo vila!07:43
kizzoI get an error when trying to use bzr-git to branch the git repository found on here: http://sourceforge.net/projects/unison/develop07:47
kizzoOn that page, the git repo url is "git://unison.git.sourceforge.net/gitroot/unison/unison"07:47
kizzoThe command I try is "bzr branch git://unison.git.sourceforge.net/gitroot/unison/unison"07:47
kizzoThe error I get is "bzr: ERROR: exceptions.TypeError: expected string or buffer"07:48
lifelesskizzo: file a bug at bugs.launchpad.net/bzr-git07:48
jelmerkizzo: you need a newer version of bzr-git07:48
kizzo[ there is more to the error message, but it just explains that it's an internal error, and how to file a bug.07:48
jelmerkizzo: urllib's behaviour changed in a minor python release and broke bzr-git07:48
kizzoAlrighty, I'll try and update things.07:49
kizzoHmm, I don't know how I would update that though - I ran aptitude update and aptitude safe-upgrade on my Ubuntu Lucid, but I'm already up to date.07:53
kizzoI guess I'm going to have to grab the latest tarball from the main bzr-git site.07:58
lifelessjelmer: what version fixes it ?07:58
jelmerIIRC 0.5.007:59
kizzoI'm not sure - the latest is 0.5.0, and the one installed on my system is 0.4.307:59
lifelessjelmer: I suggest you put a SRU for bzr-git together _asap_ then.08:00
kizzoShould I uninstall my version first, before doing "python setup.py install" for the new version?08:00
lifelesskizzo: grab the deb package for bzr-git from debian08:00
kizzolifeless: I double-clicked the deb file to install it, but it says error: Error: Dependency is not satisfiable: python-dulwich (>= 0.5.0~)08:03
kizzoBoo.08:03
lifelesskizzo: that one too :P08:04
kizzoYeah I started figuring - dang.08:04
kizzoThings are working now, thanks.08:09
kizzoThe command works now.08:09
jelmerlifeless: I won't have time for that before UDS unfortunately.08:09
lifelessjelmer: its actually pretty straight forward to start one - are you positive you don't have time ?08:10
lifelessjelmer: how big is 0.4.3->0.5.0; is grabbing all of it feasible ?08:11
jelmerlifeless: it's probably too big for a SRU08:13
lifelessjelmer: is a backport of that fix feasible ?08:13
jelmerlifeless: it's feasible, but nontrivial. The last SRU I did took me an hour or two that I don't have right now (on leave during the last days of the week).08:14
lifelesssure08:14
lifelessdo you remember the bug number of the original report ? or a good search string ?08:14
lifelessactually, bug 556968 is it08:15
ubottuLaunchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository" [Undecided,Confirmed] https://launchpad.net/bugs/55696808:15
kizzoShould I post my solution there?08:19
lifelessno, I'll note that down.08:20
kizzoJust to mention what I did to fix it.08:20
kizzoAlrighty.08:20
lifelessspiv: nb: bzr-git(ubuntu) bugs may not be visible to jelmer - you probably want to 'affects project' on them08:21
lifelessspiv: I refer to https://bugs.edge.launchpad.net/ubuntu/+source/bzr-git/+bug/53219208:21
ubottuLaunchpad bug 532192 in bzr-git "bzr crashed with TypeError in open()" [Undecided,New]08:21
spivlifeless: ah right.08:22
lifeless(which I've just done)08:22
spivI don't tend to look to closely at if a bug is filed on distro. vs. upstream08:22
lifelessindeed08:22
lifeless[me neither, not explicitly anyhow]08:22
spivHmm, it's unfortunate that a test that does "tree = self.make_branch_and_tree('foo'); tree.commit('blah')" can't simply have self.make_branch_and_memory_tree substituted without adding a few lines of boilerplate.08:45
lifelessspiv: agreed08:46
=== oubiwann is now known as oubiwann_
mtaylorlifeless: can you think of any decent reason why I can't use bzrlib from jython?09:26
mtaylorimport bzrlib just worked09:27
lifelessmtaylor: someone is working on it.09:27
lifelessmtaylor: file bugs.09:28
mtaylorlifeless: oh neat09:28
bialixheya09:28
mtaylorlifeless: as in "just try to use it normally and file bugs" or - go find the jython-bzr project and file bugs there?09:28
lifelessmtaylor: file them on bzr itself09:28
mtaylorcool09:28
mtaylornow - to solve jython maven integration...09:29
lifelesshi bialix09:30
bialixvila: ping09:34
vilabialix: pong09:34
bialixbonjour vila09:34
bialixI'm not quite understand your review09:34
vilabialix: which part ?09:34
bialixFor all *files* you check that the *directory* is not a branch. <-- what do you mean?09:34
bialixand I don't understand this: The correct way to do this would be to prune the directory and *all* of its content when it's first processed.09:35
bialixat all09:35
vilabialix: if you have a nested branch with thousands of files, they are all included in the list you're processing09:35
bialixvila: no09:35
bialixthis is not correct09:35
vilabialix: you rely on tree.extras() right ?09:36
bialixonly the directory with the branch will be in the list09:36
vilabialix: no09:36
vilaat least I don't think so reading the code09:36
bialixvila: I'm relying on what clean-tree do before09:36
vilatree.extras() filters out all the files present in the inventory but walks the whole tree09:37
vilabialix: I didn't say you didn't :)09:37
bialixvila: http://pastebin.com/WHDxuCc909:38
bialixthere is no entries from nested branch09:38
vilabialix: re-read my review, I'm not saying your code is incorrect,09:39
bialixvila: I don't see any reliable way to filter out files, other than using isdir() check09:39
vilaI say it will process too much09:39
bialixit will process the list twice09:39
vilabialix: once you know a dir is a branch, you don't need to even look at the dir content09:39
bialixbecause actual delete code also checks for file/dir09:40
bialixvila: there is no dir content in the deletables list09:40
bialixonly dir itself09:40
vilabialix: ??? you mean if you have '.' you don't have './foo' ?09:41
bialixhttp://pastebin.com/1SHdFxaW09:41
bialixI mean if I have foo, I won't have foo/bar09:41
vilabialix: even in deletables ?09:43
bialixin my understanding bzr won't recurse into ignored/unknown09:46
vilabialix: !09:47
bialix?09:47
vilabialix: you're right !09:47
bialixok09:48
vilabialix: sorry for the noise :)09:49
vilabialix: may be worth a comment :)09:49
vilabialix: ' bzr won't recurse into ignored/unknown' captures this right09:50
bialixokay, will do09:51
* bialix updating the patch based on the review of vila and partm09:52
bialixvila: what should I do for backporting the patch to 2.1 once it will be approved?09:52
bialixwho is in charge?09:52
spivbialix: there's no-one specifically in charge09:53
spivbialix: simplest is probably for you to make the backport and propose it for merging.09:53
bialixso I just will need to file a mp against 2.1, that's all?09:53
bialixok09:53
spivRight.09:53
bialixvila: ok, so there is still a problem09:54
bialixif foo is unversioned, and foo/bzr is a branch then we happily remove it09:55
bialixfoo/bar09:55
bialix(something strange in the fact that both a and z are so close on the keyboard)09:55
bialixbut I don't think we want to handle this due the performance as you say09:56
vilabialix: it would have been better to start by targeting 2.1, releases branches are regularly (handwaving) merged into trunk09:56
bialixI can rebase, perhaps09:57
vilabialix: urgh :)09:57
bialix:-)09:57
vilabialix: kidding, yes, now, rebase is probably the easiest09:57
bialixbut I don't mind just cherrypick patch to 2.109:58
spivI just cherrypick in that situation.09:58
vilabialix: regarding branches 'hidden' below ignored or unversioned, a FIXME would be welcomed as well09:59
bialixvila: http://pastebin.com/rg9h5F1k09:59
bialix?10:00
vilabialix: won't skip is unclear, 'we will delete the nested branch' is more explicit10:00
bialixhttp://pastebin.com/B3RhHxgh10:01
bialixvila: should I add note about skipped bzrdirs as partm suggested?10:02
bialixsorry, parthm10:02
vilabialix: well, the second reviewer may have a different opinion but I'll land this proposal and make a new one for that instead...10:05
vilabialix: except if it's really trivial to add10:06
GaryvdMHi all10:06
vilahey GaryvdM !10:06
GaryvdMI'm looking at https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/2053710:06
vilaGaryvdM: great10:06
bialixvila: the problem in the correct wording10:06
GaryvdMIs there a guide anywhere to runing the test suit under wine?10:07
bialix*is10:07
bialixGaryvdM: heya!10:07
GaryvdMHi bialix10:07
GaryvdMHi vila10:07
vilabialix: start with Martin's suggestion (was it bzr control component ?), that can be refined later or even tweaked based on the second review10:07
bialixI've tested it manuall and I don't like how it mingle with the list of paths to delete10:18
bialixlp is rwad-only, does it means I can't push my branch?10:20
bialixlp is read-only, does it means I can't push my branch?10:20
GaryvdMbialix: yes10:23
GaryvdMSeem like we can't pull either10:26
* GaryvdM is running "wine c:\\python26\\python bzr selftest" :-)10:29
* bialix hopse GaryvdM has very fast hardware, otherwise he can go for lunch and maybe dinner10:30
GaryvdMah - with -s bzrlib.tests.test_diff10:30
funkyweaselGood morning.  I recently upgraded to Ubuntu Karmic and bzr 2.0.2.  Unfortunately our repository server is stuck on Hardy / bzr 1.3.1.  I know find branching and status hellaciously slow.10:34
bialixapt-get?10:34
GaryvdMfunkyweasel:  Are you running a bzr smart server on the Hardy server?10:36
funkyweaselWe're not able to upgrade the repo server at this time.  Is it a known issue that newer versions of bzr have difficulty with branches generated by older versions of bzr?10:36
funkyweaselGaryvdM: No.  But it sounds like a good idea when we move the repo server to the new Ubuntu LTS.10:37
GaryvdMfunkyweasel:  Please tell us what repo formats the branch on the server is, and the branch on your pc is.10:38
GaryvdMfunkyweasel:  bzr info -v10:39
funkyweaselGaryvdM: repo: Packs containing knits without subtree support, local: Knit repository format 1.  Noted that it took about a minute to count the revisions on local.10:41
bialixfunkyweasel: you have old format in local tree10:42
bialix`bzr upgrade --pack-0.92` on local10:42
funkyweaselbialax: Yes, I thought that too.  But if I upgrade using 2.0.2 it becomes incompatible with the repo server.  I can no longer commit.10:42
bialixfunkyweasel: I've wrote format1 plugin that force pack-0.92 as default10:43
funkyweaselNow that I have not tried.10:43
bialixfunkyweasel:  upgrade --pack-0.9210:43
bialixthere is explicitly defined the format10:43
bialixyou have to avoid upgrade to anything newer than --pack-0.9210:43
bialixor --rich-root-pack10:44
GaryvdMfunkyweasel:  -bialix: Please will you do me a favor:  Please run bzr selftest -s bzrlib.tests.test_diff.TestEncodedDiffFromTool in this branch: lp:~vila/bzr/523746-difftool-file-names10:45
GaryvdMfunkyweasel:  Sorry last msg not for you10:45
GaryvdMbialix:  I get this error in wine: http://paste.ubuntu.com/427530/10:45
bialixGaryvdM: codehosting is offline10:46
GaryvdMbialix: oh forgot that.10:46
bialixbzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10061, 'Connection refused')10:46
GaryvdMbialix: I'm not sure if it's wine specific10:47
bialixonce lp going back online, ping me10:47
GaryvdMbialix:  thanks.10:47
GaryvdMvila: any idea how to fik http://paste.ubuntu.com/427530/ ?10:48
GaryvdM*fix10:48
vilaGaryvdM: let me check, but from memory the last commit in my branch was trying a different approach and didn't pass tests as I wanted some feedback first10:48
GaryvdMvila: Tests work in ubuntu, but not wine.10:49
vilaoh, failure while *reporting* the failure, different bug, not sure this branch includes the related fix10:50
vilaGaryvdM: Hmm, I was thinking about reno 5163 on bzr.dev but the fix seems to be present :-/10:52
GaryvdMvila: Ok - If don't know - let me debug a little10:53
GaryvdMlaunchpad code hosting back up10:59
anddamhello11:06
parthmanddam: hi11:08
anddamI'm trying to figure out the difference between checkout and branch11:08
anddamI read "Core concepts"11:08
anddamhttp://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html#centralized says "They run bzr update to get their checkout up-to-date, then bzr commit" but step 1 is checkout11:10
anddamis it done only once?11:10
parthmanddam: checkout are similar to traditional svn checkout11:10
anddamok I'm fine with that11:10
anddama branch is a "ordered series of revisions", how does that make any difference?11:11
parthmanddam: when you commit to a checkout, it is committed to the place from where you checked out. branch commit is local.11:11
anddamso "branch" is like "my own branch"11:11
parthmyes. branch is your own. checkout is more like central ... with the place from which you checkout being the center.11:12
anddamwhile a commit to a checked out working dir would write on main development repository (or wherever the working dir has been checked out from)11:12
anddamthanks11:12
parthmyes.11:12
parthmwith checkout you also have the --lightweight option which is very close to svn/cvs11:13
parthmwith a branch you will need to either push, or merge into trunk/mainline. checkout commit goes to mainline by default.11:13
parthm"bzr help checkouts"11:14
bialixGaryvdM: I've ran the test; he same error here11:17
bialixGaryvdM: I've ran the test; the same error here11:17
=== kgoetz is now known as Kamping_Kaiser
a212901390231901<mtaylor> lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html11:22
a212901390231901now I'm off out.11:23
GaryvdMbialix:  thanks.11:25
bialixhi a212901390231901 Ж-)11:26
bialixhi a212901390231901 :-)11:26
a212901390231901that makes a pretty good monster smilie11:27
bialixI'd say it was insects smilie11:28
bialixin russian11:28
funkyweaselbialax: This upgrade is taking an extremely long time.11:28
bialixpoor lp, it seems to be very heavy loaded11:29
bialixfunkyweasel: maybe you have a very big history?11:29
funkyweaselbialax: I do.  But bzr 1.3.1 seemed to cope with it much better.11:29
a212901390231901it's caught up with bzr.dev but not my branch for review yet11:29
bialixsometimes it's much easier just to get the new branch from the server, because it seems you have it in decent format there?11:30
funkyweaselOh.11:30
funkyweaselIt's spent a while 'checking repository format'11:31
bialixwhat?11:31
funkyweaselThat's the stage the upgrade is on.11:31
bialixdo you have local branch, not a checkout?11:31
a212901390231901bialix, just to clarify on your ctypes-users question, cdll['foo'] code calls getattr which forwards to the same method that cdll.foo uses11:32
a212901390231901and now I really have to go.11:32
bialixok11:32
funkyweaselbialix: I branched from the local copy and set it upgrading to --pack-0.92 with the intention of then pushing it to the repo server, and binding to that version on the repo server.11:33
bialixfunkyweasel: how many revisions/files in the branch?11:33
funkyweaselIn the vague hope I'll get back the old performance I had a week ago on my hardy/bzr1.3.1 box11:33
funkyweaselSadly it's 3976 revisions.  It's an old tree.11:34
bialixit's not very big, I think11:34
bialixcan you look into .bzr.log and see what it doing actually?11:35
funkyweaselI'm quite frustrated at how the performance has plumeted since upgrade.11:35
bialixvila: ^11:35
bialixany hints?11:36
funkyweaselbialax: Ah,  xxxx.yyy opening working tree '{branch path}'11:37
funkyweaselxxxx is 3058, yyy is 536, both increasing rapidly.11:38
funkyweaselI noticed that it seems to go really quick except for the last 900 or so revisions.11:38
bialixxxxx.yyy is the timestamp11:38
funkyweaselNot revision number?11:39
bialixit seems there is multiple opening of working tree. strange. bug?11:39
funkyweaselbialix: I don't know.  Is 2.0.2 buggy then?11:39
funkyweaselSaddening.11:40
bialixbzr has revno either NNN or NN.B.K11:40
bialixthere is 2.0.5 released11:40
funkyweaselIt's really impacting my work flow.11:40
bialixcan you upgrade from bzr PPA?11:40
funkyweaselI don't know.  Can I?11:40
bialixhttp://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu11:41
funkyweaselAt the risk of sounding horribly plaintive - I'd rather like it to work like it used to please.  But progress, I imagine...11:41
funkyweaselI'm on the latest for Karmic, my current distro on local box.11:41
* bialix is not Ubuntu expert, sorry11:42
funkyweaselIt's taken me nearly all morning to try and get a new branch.  This is highly inefficient.11:42
funkyweaselAnd this checking process is consuming 100%.  Which is also nice.11:43
bialixupgrade is one time operation11:43
funkyweaselbialax: True.  And it's typically worth it.11:44
funkyweaselIt's odd how repo versions have broken between 1.3.1 and 2.0.2 though.11:44
bialixI can't comment this11:45
bialix1.9 format is very nice11:45
funkyweaselThe latest one is that?11:46
jelmerthe latest format is 2a11:47
GaryvdMNo - 2a is the latest format, but it is a rich root format, and so you wont be able to push from a 2a format to the format on your server11:48
funkyweaselNice one.11:48
funkyweaselI think a lot of our problems will be solved once we push our repo server up to the latest Ubuntu LTS and upgrading the branches there.  Trick is 1. waiting for the LTS to be post-launch stable and 2. finding time to upgrade our repo server.11:49
bialixfunkyweasel: are you upgrading standalone branch or branch in the sahred repo?11:51
funkyweaselbialix: Made a local dev branch from the local trunk branch.  Upgrading the local dev branch.  Which is why I am surprised it's taking so long.11:52
funkyweaselIt's now taken over an hour on this upgrade.  Is this normal?12:00
=== mrevell is now known as mrevell-lunch
GaryvdMfunkyweasel:  Are doing "bzr upgrade --pack-0.92" - Is this normal > think so. It's a one time operation. Go get lunch :-)12:05
funkyweaselGaryvdM: Cheers man, and that's an excellent plan.  Unfortunately I have a script that does a mailout that needs to go out as soon as possible - it was due first thing this morning but the format was broken so we've delayed it til it can be fixed.  So... spending all morning trying to make bzr work at the speeds it used to has consumed the morning, pretty much.12:07
GaryvdMfunkyweasel:  Sorry man12:09
funkyweaselNo worries.  I should have known this would take a while and put up with the now-ball-crunching slowness of bzr2.0.2 on pre-RichRoot repos.12:10
GaryvdMfunkyweasel: If you want to stop it, it upgrade creates a backup which you can restor.12:10
GaryvdM*restore12:10
GaryvdMThe outer thing you can try:12:11
funkyweaselGaryvdM: True, but it's been going for so long that I don't want to quit it.  I've started working on the local copy of thetrunk so I can actually get something out soon.12:11
GaryvdMmkdir temp12:11
* GaryvdM rather puts this into paste bin12:11
bialixfunkyweasel: may I ask to send your notes to bzr ML about your experience when it finished?12:11
bialixfeedback ftw12:12
GaryvdMfunkyweasel:  You can try this: http://paste.ubuntu.com/12:13
GaryvdMbialix: Please check that for me ^12:14
bialixGaryvdM: do you want me to pasteyou what?12:14
GaryvdMOh - sorry. This: http://paste.ubuntu.com/427580/12:15
GaryvdMThis will, rather than upgrade the local copy, just refetch from the server, in the same format as the server.12:15
GaryvdMfunkyweasel: ^12:16
funkyweaselbialix: Sure thing.  Will filter out lightly-stressed incuded btching on my part. :)12:16
bialixthat's correct12:16
funkyweaselGarvydM: That looks promising.12:17
=== bialix is now known as bialix-lunch
=== salgado-afk is now known as salgado
GaryvdMvila: could you please do a second review on https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/2448312:54
parthmGaryvdM: thanks for the review.12:56
parthmvila: just wanted to point out that line 64-65: unused "from bzrlib import tests" is now gone. i am waiting for branch refresh.12:57
vilaparthm: just for context, is there some progress bar shown in that case ?12:58
GaryvdMvila: Yes, the progress bar shows bellow the message.12:59
parthmvila: the message (may take time) is shown. and in the next line the usual progress bar 'fetching revisions' etc. is shown.12:59
vilaparthm: then I think the 'may take some time' is superfluous, do we use this elsewhere ?13:00
parthmvila: i think the intent is that for the user "checkout" indicates a fast operation (unlike, branch). however as checkouts are heavyweight by default they take the same amount of time.13:01
parthmvila: hence the message.13:01
GaryvdMparthm: Maybe: 'Copying history to "test". To checkout with out copying history, use --lightweight'13:02
GaryvdM*without13:02
vilaparthm: I like Gary's suggestion. My point was that the progress bar *should* tell the user that it will take some time, and after a few seconds he should even feel how much (better than "some")13:03
parthmyes. thats fine by me. i will update and push.13:04
vilaparthm: you have pqm rights now, right ?13:05
vilaor did I goofed again ? :-D13:05
parthmvila: yes. thats working fine :)13:06
GaryvdMvila: :-)13:06
parthmvila: thanks.13:06
vilaparthm: cool, so feel free to land13:06
vilaparthm: I've approved13:06
parthmvila: sounds fine. i will update the user message and land it.13:06
parthmvila, GaryvdM: thanks guys.13:07
sangiwhen i try to do bzr push, getting an error like bzr: ERROR:parent directory of bzr+ssh:/the/path/of/remote/server/ does not exist13:23
sangican anyone give solution for this error13:23
GaryvdMvila: Should I be going through the "Other reviews I am not actively reviewing" section of activereviews, or should I leave that?13:24
GaryvdMsangi:  Create the parent dir manually.13:25
vilasangi: --create-prefix13:25
sangiGaryvdM, how to create parent dir13:25
vilasangi: bzr help push, look for --create-prefix13:26
vilaGaryvdM: that would be nice13:26
sangivila, ok13:26
GaryvdMvila: oh - I didnot know about --create-prefix13:26
vilaGaryvdM: haaa, too clikety-click GUI only guys :-P13:27
GaryvdMvila: all of the mp's that I have looked in that section have a review request to a specific person (typically lifeless.)13:29
vilaGaryvdM: you're done then :-/ Or you can nudge lifeless  :-P13:29
GaryvdMvila: Ah - found one that needs a second review13:30
vilaGaryvdM: don't forget to set the status to 'Approved' when you find (or make) one with 2 approved reviews13:31
GaryvdMvila: Or just submit to pqm ?13:31
vilaGaryvdM: both :)13:31
GaryvdMok13:31
GaryvdMvila: Don't you have a all hands this week?13:35
=== bialix-lunch is now known as bialix
vilaGaryvdM: no13:35
vilaGaryvdM: there may be a some hands though :)13:36
=== oubiwann_ is now known as oubiwann
=== oubiwann is now known as oubiwann_
sangiafter pushing the edited source to the remote server using bzr push, the changes are not getting effected in the source which is there in the remote server13:52
vilasangi: yes, only the branch is updated, not the remote working tree, you want the push_and_update plugin13:54
sangivila, how can i install it13:56
GaryvdMsangi: First, do you have ssh access to the remote server?13:57
vilasangi: like all other plugins ?? No wait, what OS are you on, what bzr version are you using ?13:57
GaryvdMpush_and_update requires13:57
GaryvdMpush_and_update requires that..13:57
vilasangi: and yes, Gary is right, do you have ssh access ?13:58
sangivila, yes i have ssh access13:59
sangibzr version is 1.113:59
sangivila, using debian14:00
vilasangi: 1.1 ??? wow, that's more than old, can't you find a more recent one ?14:01
GaryvdMsangi: I dont think that there is a debian package, so the easiest way to install it is:14:02
sangivila ok i will install the latest14:02
GaryvdMcd ~/.bazaar/plugins14:02
GaryvdMbzr branch lp:bzr-push-and-update push-and-update14:02
vilasangi: anyway, it's a unix, so :  bzr lp:bzr-push-and-update  ~/.bazaar/plugins/push_and_update14:02
vilaghaaa, bzr *branch* of course14:03
sangiGaryvdM, ok14:03
sangivila, ok14:03
vilahmm, may be not the best time to use lp :-/14:04
vilasangi: note the - and _14:04
sangivila, ok14:05
GaryvdMah - mine is wrong...14:05
vilasangi: so, quickly reading the code, 1.1 may be supported, give it a try, you get a new push-and-update command, the regular push receives hook (*this* may require a newer bzr) that will trigger the update if a remote working tree exists14:08
vilasangi: if all else fails, what this plugin does is: bzr push ; ssh <host> ; cd <right_place> ; bzr udpate14:09
bialixvila: do I need second vote on clean-tree patch?14:10
bialixthanks btw14:10
vilasangi: and the reason we don't update remote working trees is that... you generally have no working trees there and performance will be bad for most protocols14:10
vilabialix: ha, AFAIR you're still a core committer, based on that, no :-P14:10
sangivila, ok14:10
bialixvila: yes, my retirement plan has failed.14:11
* vila evil laugh14:11
bialixI hope you helps me to push it into pqm?14:12
bialix*help14:12
GaryvdMbialix: It's not to hard to setup pqm-submit14:12
GaryvdMbialix: it is worth it to.14:13
GaryvdMbialix: I can't see that it would be more difficult on windows.14:14
bialixGaryvdM: when I was core committer I've sent pqm mails manually14:14
bialixI'll delay installing pqm plugin till UDS14:14
bialixso smart people will helps me with word and deed14:15
bialixnever mind my english14:15
GaryvdMbialix: I guess you will be able to do submit through launchpad web interface soon...14:16
bialixso I can procrastinate more ;-)14:16
funkyweaselGoodness me.  That upgrade is *still* going, nearly 3 hours later.14:16
bialixfunkyweasel: it hurts to hear this14:16
funkyweaselI *do* think there's something seriously wrong with this version of bzr and my set up.  There's no way even a point-version should break things this badly.14:17
a212901390231901upgrade does take ages, when I upped bzr.dev it was a multi-hour thing14:17
funkyweaselThis is less than 4000 revisions.  And it did not take this long under 1.3.1.14:18
funkyweaselWhich, after all this, I am tempted to downgrade back to.14:18
bialixfunkyweasel: I'd recommend 1.9 at least14:19
bialixbut it doesnot matter much14:20
funkyweaselI think this upgrade has failed.  Nothing is appearing in .bzr.log now, and it keeps spinning on 'checking repository format'.14:21
bialixvila: I've set commit message: ``bzr clean-tree`` should not delete nested bzrdirs. (bialix, #572098)14:21
bialixis it what you asking me?14:22
funkyweaselOh, but bzr is still consuming 100% cpu.  Which is nice.14:22
vilabialix: exactly14:23
vilafunkyweasel: weird, what was the last thing mentioned in .bzr.log ?14:25
a212901390231901I've not been setting commit messages 'cos I don't know if they get the (person) annotation added automatically or not14:25
a212901390231901or if I should be adding them manually14:25
vilaa212901390231901: they do14:25
a212901390231901but say, r5200 doesn't have any14:26
GaryvdMHmm - wonder why pqm does not set --author14:26
vilaa212901390231901: submitted by mail most probably, i.e. not using this field14:26
funkyweaselvila: 13231.056  opening working tree '{branch location}', but that's in .bzr.log.old now.  No mention of the operation in the branch on .bzr.log which is as of 1200BST14:27
vila>-/14:28
funkyweasel{branch location} is actual location of branch, not literal.14:28
vilafunkyweasel: standalone branch ?14:28
vilaoh, 1.3.1... geee, what were the progress reporting then...14:29
funkyweaselvila: Locally branched from a checkout from a repo running bzr 1.3.114:29
vilameh was14:29
funkyweasel2.0.2 locally.14:29
vilaand the repository is local or remote ?14:29
funkyweaselremote server.14:29
vilaouch14:29
GaryvdMfunkyweasel:  But arent' you upgradeing your local branch?14:30
vilawhat protocol are you using to reach the server ?14:30
funkyweaselGaryvdM:  Yes.14:30
funkyweaselvila: upgrading locally.14:30
funkyweaselto pack-0.9214:31
vilahmm, are you sure you're not upgrading both locally and remotely ?14:31
funkyweaselPretty sure, yes.14:31
funkyweaselI *think* I understand the problem.  bzr 2.0.2 is optimised for a different type of repo to 1.3.1 and performs inefficiently on the old version.  At least I hope that's what's happening.14:32
vilanah, even tht should produce some meaningful output in .bzr.log14:32
vilacan you do a 'bzr info -v' in this branch and paste the output14:33
GaryvdMvila: even while bzr upgrade is running?14:34
vilaGaryvdM: at worst we'll get a bzr locked error14:34
bialixvila: oh, it was my mistake to merge from bzr.dev before doing cherrypick :-(14:37
bialixbackporting to 2.114:38
vilabialix: told you, should have targeted 2.1 from the start :-O14:38
vilabialix: sorry to hear that :-/14:38
bialixDaggyFixes, yeah14:39
bialixbzr diff -rsubmit: <-- this produce the same patch as mp>?14:39
vilabialix: indeed, we still need a good solution for the NEWS entries though14:39
vilabialix: if your branch.conf is correct, yes14:39
bialixaha, NEWS needs manual editing anyway14:40
vilahmm, and will need editing again if you land in trunk, then in 2.1 and finally merge 2.1 in trunk14:41
vilaif you land 2.1 first, you're done14:41
vilawell, you have to wait for someone to merge 2.1 into trunk, but NEWS doesn't need to be edited in this case14:41
=== oubiwann_ is now known as oubiwann
vilafunkyweasel: what OS are you on and how did you upgrade to bzr-2.0.2 ? Could that be an extension not compiled related slowness ?14:46
funkyweasel~bin14:47
funkyweasel~paste14:47
funkyweaselTch.14:47
bialix!pastebin14:48
ubottuFor posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.14:48
funkyweaselStation.14:48
vilaStation ? Is that an OS ? Nobody never tell me nothing !14:49
funkyweaselSorry, watched Bill & Ted's Bogus Journey again lately.14:49
funkyweaselhttp://paste.ubuntu.com/427662/14:49
funkyweaselI'm on Ubuntu Karmic, the distro prior to the recently released LTS version.14:50
vilaok14:50
funkyweaselClean install.  using branches checked out from the repo server that's on bzr 1.3.1 results in branches which take an order of magnitude longer to complete basic tasks - diff, status.  Commit isn't noticeably worse, but trying upgrade operations takes longer than three hours.14:52
vilahmm, weird, I wonder if the update is really still proceeding or has already complete... 'Packs containing knits without subtree support' *is* pack-0.9214:52
GaryvdMvila: note that that pastebin shows new repo version. old repo version was...14:53
vilafunkyweasel: are the numbers of revisions (branch/repo) the ones you're expecting ?14:54
GaryvdMvila: old repo version was Knit repository format 114:54
vilaGaryvdM: yeah, so 'bzr info' finds the upgraded stuff apparently, which is why I'm wondering if the upgrade is already complete or not14:54
vilaI don't remember the upgrade to be that long for packs, I know why it takes longer for 2a but for packs...14:55
funkyweaselvila: Sounds about right number of versions.  the upgrade completed, but spent a lot of time 'checking the repository'14:56
vilafunkyweasel: without displaying a progress bar ?14:56
funkyweaselYup.  Little spinning chap and everything.14:57
funkyweaselI'm trying a bzr status on the branch.  Looks like it's still measured in minutes to complete.14:57
GaryvdMfunkyweasel:  That probably because you still have bzr upgrade running.14:58
funkyweaselGaryvdM: Not that I can see in the process list.14:59
funkyweaselI killed it after hour 3.15:00
GaryvdMfunkyweasel:  Oh15:00
vilaoh15:00
funkyweaselBut this is the problem.  Branches generated in 1.3.1 and checked out from a 1.3.1 server to local where I am using 2.0.2 seem to perform history-based operations *really* slowly.15:01
vilafunkyweasel: this 'bzr status' taking minutes, is it for the run after the upgrade or for any run ?15:01
funkyweaselAny run.15:01
GaryvdMfunkyweasel:  Try run bzr status again15:01
funkyweaselSame with diff.15:01
vilafunkyweasel: and what was it before the upgrade ?15:02
GaryvdMvila: pack-0.92 did have dirstate right15:02
funkyweaselQuickly now.15:03
vilaGaryvdM: wt6 yes15:03
funkyweaselDid it need to generate some cache.15:03
funkyweaselAha.  So let it upgrade, then kill when it's completed but still "checking the repo"?15:04
vilafunkyweasel: yes, it's .bzr/checkout/dirstate15:04
GaryvdMfunkyweasel: Yes, thats why I want you to run bzr status again :-)15:04
funkyweaselNow it is fast.15:04
funkyweaselThat is excellent.15:04
vilafunkyweasel: something happened that I can't explain, I'm tempted to suspect some weird stuff that may not be reproducible, so if it was me, I'll try to redo the upgrade in some scratch dir and see15:05
funkyweaselThis is most handy.15:05
funkyweaselNow I need to see if I can push this *slightly* upgraded branch to the repo server, bind to the repo server and all will be well.15:06
vilafunkyweasel: packs-0.92 was introduced in... 0.92 so a 1.3.1 server ought to handle it fine15:08
funkyweaselIt works.  And it is once again the swiftness.  Outstanding!15:10
funkyweaselCheers folks!15:12
bialixbzr miss15:16
bialixvila: I've got error for https://code.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/2466915:19
bialixLaunchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has no revisions.15:19
bialixwhat I'm doing wrong?15:19
bialixdoes lp:bzr/2.1 is wrong branch?15:20
GaryvdMbialix:  It's maybe a launchpad issue. Maybe try resubmit.15:27
bialixah, my branch is not scanned yet: https://code.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir15:29
bialixI'm not sure what I can do about this15:29
bialixit's stacked on lp:bzr15:30
bialixmaybe there is problem?15:30
GaryvdMbialix: I think just wait15:30
bialixI should manually stack on lp:bzr/2.1?15:30
GaryvdMI think thay are still creating lots of new branchs for ubuntu m15:31
GaryvdMbialix: I would like to talk to you about something.15:40
bialixsounds scary15:40
GaryvdMbialix:  qlog search is broken in lucid15:40
bialixindeed, scary15:40
bialixwhat is qlog search15:40
GaryvdMopen qlog. type in search box?15:41
GaryvdMbialix: It is due to a change in behaviour in fnmatch.translate15:42
bialixhmm?15:42
bialixpython?15:42
GaryvdMbefore fnmatch.translate('abc') = 'abc$'15:42
GaryvdMnow fnmatch.translate('abc') = 'abc\\Z(?ms)'15:43
bialixwow15:43
bialixwhat's it?15:43
GaryvdMbialix:  Should we implement our own function15:44
bialixthat's my first thoughts15:44
GaryvdM\Z = end of string15:44
bialix(?ms)15:44
=== radoe_ is now known as radoe
bialix?15:45
a212901390231901sets flags I think.15:45
GaryvdMI'm not sure why it's \\Z15:45
a212901390231901because it's not a r"" string.15:45
GaryvdMa212901390231901: Ah15:45
bialixreturn fnmatch.translate(wildcard).rstrip('$')15:45
bialixwe can delete just \\Z(?ms)15:46
a212901390231901yeah, re.M (multi-line), re.S (dot matches all)15:46
GaryvdMa212901390231901: Do you know what the (?ms) is for?15:46
a212901390231901they changed it so you can match newlines in the pattern I guess15:46
GaryvdMa212901390231901: Thanks15:47
bialixso, our search patterns are never multiline15:48
bialixwe can add workaround and remove either $ or \\Z(?ms)15:48
bialixif this does not sound very ugly for you15:48
GaryvdMor just \\Z15:48
a212901390231901or add ".*" to the end before translate15:48
bialixwriting our own parser/translator is not fun, I guess. but we can just copy-paste old code from py2.5 libs15:49
a212901390231901blah.*$ or blah.*\\Z will both work15:49
bialixnow I don't follow15:49
bialixwhy there is required .*15:49
GaryvdMa212901390231901:  fnmatch.translate('abc.*') == 'abc\\..*\\Z(?ms)'15:51
GaryvdM:-(15:51
a212901390231901okay, scratch that idea then.15:51
a212901390231901just star? it's turning a glob-looking thing into a re-pattern?15:52
GaryvdMah yes15:52
bialixjust asterisk15:53
a212901390231901bit confusing that it's using search() rather than match() so doesn't need a leading one15:54
GaryvdMa212901390231901: We only use fnmatch.translate, and then call .search ourselves.15:56
a212901390231901ah, well, if you use match instead, you'd need another star :)15:57
GaryvdMyes15:57
vilasorry was afk15:58
vilabialix: probably lp being a bit slow, just wait15:58
bialixokay16:04
GaryvdMIs there a way to get public_branch from .bzr/branch/branch.conf to override public_branch from ~/.bazaar/locations.conf16:17
GaryvdM?16:17
jelmerGaryvdM: not atm, lifeless was looking into that IIRC16:18
GaryvdMjelmer: Ok16:19
GaryvdMthanks16:19
GaryvdMWill just comment locations.conf for now16:19
bialixGaryvdM: so, what's the resolution for a problem with qlog?16:24
Peng_jam: ping?16:25
jammorning Peng_16:25
Peng_Oh hi. :D I didn't really expect you to respond. :P16:25
Peng_Wanted to ask about history_db.16:25
Peng_Does it handle ghosts and stuff as well as the old code did?16:26
Peng_I noticed KeyErrors in two branches, but one of them is most likely corrupt (old bzr-svn) and one of them is an old Arch import, so it's probably a bit funny too, though not corrupt.16:26
jamPeng_: I've tested it against bzr itself, which has ghosts.16:27
jamSo I won't guarantee I've handled all the edge cases, but I should have handled most16:27
jamif you have tracebacks, point them my way16:27
Peng_The tracebacks are recorded in my gigantic log file; the trick is digging them out. :P16:28
Peng_Here's one: http://paste.ubuntu.com/427731/16:29
jam /KeyError<enter>^b ^b ^b V kkkkkkkkk "+y :)16:29
GaryvdMbialix: I think I'm going to add on * to the end  of everything.16:30
jamah, the old code just set revno = None for ghosts16:30
jamthe new one probably gets a KeyError.16:30
jamShouldn't be hard to fix16:30
Peng_Oh oh, one of them is in bzr.dev too (one of your revisions, in fact :D ).16:30
Peng_This one's caused by annotate_ui, but it's the same line of history.py.16:31
GaryvdMHi jam16:31
bialixheya jam16:32
jammorning all16:32
=== salgado is now known as salgado-lunch
jamPeng_: yeah, I have 2 revs in bzr.dev that are ghosts16:32
jamit was before merge did fetch16:32
Peng_Heh, nice.16:35
Peng_jam: http://paste.ubuntu.com/427734/ too. KeyError in get_revno on Loggerhead's history.16:35
jamPeng_: care to try updating to rev 420?16:37
jamor you want the integration branch, just a sec16:38
jamk, rev 419 of integration, or 420 of history_db16:38
jamhmm.. seems to still be a problem16:39
jamchecking16:39
jamyeah, silly typo16:40
GaryvdMvila: would it be ok for me to set https://code.edge.launchpad.net/~spiv/bzr/repo-refresh-data-574236/+merge/24653 to Approved16:40
Peng_Ah? Tell me when you've fixed the typo.16:40
jamPeng_: 421 of history-d16:41
jampushing now16:41
Peng_Got it.16:41
vilaGaryvdM: I think it's even Merged16:42
vilaGaryvdM: but yes, it's ok16:42
vilaGaryvdM: lp is slow these days but it should do this (set to Merged)16:43
Peng_jam: Yup, all fixed. <316:44
GaryvdMVila: I check - it is merged, so I have set it as such :-)16:48
vilaGaryvdM: thnks16:48
Peng_jam: Oh, if you didn't see the email yet, I noticed another traceback too (History._rev_info AttributeError): https://code.edge.launchpad.net/~jameinel/loggerhead/history_db/+merge/24637/comments/6131516:50
Peng_jam: Not to rush you or anything. Just sayin'.16:53
jamPeng_: thanks for the heads up, always nice to have code poking at other code's private vars :)16:57
=== beuno is now known as beuno-lunch
=== IslandUsurper is now known as IslandUsurperAFK
bialix~~~17:10
cobalt_mikeGood morning... has anyone gotten bzrlib to work under Jython? I worked around the requirement for tty/termios but now it needs fcntl or ctypes...17:10
jelmercobalt_mike: afaik we don't use ctypes anywhere...17:10
cobalt_mikebzrlib/lock.py17:11
cobalt_mike... requires one of { fnctl, pywin32 or ctypes } for file locking, it seems17:11
a212901390231901you need my branch17:12
a212901390231901and it still doesn't work very well, partly java's fault, partly bazaar's17:13
Peng_cobalt_mike: People occasionally work on making bzrlib fail less on alternate Python implementations. Not sure if they ever fully succeed, though.17:13
a212901390231901https://code.launchpad.net/~gz/bzr/noncpython17:13
a212901390231901also read this: https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html17:14
cobalt_mikethanks, reading17:17
a212901390231901took me something like 5 months to get a one line fix in jython trunk, so I didn't see much chance of getting quick resolution to the various issues17:17
cobalt_mikealso, it is possible to build bzrlib such that it has no native os components? (eg., shared libraries)?17:17
cobalt_mikewondering if it might be easier to just shell out to the bzr cmdline, now =/17:19
a212901390231901for the moment, yes unfortunately.17:20
cobalt_mikeugh17:20
cbzis there anything that will pack and get rid of obsolete packs?17:21
a212901390231901noting on the jython list that you want to use bazaar with it might still be useful though, there have been several people in the past week interested17:22
a212901390231901and it might mean they'll actually look at it.17:22
jamcbz: in the 2.2 series there is "bzr pack --clean-obsolete-packs"17:23
a212901390231901(IronPython started worse off, but have been much more responsive to reported issues, despite not even taking patches)17:23
jambut you can also do "bzr pack && rm .bzr/repository/obsolote_packs/*"17:23
cobalt_mikea212901390231901: thanks for all the pointers, need to make some decisions now... sigh17:27
a212901390231901what bits of bzrlib do you need exactly?17:28
a212901390231901if you can skirt past bzrlib.chunk_writer and some other problem areas, I might be able to help17:29
cobalt_mikeright now, I need basic things: checkout, commit17:30
cobalt_mikedoing some examination of the working tree17:30
a212901390231901well, could try my branch and see how far you get17:32
a212901390231901I've got it merged up to trunk locally but haven't updated on lp as there's upstream mess17:33
cobalt_mikealright, I'll give it a shot17:33
a212901390231901I'm around so yell if you run into any problems17:34
cobalt_mikecool, will do17:34
cobalt_mikea212901390231901: well, compiled your branch and I've gotten farther than I did with the vanilla bzrlib.. I think I have a bug in my code now. Thanks!!17:54
=== salgado-lunch is now known as salgado
=== oubiwann is now known as oubiwann_
=== IslandUsurperAFK is now known as IslandUsurper
=== beuno-lunch is now known as beuno
cobalt_mikehas anyone used bzrlib with jepp instead of jython?18:34
=== oubiwann_ is now known as oubiwann
kfogeljam: ayt?19:43
jamkfogel: yeah, just saw your message20:05
kfogeljam: you mean my email?20:06
GaryvdMHi amanica20:10
jamkfogel: yeah, your email20:14
jamI responded20:14
kfogeljam: cool, that's what I was pinging about.  Thanks.20:16
amanicahi GarryvdM20:23
=== salgado is now known as salgado-afk
jamPeng_: the last traceback you sent me has been fixed, but requires updating both loggerhead and bzr-history-db.22:55
mkanatjam: Oh, so bzr-history-db is coming along now? :-)22:58
jammkanat: well, I've specifically integrated it into loggerhead, and I'm responding to fix requests22:59
mkanatjam: Ah, okay. :-)23:00
mkanatjam: As a loggerhead plugin?23:00
jammkanat: as changing the History class to use it for storage rather than the current sqlite backend23:00
mkanatjam: Ahh, okay.23:00
mkanatjam: Any reason you didn't use some sort of NoSQL DB instead of sqlite?23:04
dashmkanat: that sounds like extra work for no benefit :)23:04
mkanatdash: Well, I was mostly just thinking about the fact that the required WHERE conditions aren't that complex, and that it would get us distributed caching if we wanted it.23:05
mkanatdash: Which would be useful for scaling loggerhead across several machines simply.23:05
mkanatdash: Perhaps it would be simpler to make the loggerhead cache itself into a NoSQL DB or something, since it just has a get() and add() interface currently.23:06
Peng_jam: Alright, thanks for the fixes.23:07
Peng_jam: I can confirm it's fixed. :)23:12
jammkanat: well, sqlite3 is bundled with python 2.5+23:12
jamI don't know of any NoSQL that can make that claim23:13
Peng_........bdb? :D23:13
jamso the "no overhead to get loggerhead running on your trivial installation" checkbox is a lot easier to fill with sqlite23:13
Peng_Or, no, um, gdbm or whatever the heck it's called.23:13
jamPeng_: bsddb ? it is certainly NoSQL, but certainly not something I'd want to use :)23:14
Peng_I still think it's interesting that bzr-svn supports tdb now.23:14
Peng_Serializing complex things into a string key is almost as ugly as using SQL queries, though. :D23:14
jammkanat: Also, w/ sql it would be trivial to put it into postgres, or probably any other db back-end. Querier is meant to be the public bzr-history-db api23:14
jamthough I violate that in one place for expediency23:15
jamI'll probably fix that eventually23:15
Kilroo...Huh.23:16
Peng_Huh?23:16
KilrooSweet, I just confused myself.23:16
KilrooI think I had some sort of harebrained idea of combining bzr-svn, bzr-hg, hg's convert extension, and...um...possibly some really stupid hooks somewhere to make an alternative to hgsubversion that would get the advantages in communicating with svn that bzr-svn provides with its custom metadata dooflotchies23:18
KilrooThen I tried to figure out what the heck I was smoking and lost my train of thought four times in a row.23:19
Peng_Sorry, what'd you say? My brain shuts down when I hear multiple VCSes in the same sentence. ;-)23:20
KilrooHeh.23:21
KilrooYeah, it drives me crazy too, especially given how we're using svn at work.23:22
KilrooAt this point I think my best case scenario is convince them to switch from svn to hg.23:22
Kilroo...hg being chosen over bzr because the eclipse plugin may be critical in getting my boss to consider a change.23:23
lifelessPeng_: so bzr-svn shuts you down immediately ?23:47
lifelessPeng_: or do you have some actual tollerance :P23:47
Peng_Does what shut me down?23:48
Peng_:D23:48
lifelessmultiple vcs's in one sentence23:48
=== salgado is now known as salgado-afk

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