=== ronny is now known as Guest28036
=== jelmer_ is now known as Guest29580
=== ronny is now known as Guest27644
LaserJockare there any tricks to getting pulls going any faster?03:02
LaserJockI'm guessing not, but it just seems like it's awfully slow compared to other VCSs and I wonder if there are any tricks to it03:04
dobeyLaserJock: what version?03:05
LaserJockespecially when there's no new revisions it seems to take a long time considering03:05
LaserJockI've got 1.6.1 (intrepid default)03:05
LaserJockbut for instance I timed a multi-pull in a repo with 5 branches and it took over 1 minute03:06
LaserJockand there were no new revisions so it should have just been checking to see03:06
dobey1.9 was just released. i think it's a bit faster than 1.6. performance is one think people are working on03:06
dobeynot me though. i'm just a user for the most part03:07
LaserJockI was wondering if it was maybe a bzr-svn thing as most of my branches are from svn repos, but it seems like the native bzr ones are "slow" too03:09
AfCI never quite got it straight what the conclusion was on the list...03:13
dobeynot sure03:13
AfCis format=1.9 backwards compatible, or did it introduce rich-root (thereby putting a floor on03:14
AfCbackwards compatibility, of something 1.9 (or $whatever)?03:14
dobeyi'm not sure03:16
AfC[recognizing that bzr 1.9 client, bzr 1.9 server, and format=1.9 promises some fairly juicy improvements, it seems worth trying for, but in a public project I'm not sure if I'm going to screw people over, so it seemed prudent to ask]03:18
lifelessAfC: there is 1.9 and 1.9-rich-root03:30
AfClifeless: ah03:34
AfCSo we haven't culled rich-root yet. Ok.03:34
AfCCan a ~1.6 client read a 1.9 branch and downgrade?03:35
AfC(format=1.9 branch, that is; I know a bzr version 1.9 server will work)03:35
LarstiQlifeless: on the off hand it's a simple answer, what is keeping rich-root from becoming default?03:53
Peng_AfC: 1.9 repos are only compatible with 1.9.04:45
Peng_AfC: I mean, you can certainly downgrade them to pack-0.92 or knit or whatever, but you'd need to do it with 1.9 or newer.04:46
Peng_(Well, 1.9rc1 I guess)04:47
stampp-Howdy folks05:17
codeRatHi, I installed bzr 1.9rc1 on my windows XP machine. When I try to use tortoise I allways get the "ImportError: No module named command" error. The overlays icons shows right on the projects I already have set up. What does this error mean?08:30
jszakmeister|awacodeRat: it sounds like its using a module that's not installed in the Windows version of Python (the command module is Unix only)08:35
codeRatso there's no way around?08:36
codeRatok, thank you08:37
jszakmeister|awaI'm not sure how/when that module is used.08:37
codeRatat least I know what to look for :)08:37
jszakmeister|awaLooks like bzrlib/shellcomplete.py is the culprit08:38
codeRatbut it strange that a program that is made for windows does use a module for unix :S08:39
* jszakmeister|awa agrees08:39
=== jszakmeister|awa is now known as jszakmeister
=== Guest27644 is now known as ronny
=== jszakmeister is now known as jszakmeister|awa
alefterishello all. why when i commit with bzr ci -x a_folder, deleted files in the bzr root directory are not being removed?10:00
alefterisi meant in the bzr branch root directoy10:02
pygihi ho10:24
willwillhello, I want bzr branch to branch my repository then another one13:17
willwill(like apt-get dependencies)13:17
AfCWrite a shell script?13:19
willwillAfC, I think svn can do this13:19
willwillOK, I found this http://bazaar-vcs.org/NestedTreeSupport13:24
willwillstill not supported yet :(13:32
hnoArgh.. now bzr again downloaded over 10MB of data for a simple pull operation.. nearly all .tix index crap. Have -Dhpss logs if anyone is interested to look into this. bzr 1.8 on both sides, using bzr+ssh:// protocol.19:25
hnothis is a lightweight checkout from a local repository where the branch is bound to the remote repository.19:27
jelmerhi hno19:28
hnohi jelmer19:28
jelmerhopefully one of the Australians can have a look when they wake up19:28
hnoa pull within the local repository seems to do the same thing so it's not due to the lightweigth checkout.. will try it without the bind also.19:30
hnodoes the same without the bind as well..19:38
hnonext, upgrade to 1.9...19:38
berto-i have a branch of bzr's repo; how can i view the 1.9 release?19:41
berto-i tried bzr tags but got nothing on the command line.19:41
Peng_Yeah, there aren't tags.19:41
berto-how do i find out what rev v1.9 was cut from?19:42
Peng_The 1.9 release branch is http://bazaar-vcs.org/bzr/bzr.1.9/ . I'd assume it was cut from that.19:43
berto-since i already have a copy of the dev branch can i pull from there and my local copy will reflect that branch?19:44
berto-i'm about to try that.19:44
berto-it would be silly for me to have to rebranch the whole thing when i have the repo already.19:45
Peng_If you use a shared repo, it won't have to download the data again.19:46
berto-right, ok, cool.19:47
rockyjelmer: ready for a simple bzr-svn bug report? :)19:54
jelmerrocky, always :-)19:55
rockyjelmer: http://cluebin.appspot.com/pasted/300119:55
hno19 behaved better. Still not good, but much better.19:56
hno1.9 i meant..19:56
jelmerrocky, thanks, fixed20:02
Peng_hno: 1.9 introduces a new index format which should be much more efficient. Of course, it's not compatible with older versions of bzr.20:04
hnoPeng_: The local was already updated to btree, but the remote can not be updated as it's a shared repository.20:05
hnoPeng_: And I think it's silly. The basic bzr pull/update over bzr+shs SHOLD do a smart call getting a bundle back of the new revisions, not raw reading of the indexes and packs..20:08
Peng_Yeah, it /should/.20:10
hnoPeng_: Waiting for a test upgrade of the remote to see how much of a difference the new index format makes in this operation.20:15
hnobzr upgrade still running...20:26
rockyjelmer: there a branch i should get?20:27
jelmerrocky, yes, the 0.4 one20:28
rockyjelmer: hm, launchpad isn't seeing the fix ... http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes/1741?start_revid=174120:29
rockyhttp://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes rather20:29
jelmerrocky, launchpad isn't the main location for bzr-svn, it just has a mirror20:29
rockyjelmer: any reason the log isn't up to date when viewing http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ with a browser?20:30
rockybasically i'm trying to see the last revision so i can just do a manual fix here ;)20:30
jelmerI don't have the right plugin installed from my current machine20:31
jelmerso it's not updated atm20:31
rockyjelmer: how does your bzr/http setup work? you using the stock http smart server or something more ?20:35
jelmerno, I'm pushing to a remote server using bzr+ssh20:36
jelmerthe location I push to is accessible using http20:36
rockyi'm a little surprised that there doesn't seem to be any bzr repos out there with r/w using the http smart server20:36
lifelessrocky: there are20:38
lifelessrocky: the uk NHS's bzr repos are read-write http(s I think)20:39
hnolifeless: Hi!20:39
lifelesshno: hi20:39
rockyoh cool20:39
lifelessrocky: on windows with IIS for extra fun :P20:39
rockywhy don't more people use that? i mean r/w http: is way more accessible then proprietary bzr: repos ... is it that much slower or something?20:39
lifelessrocky: bzr+ssh is what most people use I think, because its basically zero setup20:40
lifelessbzr: is a registered port with the IANA, so its not that proprietary :P20:40
rockyi have 1 dedicated box, giving people shell access is not acceptable for my setup ... and i know a lot of people in the same boat... plus people coming from svn backgrounds are accustomed to only dealing with http20:40
lifelessrocky: sure, but you asked about other people :P20:41
lifelessbbiab, morning $foo20:41
hnohow long is an bzr upgrade supposed to take?20:43
rockyjelmer: it's too bad  easy_install bzr-svn doesn't install bzr-svn properly20:45
jelmerrocky: install should work though20:46
rockyjelmer: yeah "python setup.py install" works fine20:46
rockybut my steps for installing new bzr these days is:   virtualenv.py bzr-1.9; cd bzr-1.9; ./bin/easy_install bzr20:46
rockyit'd be nice if the last step was ./bin/easy_install bzr-svn20:46
lifelesshno: if its in the same model and local, a few minutes20:47
jelmerWhat would be required to support easy_install? I must admit I've never used it20:47
lifelesshno: what exact command did you run ?20:47
hnobzr upgrade --format=1.9-rich-root20:47
lifelesshno: cancel that20:47
lifelesshno: remove .bzr, rename backup.bzr to .bzr20:48
hnoit was on a copy..20:48
lifelessthen just cancel it20:48
hnodone, and restored.20:48
lifelesshno: is this the squid repo ?20:48
hnoyes, still having trobles with those indexes..20:48
lifelesshno: 'bzr upgrade --1.9'20:48
lifelesshno: and you need a 1.9 client to use a 1.9 repository20:49
rockyjelmer: well it's not really an issue of supporting easy_install, it's making sure bzr-svn is packaged properly to be an egg ... are there any other bzr plugins packaged as eggs?20:49
rockyi wouldn't think it'd be much work20:49
hnolifeless: 1.9 on both.20:50
lifelesshno: cool, was just answering your question from scrollback20:50
jelmerrocky, I'll happily apply patches that fix easy_install, as long as there's no overhead per release20:50
hnolifeless: 1.9 did behave better than 1.8, but still very heavy.20:50
rockyjelmer: should just be a one-time change20:51
hnolifeless: with the old index format that is. Upgrade of bzr brought the operation down from 8MB of indextransfer to ca 1MB I think.20:52
lifelesshno: sounds about right20:52
hnolifeless: followed by 75KB of actual pack data.20:54
hnolifeless: Corrected numbers. 1.8 read 9576413 of indicies 71598 bytes of packs. 1.9 read 3426251 bytes of indicies, same packs. (from the main squid3 repo with old index format)20:59
lifelesshno: the btree index will help immensely I think21:00
lifelesshno: 4K pages, 100-way fanout21:00
hnolifeless: Testing..21:03
hnolifeless: Using 1.9 format on the remote result in a transfer of indicies 448673 bytes, packs 70842 bytes.21:06
jelmerthe smart server should be smarter :-)21:08
lifelesshno: interesting21:21
hnopacks got a little smaller as upgrade also repacks the repository.21:32
hnobut still, that's at least 445k unwanted overhead..21:33
lifelesshno: we're agreed that it should stream21:35
lifelesshno: I'll need to check and see if we are doing prefetching on btree indices, because 445K of index data is 111 pages21:35
lifelesswhich is arge21:36
hnolifeless: I can tar up my local repository for you to experiment from, if you need a startingpoint to trigger this..21:38
lifelesshno: I have a separate performance issue I'm working on at the moment21:39
lifelesshno: but thanks21:39
hnolifeless: Ok. I'll keep a copy around for some time anyway.21:40
lifelessjelmer: bug 295611 - whats the summary?21:41
ubottuLaunchpad bug 295611 in bzr "NoSuchRevision: KnitPackRepository" [Undecided,Confirmed] https://launchpad.net/bugs/29561121:41
jelmerlifeless, basically it's similar to the bug we looked at during the summer21:42
* jelmer looks again21:43
jelmerlifeless, sorry, it's actually related to ghosts21:43
jelmerwhere "bzr diff" assumes that the revision info for the last-changed-revision of all files in the tree are present21:44
lifelessjelmer: I can't parse that. Is a valid rephrasing 'the last-changed-revision is used as the key for the file text'?21:49
jelmerlifeless, nope21:49
jelmerlifeless, bzr diff prints the timestamp of the original text of a file and of the new revised one21:50
lifelesswith you so far21:51
jelmerin order to obtain the timestamp for the old text, it uses the text revision and calls Repository.get_revision(text_revision)21:51
jelmerif that text_revision happens to be a ghost, things break21:51
lifelessso there are some interactions here21:51
lifelesswe really need to sit down and clean up the ghost handling once and for all21:52
lifelessthe interaction I'm thinking of is: we only copy text (id,X) when we copy revision X21:52
lifelessso that repository isn't clonable by bzr at all anyhow21:52
lifeless(as it currently stands)21:52
jelmerthat would break bzr-svn, which usually only pushes lhs revisions21:53
jelmerthat may contain references to texts introduced by rhs revisions21:53
jelmer*those lhs revisions may contain references to texts introduced by rhs revisions21:54
lifelessjelmer: 'does break'21:57
lifelessjelmer: though I think I've mentioned before that having those references isn't strictly valid21:58
lifelessunder the current rules. And thus the need to fix this forever21:58
lifelessthe inventory work being done at the moment will open the door to handling this efficiently and preserving arbitrary revision text values, which would make the revision-being-absent a valid bug21:59
jelmerlifeless, ah, that makes sense22:10
lifelessthe problem at the moment is that doing 'inventory_delta(X,Y)' is very expensive22:11
lifelessso we can't tell what texts are new for a set of inventories by doing that, instead what we do is a bit of hack by examining all the delta'd lines22:11
lifelessthe problem there is that fulltext inventories cause every line to be examined, so we end up either copying, or checking-for, the entire tree on every pull of 200 revs (on average)22:12
lifelessand that is very very bad on big trees; which are also likely to have more committers and thus trigger it more often22:12
ymlI have a quick question regarding bzr-svn and bzr 1.9. I am working to on Ubuntu and as of now I cannot install it because : bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~hardy1 is to be installed22:19
ymlI would like to know if this is going to be solve in a matter of day or if I should downgrade to bzr 1.822:20
lifelessyml: I imagine we just need to upload a new package to the ppa22:20
lifelessyml: if you are using the ppa22:20
ymllifeless: Yes I am using PPA22:21
ymllifeless: else is there a place where I could download bzr-svn  .deb ?22:22
jelmeryml, Debian should have one22:23
jelmerlifeless, what's the ETA on split-inventories?22:23
lifelessjelmer: draft results are promising22:25
lifelessjelmer: no specific timeline, you know how software dev goes22:25
jelmerlifeless: Ah, cool - how complete is it though?22:26
jelmerInitial work done? Some things already work ? Only a few tests left that need fixing?22:26
lifelesschk layer is about 95%, dictionary built on that is ~60% I would say, inventories on that are very thin, mainly need optimisers and tuning call it 70%22:26
lifelessneeds lots of profiling and feedback cycle22:27
lifelesscompression is not really touched, call that 10%22:27
jelmerah, so this is the CHK stuff I've seen scrolling past on bazaar-list.. :-)22:27
lifelesschk is content hash key22:28
lifelesswhich is the obvious implementation to satisfy a canonical representation with nested hashability22:29
ymljelmer : Is that the deb that I should download ?22:29
lifelessits slightly more general than git's keys, because its forward extensible (in disk layout) to sha256 etc22:30
jelmerlifeless, ah, nice22:30
lifelessCHKMap is a dict built in that layer22:31
lifelesswhich as a basic datatype is reusable22:31
ymlubuntu complains about libsvn1 being to hold ?22:46
jelmeryml, They probably have different versions of libsvn122:48
ymlok I will wait for a while22:49
fullermdlifeless: Speaking of inventory stuff...   does the new stuff you're working on support referencing unchanged files in a revision?23:21
lifelessfullermd: how do you mean?23:23
fullermdbzr ci --unchanged some/file23:23
lifelessfullermd: no23:25
fullermdI'm going to give you another chance to answer   :)23:25
lifelessfullermd: no23:25
lifelessfullermd: because..23:25
=== rocky1 is now known as rocky
jelmerfullermd, why would you ever want to do that?23:28
fullermdWell, why would you ever want to commit --unchanged?23:28
fullermdIf there's a reason for the one, there's a reason for the other.23:29
lifelessfullermd: the last-changed field on inventory entries is derived data; we don't provide (nor should we) a knob to fiddle it; its not included in testaments for instance23:30
pooliehello lifeless23:31
lifelessfullermd: annotating history so you can find a commit that marked 'foo' interesting is really quite orthogonal - I would approach it by adding a rule to the derived data logic that adds a last-change value for the commit, probably by recording in the commit that that path was interesting23:31
lifelessfullermd: and as such the inventory layer is unaffected - its no more or less capable of doing what you desire than current inventories23:31
lifelesshi poolie23:31
pooliei'm going to try running john's packaging script23:33
fullermdHm.  'k...   it seemed to me that last time we discussed it, you said it needed inventory-level changes, and so would end up falling into the next round of inv work.  Guess I misunderstood.23:35
lifelessfullermd: I think you asked about a variation ;P23:35
lifelessfullermd: or my thinking has refined23:35
fullermdWell, we could always use more refinery.  Or distillery, anyway.23:36
lifelessk, time for full screen code, poolie - ping me via skype(chat|voice) when ready23:37
poolielifeless: ok, the net here may be a bit slow to actually do voip23:38
pooliewe'll see23:38
fullermdDragonfly ended up with git, BTW.23:41
fullermd(not overly surprising; hg had a late surge, but git was up 2:1 most of the voting time)23:44

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