=== dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr
=== n2diy_ [n=darryl@wlk-barre-208-103-148-76.dynamic-dialup.coretel.net] has joined #bzr
keirsweeeeet, got my compact dictionary building code to work12:52
=== grimeboy [n=grimboy@85-211-243-152.dsl.pipex.com] has joined #bzr
=== abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr
=== phanatic_ [n=phanatic@dsl54028306.pool.t-online.hu] has joined #bzr
=== phanatic_ is now known as phanatic
=== pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr
=== jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
NfNitLoopHmm, when I do 'bzr pull <http-location>' bzr is complaining that paramiko isn't complained, and shows me an sftp url.02:29
NfNitLoop(a saved pull URL that I used long ago.)02:30
NfNitLoopShouldn't specifying a location argument to pull override that saved location?02:30
jelmerNfNitLoop: hi02:30
jelmerNfNitLoop: that bug that only appeared in 0.90 should be fixed now02:30
jelmerNfNitLoop: no, it will only override if you specify --remember02:30
NfNitLoopjelmer: not even for that run?02:31
NfNitLoopI don't want it to remember... I just want it to pull from a different location.02:31
jelmeryes, it should always use it for that run02:31
jelmerisn't the branch you're pulling to bound by any chance?02:31
NfNitLoopHmmm.  possibly.02:31
jelmerbound to that sftp url, that is02:31
=== NfNitLoop checks.
NfNitLoopI forget where bound info shows up, but I don't see the word "bound" in the results from "bzr info".02:32
NfNitLoopOh... it does say "checkout of branch sftp://"02:32
NfNitLoopthat would be bound, eh?02:32
NfNitLoopand you can only pull from a bound branch.   That should probably give you an error message then.  :)02:33
jelmerNfNitLoop: no, you can pull from the http branch02:33
NfNitLoop(er, rather, if you're working from a bound branch, you can only pull from that one.)02:33
jelmerbut it will update both the local branch and the branch it's bound to02:33
NfNitLoopjelmer: Aaaaaah.02:33
NfNitLoopso it wasn't failing on the pull... it was just failing on syncing back to the checkout.02:33
jelmerif the error message is confusing, that'd definitely be a bug02:34
NfNitLoopHmm.  It makes sense now.  I just hadn't worked with this branch in so long that I didn't realize I'd bound it over sftp.02:35
=== NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr
NfNitLoopjelmer: bzr: ERROR: Invalid revision-id {None} in SvnRepository02:41
NfNitLoopOh, DUH.02:41
NfNitLoopit would help if I put the new version in my plugins directory.02:41
Pengnir: Yeah, I've noticed the same thing on Linux. I guess it could use os.path.abspath('/tmp') or something?02:41
NfNitLoopjelmer: yay, worked!  :)02:44
nirPeng, maybe02:44
nirThe test also fail here with OSError - too many open files02:47
nirunless I use ulimit to allow more than 256 open files02:48
NfNitLoopjelmer: Though... I'm unable to push:  python: /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical(component, clen)' failed.02:48
PengMy ulimit is set to 1024 files, and that freaks out Opera sometimes. Dunno if I can change it, though.02:49
nirIs this the default?02:49
Pengnir: Well, I didn't change it.02:49
PengAnyway, I'm not on OS X.02:49
jelmerNfNitLoop: if you run with -Dtransport -Dcommit, what are the last few lines in ~/.bzr.log ?02:56
NfNitLoopsvn get-latest-revnum02:57
NfNitLoopsvn ls -r 0 ''''02:57
NfNitLoop(the first one is repeated 5 times)02:57
NfNitLoopneed more?  I could e-mail it.02:57
jelmerwhat url did it connect to ? I don't need the full URL but just the bits after the repository location02:59
jelmerincluding trailing characters02:59
NfNitLoopthere are not bits after the repository location... just the closing '03:00
=== troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net] has joined #bzr
jelmerNfNitLoop: is there a trailing slash after the repository location?03:03
jelmerNfNitLoop: what location do you specify when you try to push?03:04
NfNitLoopno trailing slash.   I'm pushing to 'svn+https://<repo>/trunk'03:04
NfNitLoop'bzr info' show that "push branch" and "parent branch" are identical.03:05
jelmerNfNitLoop: and the ls -r0 is the last line  before the crash?03:07
jelmerNfNitLoop: please update the plugin and try again, I think I've fixed it03:13
NfNitLoopjelmer: 'k. :)03:13
NfNitLoopI hope it's OK to just leave a bzr repo in ~/.bazaar/plugins/svn.   It makes it easy to stay up to date. :)03:14
NfNitLoopjelmer: Success!03:14
NfNitLoopThanks for all your help.  :)03:14
NfNitLoopNow, all of that was on my test repo.    Any suggestions on checking out my large one that keeps crashing?  :p03:15
jelmerNfNitLoop: is that still crashing?03:15
NfNitLoopI haven't tried it with these latest changes.03:15
NfNitLoopthink I'd have better luck?03:15
=== NfNitLoop goes off to start it.
jelmeryes, I think it should work now03:16
jelmerthe http support in bzr-svn has been a bit unstable because there's no testsuite for it03:16
NfNitLoopHmm, let me shut down X first to give it a bit more room to play in. :)03:16
jelmerin *theory* it should behave exactly the same way that the other transports do, but there are subtle differences03:16
=== fullermd can't believe somebody just said "no testsuite" on #bzr.
jelmerin theory, the abstraction in python-subversion should take care of it03:18
jelmerfullermd: I don't really feel like bootstrapping apache, webdav and subversion as part of the bzr-svn testsuite.. :-)03:19
NfNitLoopI also just learned that you can use checkout to create a wc in the repo directory.  (That just seemed... wrong, for some reason.)03:19
fullermdPfft.  As if that's an excuse.  You gotta be committed, man!03:21
fullermdThink of it this way; if you bootstrapped svn in the test suite, we wouldn't need to worry about trying to get a patched version installed on our systems; just run the test suite, and it installs it!03:22
NfNitLoopWhat was the issue with needing a patched version of svn, anyway?03:23
jelmerthe subverison python bindings are horribly broken in earlier versions of svn (< 1.5)03:24
fullermdDoes the trunk now have all of the fixes integrated?03:27
jelmerfullermd: yep, that's where I originally fixed python-subversion03:29
=== pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr
NfNitLoopHmm... about 20% done and my computer's still responsive.  :)03:34
NfNitLoopI should probably invest in more RAM for that machine anyway.  It's so old now I but whatever ram it uses is cheap. :p03:35
fullermdThe rate fabs are turning over, it's probably more expensive than the fastest new stuff  :p03:36
fullermdI've looked a couple of times at faster CPU's for this machine, but it would be cheaper to completely replace the motherboard, even including RAM.03:36
NfNitLoophehe, wow.03:37
NfNitLoopaha!   I can ctrl-c, then go do a "bzr pull" to continue, before the leaky python-svn library eats up my ram. :)03:38
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
NfNitLoopDoh.   bzr: ERROR: exceptions.AssertionError:03:53
NfNitLoop.bazaar/plugins/svn/fetch.py", line 306, in close_file assert checksum is None or checksum == actual_checksum03:53
NfNitLooptrying to resume.03:54
NfNitLoopHrmm, well, the resume hasn't failed yet.  Bad checksum it seems?  *shrug*03:59
jelmerNfNitLoop: hmm, strange04:15
NfNitLoopjelmer: seems to be working OK now.  :)04:18
NfNitLoopjelmer: if a branch is created in the subversion repository at a later point in time...04:54
NfNitLoophow would I go about checking out that branch in my bzr repo?04:55
NfNitLoopjust bzr branch svn+https://<repo>/branches/the-branch  in the shared repo directory?04:55
NfNitLoopwhat I'm wondering is if it would be smart enough not to re-fetch all of the history in that case. :)04:56
jelmerNfNitLoop: yep, just bzr branch will work05:03
jelmerit won't refetch history it already has05:03
keiranyone here familiar with the transport code?05:24
keiri'm designing a stand-alone compact dictionary format05:24
keirbut i'm going to reuse it within the graph itself05:25
keirso this serialization will be embedded05:25
keircan i make a 'view' on a file with a transport?05:25
=== BasicOSX [n=Basic@fortress.tanners.org] has joined #bzr
=== ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr
=== abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr
NamNguyenhi abentley, is there a plan to let BundleBuggy support more than one branch locations?07:34
NamNguyeni could imagine that detecting for which branch a merge request is will be a problem07:36
Odd_BlokeNamNguyen: Do you mean have a single BundleBuggy instance pick up merge requests for, for example, bzr and bzrtools from the same mailing list?07:39
NamNguyenthat is correct07:40
NamNguyenOdd_Bloke, and if you have looked at BB's code07:40
NamNguyenthere is a tool to automatically mark merge requests as "merged"07:40
NamNguyenit would need to support multiple branches too07:41
abentleyNamNguyen: No immediate plans.  Merge directives do include a target branch, so the only problem is that people don't send merge directives with useful target branches.07:42
abentleyBut for patches or plain bundles, there's no way to know.07:43
NamNguyenthe recommended practice is to make a local branch from bzr.dev, then branch from that local branch to make changes07:44
NamNguyenin that case, isn't the target branch pointing to the local bzr.dev?07:44
abentleyIf there is a public location for the target branch, the public branch is used in the merge directive.07:46
abentleyHave a look at any of my merge directives, and you'll see http://bazaar-vcs.org/bzr/bzr.dev as the target location, even though I used a local copy of bzr.dev07:48
=== luks [i=lukas@unaffiliated/luks] has joined #bzr
Odd_BlokeCan bzr nickname remote branches like git does with 'git remote add <name> <location>'?  For reference, you can then do 'git fetch <name>' which is equivalent to 'git fetch <location>' (or so is my understanding).09:15
=== ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr
=== ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
=== mwh [n=mwh@gustomal-adsl.demon.co.uk] has joined #bzr
=== pygi [n=mario@83-131-27-15.adsl.net.t-com.hr] has joined #bzr
=== pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr
=== hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr
=== gakster [i=96656340@gateway/web/cgi-irc/ircatwork.com/x-11ba859992bd94a0] has joined #bzr
=== gakster [i=96656340@gateway/web/cgi-irc/ircatwork.com/x-61e1b70bc13d598b] has joined #bzr
gaksterhi all,   i have tried to learn the difference between DARCS distributed method and Subversions centralised.... but is there anyone who might like to try to explain it to me again. I am still confused12:05
gaksterall I understand is that with the distributed method, every copy of the files is a repository of an equal level, and patches are shared amongst users12:06
gaksterwith subversions centralised method.... there is one MAIN repository,  and everyone works throug that12:06
gaksteris there more to it than that?12:06
Penggakster: With the centralized model, there's one repository, and only certain authorized people can commit to it. In the distributed model, everybody has his own repository and can commit to it and put it on a server for other people.12:17
Penggakster: One benefit of the distributed model is that since the VCS has to merge changes between different peoples' branches frequently, it has to be damn good at it.12:18
Penggakster: That's purely the technically differences. Socially, the distributed model is way better (IMO and with one or two exceptions, of course).12:21
pygidistributed model also allows you to merge patches from people, and credit it to them. Where in svn if someone who doesn't have commit access and sends you a patch, you commit it, and therefore it looks like you did it12:27
gaksterin what social situations is centralised better than distributed?12:31
gaksterwhat if i want to use version control to just keep track of changes to my website..... I dont need multiple copies of my website... i just need one repository12:32
=== mwh [n=mwh@] has joined #bzr
=== duckx [n=Duck@tox.dyndns.org] has joined #bzr
pygigakster, distributed is much easier as in most cases you don't need a special server12:37
pygibzr, git, mercurial ... distributed, without server12:37
pygisvn, cvs, perforce ... centralized, need server12:38
gaksterI like the idea of not needing to install a server..... this is a positive of distrubted12:42
gaksterdoes anyone know why the http://darcs.net/ webpage has been crashed for a few days now?12:43
pygifor bzr however there is smart server if you wish, that allows improvements in performance12:43
pyginot really, this is bzr channel =)12:43
gakstersorry, dont know who else to ask :-)12:44
gaksteri congratulate bazaar for having a webpage that doent look ugly.... it is important for people like me who are more graphical windows users... well done!12:49
gaksteralso great that you have some NON technical documentation12:49
gaksterdoes anyone have a suggestion as to the best windows GUI.     I am looking for simplicity and ease of use. And nice pretty colours for diff reports12:51
=== dato [n=adeodato@tarrio.org] has joined #bzr
pygigakster, Olive? :)12:56
pygiwell, there's this bzr-gtk that should work, and it includes Olive12:56
pygiand all the other cool things12:57
=== sadleder [n=sadleder@p50810F06.dip0.t-ipconnect.de] has joined #bzr
=== sadleder [n=sadleder@p50810F06.dip0.t-ipconnect.de] has left #bzr []
gaksterwhat about http://bazaar-vcs.org/TortoiseBzr   how is this different from bzr-gtk01:07
pygiit's something like tortoisesvn01:08
pygiI'm not aware of it's staus01:09
gaksterI have downloaded and installed the standalone windows install of bazaar.....    for me to be able to use olive and other br-gtk....  it says i need to have a python based install, and need a bunch of other dependencies? is this right?01:22
gakstersounds too hard for me01:23
=== asabil [n=asabil@ti0035a340-0802.bb.online.no] has joined #bzr
=== AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr
=== nir [n=nir@moinmoin/fan/nir] has joined #bzr
=== grimboy_uk [n=grimboy@] has joined #bzr
=== grimeboy [n=grimboy@] has joined #bzr
=== MaSch [n=masch@p5091900E.dip0.t-ipconnect.de] has joined #bzr
MaSchmaybe its a stuid question, but i never worked with svn-systems befor so, how i use this? So if i have a server, where all the files are stored and where bzr runs, how i edit them and upload them back to the server?02:17
MaSchand sorry for my bad english02:17
MaSchso with bzr branch <url> i get the files to my local machine, but how i upload them to the server?02:21
jelmerbzr commit02:23
jelmerfollowed by 'bzr push'02:23
jelmer'bzr commit' records the changes02:23
jelmer'bzr push' uploads the changes02:23
MaSchokay thanks02:23
MaSchits that easy.. nice..02:23
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
=== phanatic [n=phanatic@dsl54028306.pool.t-online.hu] has joined #bzr
dirkerHello :) How good is bazaar suited to host a project with source aswell as binary files? I'm minly thinking of merges and compression of the history.02:52
=== g0ph3r [n=g0ph3r@p57A097F4.dip0.t-ipconnect.de] has joined #bzr
=== mwh [n=mwh@] has joined #bzr
=== mdke [i=mdke@ubuntu/member/mdke] has joined #bzr
mdkeI'd like to try and create a patch which spans several revisions I've made to a branch, but not others; is that possible?03:10
pygimdke, cherrypicking?03:26
=== mwh [n=mwh@] has joined #bzr
=== Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr
pygimdke, if that's what you think, then yes, you can do it03:31
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
=== dpm [n=dpm@p54A130EE.dip0.t-ipconnect.de] has joined #bzr
=== AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr
=== fog [n=fog@debian/developer/fog] has joined #bzr
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
=== Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr
mdkepygi: how?04:16
=== pygi thinks
pygicherrypicking needs to be improved in bzr, but :04:18
pygibzr merge -r 81..82 ../bzr.dev04:18
pygiperhaps this should do the trick?04:18
pygijust an example04:19
mdkepygi: I need to create a patch though...04:19
pygimdke, well, do cherrypicking, and the do a diff against the original tree?04:20
mdkeah, interesting.04:21
mdkethanks, I'll look into that04:21
pygimdke, yw04:21
phanaticmdke: maybe bzr diff -r X..Y ?04:25
=== mwh [n=mwh@] has joined #bzr
Odd_Blokephanatic: That'll diff between the two revisions.04:31
mdkephanatic: I'm going to try pygi's because it will help me get a patch that I can apply cleanly against the original branch (I've made quite a lot of other changes to the branch which I don't want to include in the patch)04:33
phanaticmdke: sorry, i misunderstood you a bit :(04:34
=== tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr
=== fog [n=fog@debian/developer/fog] has left #bzr []
=== pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr
=== abadger1999 [n=abadger1@] has joined #bzr
=== rents [n=db@84-50-162-133-dsl.rgu.estpak.ee] has joined #bzr
rentshi, do i have to recompile everything after doing "bzr up"?05:25
pygiwhat do you want to recompile?05:25
rentsif i am updating something05:25
Odd_Blokerents: You always have to recompile a project if the source code changes.05:26
Odd_Blokerents: Assuming it's a project which requires compiling.05:26
Odd_BlokeWhether this is through you editing a file or 'bzr update' modifying a file is immaterial.05:26
rentsthen i should now figure out if this project really needs recompiling05:27
rentsexaile in this case05:27
pygirents, it doesn't05:27
pygiexaile is written in python05:28
rentsand won't need it?05:28
rents<- total newb05:28
Odd_Blokerents: Python doesn't require compilation, it's an interpreted language.05:28
pygiwhy dont you ask adam?05:28
rentsok, that's all i wanted to know05:29
rentsthank you guys05:29
rentsbye for now05:29
=== GaryvdM [n=chatzill@mtngprs4.mtn.co.za] has joined #bzr
=== Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr
=== ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr
=== pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr
=== arjenAU_ [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr
ubotuNew bug: #138437 in bzr "Cannot revert single files via olive" [Undecided,New]  https://launchpad.net/bugs/13843706:25
mdkepygi: I'm trying your method, the first revision worked well, but now I'm trying to apply another revision and it won't let me without committing the changes06:30
mdkepygi: is there any way around that?06:30
datono, but you can commit in a throwaway patch, which you can remove after generating the diff.06:32
luksyou can use --force06:32
mdkeI'll try; I can't commit anyway because I did a checkout06:32
luksbut it's probably better to have it as multiple commits and then generate diff over the range of new commits06:32
mdkewow, --force has done the trick06:33
mdkeand the revisions have applied cleanly \o/06:33
pygimdke, see? :)06:34
mdkethat's pretty awesome06:34
mdkeshame the code doesn't work06:35
pygimdke, well, I'm off to dinner, but if you need anything poke06:37
mdkepygi: thanks, I think I've got there, just have to fix the code06:37
pygimdke, kk, congrats ;)06:38
ubotuNew bug: #138439 in bzr "Cannot select multiple files and execute a command in olive" [Undecided,New]  https://launchpad.net/bugs/13843906:40
phanaticolive bugs filed under bzr, nice06:41
=== mdke [i=mdke@ubuntu/member/mdke] has left #bzr ["goodbye!"]
ubotuNew bug: #138446 in bzr "Cannot import from svn" [Undecided,New]  https://launchpad.net/bugs/13844607:11
luks... and bzr-svn bugs files under bzr :)07:18
=== Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr
pygiphanatic, fix it =)07:24
MaSchwhats olive?07:26
Odd_BlokeMaSch: A GTK frontend for bzr, I think.07:26
MaSchokay thanks07:26
pygiOdd_Bloke, you're right07:26
=== asak [n=alexis@201-1-47-31.dsl.telesp.net.br] has joined #bzr
=== fog [n=fog@debian/developer/fog] has joined #bzr
=== pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr
=== ACSpike[Home] [n=ACSpike@] has joined #bzr
ACSpike[Home] hello07:41
pygihi ho07:41
Odd_BlokeIf I'm branching into a shared repository (from a remote branch) is there any way to resume after interruption?08:14
datothe fetched revisions will be present in the repository, so remove the branch and rebranch08:15
=== Mez [n=Mez@ubuntu/member/mez] has joined #bzr
=== matkor [n=matkor@ip83-230-19-175.e-zabrze.pl] has joined #bzr
=== grimboy_uk [n=grimboy@] has joined #bzr
=== tca [n=tom@ti541110a080-5238.bb.online.no] has joined #bzr
lifelessjelmer: ping09:32
lifelessdato: ping09:32
datolifeless: pong09:32
lifelessbzr packages for gutsy are going to be updated real soon now09:32
jelmerlifeless: pong09:33
lifelesswhere you planning on a bzr-svn 0.4.2 upload to sid today ?09:33
=== GaryvdM_ [n=chatzill@mtngprs4.mtn.co.za] has joined #bzr
jelmerlifeless: the debian branch is up to date09:34
lifelessjelmer: package not branch.09:34
lifelessI use the terms advisedly because of the various processess involved09:34
=== GaryvdM_ is now known as GaryvdM
jelmerlifeless: ah, right09:34
lifelessnow, I can upload bzr-svn to debian if you are happy with the packaging.09:35
lifelessthats kinda trivial :)09:35
jelmerlifeless: yup, please do09:35
datolifeless: ok. you needed something or were just telling?09:37
lifelessdato: if you were doing a bzr-svn upload I would not do one09:38
lifelessdato: I was coordinating09:38
datoah, good. just fyi it'll prevent bzr 0.90 from getting to testing, but I don't think that's happening anytime soon either because of a failed mipsel build.09:39
lifelessdato: I'm not worried about testing right now :) - why will it prevent it though ?09:40
datoprevent in less that 10 days, I meant09:40
lifelessjelmer: http://bzr.debian.org/pkg-bazaar/bzr-gtk/unstable ? seems out of date09:40
lifelessoh crap09:40
lifelessbzr-svn doh09:40
=== GaryvdM_ [n=chatzill@mtngprs5.mtn.co.za] has joined #bzr
=== GaryvdM_ is now known as GaryvdM
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
keirlifeless, ping!09:48
keiri wrote the dictionary builder09:50
keirand am 1/3 way through the reader09:50
keirit's compressed btree09:50
keirlifeless, do you have couple mins to chat about it?09:52
keiri branched from bzr.dev instead of packs.knits09:53
keirbut the code is contained in two files, so it should be easy to switch09:53
GaryvdMjelmer: I've been hacking away at viz. I've finish a proof of concept that loads the revisions incrementaly.09:54
GaryvdMIt's published here: http://bazaar.launchpad.net/~garyvdm/bzr-gtk/vizchanges09:54
keirlifeless, so what i have is just like i described in the 2nd email regarding a separate dictionary09:55
keirexcept that if the 'index' block is larger than the block size, it recurses09:55
GaryvdMThere are still some bugs in the code to work out where the lines need to be - Some of the lines are drawn on top of each other.09:55
lifelessI think that makes it a b+ tree :)09:56
keirlifeless, oh. heh09:56
keirhmm, i'm lacking a webserver09:57
lifelessyou probably want to merge it with packs and do some adhoc testing yourself09:57
lifeless(keeping your branch separate and unmerged is fine; I just mean have a copy that is integrated)09:58
siretarthi lifeless09:58
siretartlifeless: do you plan to update bzr in gutsy?09:58
keirlifeless, ok09:58
lifelesssiretart: see above09:58
siretartoh, sry09:59
lifelesssiretart: the answer is yes, but someone needs to do the uvfe dance for about 6 packages09:59
lifelessbzr bzr-gtk bzrtools bzr-svn bzr-rebase bzr-builddeb all need updates IIRC09:59
siretartlifeless: in past releases, there were no uvfe reports for bzr packages09:59
lifelessin the past we were not updatng 3 days before beta10:00
siretartah, ok10:00
keirlifeless, pushing my branch now. it's still based off bzr.dev until i have at least the dictionary functionally complete10:02
keirwe gotta fix that progress bar10:03
keirit's so totally useless10:03
fullermdIf we just got all operations completing in under 5 seconds, we wouldn't need a progress bar.10:03
keirworking on it!10:03
lifelessfullermd: the internets are slow10:04
lifelessfullermd: pushing 2G of data >>>> 5 seconds10:04
fullermdWell, can't we just rewrite the slow parts in C?10:04
keirfullermd, the problem is the data formats (i think?)10:04
keirpush is going on 4 minutes now10:04
lifelesskeir: fullermd is our resident troll-resistance-tester10:04
lifelesskeir: initial push is slow for knits because of round trip latency on each knit10:05
lifelesskeir: if you are using sftp, its either 3 or 4 round trips per file, and 2 files per knit.10:05
=== Mez [n=Mez@ubuntu/member/mez] has joined #bzr
lifelesspacks are only 20% slower than rsync10:05
keirdoes sftp do its own compression?10:05
keirregardless of whether we speed things up, i still want nice progress bars10:07
jelmerGaryvdM: cool10:08
jelmerGaryvdM: I'll try it out this week!10:08
keiraaaag only 2 modified files and push is still going10:09
keir8 minutes now10:09
keirlifeless, i'm thinking of building a 1st version that does away with the separate storage for the graph10:10
keirand just packs the keys (as dumb strings even!) into the dictionary10:10
keirsince it should be very easy to code, i figure it's a worthwhile experiment10:10
keiris there a benchmark suite waiting for me to try out?10:10
lifelessthat sounds very close to the toy index, just with a B+ tree rather than bisectable array.  :)10:11
lifelesssome of the benchmarks may help, but really for this size data - no.10:11
keirlifeless, sftp://mierle@bazaar.launchpad.net/~mierle/bzr/compactgraph; not done the push yet. i'll be back in 1/2 hr10:11
lifelessto test it out I'd suggest converting bzrlib to packs using it10:11
lifelessand then trying things like :10:12
lifelessbzr cat10:12
lifelessbzr log FILENAME10:12
lifelessbzr merge10:12
keiri tried the dogfooding instructions, and it didn't work when i tried to branch the pack version10:13
keirwhich is why i branched bzr.dev10:13
keirbrb in 1510:14
lifelesswe have a corrupt data item, which is noted in the followup mails about dogfooding10:14
lifelessjelmer: where is the bzr-svn tarball ?10:30
=== pygi [n=mario@83-131-30-103.adsl.net.t-com.hr] has joined #bzr
lifelessalso, consider signing the targz please10:32
lifelessI can quite easily construct a tar.gz which when piped through gunzip -c | gpg verifies10:34
lifelessbut when tar xzf'd does something different10:34
lifelessjelmer: ^10:35
jelmerI'd rather be consistent with the way I have to do other releases, but I'll consider it for 0.4.310:35
=== pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr
lifelessjelmer: what other releases require this?10:35
lifelessoh, your debian branch has the packaging mixed with the code?10:36
jelmerlifeless: it's the convention for samba projects10:37
lifelesswell, try creating a tar that overrides /boot/grub/menu.lst10:38
jelmerlifeless: yep, makes it easier to diverge a bit from the main branch without having to use quilt or anything10:38
lifelessand then cat that tar before your release tar as two gzip streams10:38
=== pygi [n=mario@83-131-30-103.adsl.net.t-com.hr] has left #bzr ["Leaving"]
jelmerwell, I do suggest running gpg on the actual unpacked tarball rather than piping through gunzip but I see your point.10:42
lifelessI encourage you to change the samba release process10:42
lifelesscreate two tarballs10:42
lifelesssha1sum *tar.* > listing10:42
lifelessgpg --clearsign listing10:43
lifelessor something like that10:43
lifelessshould be no harder10:43
lifelesssame number of gpg sigs10:43
=== pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr
lifelesseasier for users to validate the content (don't need to unbzip2 or whatever)10:43
jelmerwell, it does add an extra step running sha1sum for the user and comparing that to the sha1sum in the listing10:47
jelmerThe actual number of users downloading the signature is a bit disappointing10:48
=== grimeboy [n=grimboy@85-211-247-60.dsl.pipex.com] has joined #bzr
fullermdJust slip a trojan into a release.  That'll encourage them.10:49
keirlifeless, did manage to get that branch?10:50
=== cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr
NfNitLoop*sigh*  getting PyCrypto onto Windows w/ python 2.5 is turning out to be non-trivial.10:51
lifelesskeir: haven't tried yet10:52
lifelesskeir: I am focused on commit performance right now, I'll happily look at your branch when you're a bit further along, or if you would like specific feedback10:52
lifelessjelmer: +1 step -1 step +security :)10:53
keirlifeless, ok, cool. just looking for overall thoughts on my design before i get any further10:53
keiri'd rather fix design issues early10:54
keirsee compact_graph.py10:54
lifelesskeir: I think you have those via the list :)10:54
lifelessbut sure, I'll do a pull later today10:54
keirmaybe it is better to wait until i have it running10:55
keirok, nevermind then, i'll make it go then mail it to the list.10:55
lifelesshmm, I will pull and peek :)11:02
lifelessbut mailing the list is always good :)11:03
=== tca [n=tom@ti541110a080-5238.bb.online.no] has left #bzr []
=== ACSpike[Home] [n=ACSpike@] has left #bzr []
lifelessdamn missed abentley11:13
keirlifeless, so for initial commit, are you speeding up the pack-based commit?11:17
lifelessI can commit a 550MB tree with 55K files in 1m48 user time11:17
lifelessbzr.dev is about 10 minutes IIRC11:18
keirhow long is git and hg?11:18
lifelesshg is 1m user time11:18
lifeless1m30 wall clock, my test code is 2m2 wall clock11:19
lifelessgit I'm not sure right now11:19
keirthat's pretty decent11:19
keirdo you think we can beat hg?11:19
lifelessI'm sure we can make the speed difference unimportant11:19
lifelesswe don't claim to be the fastest system, only the nicest.11:20
lifeless'only' :)11:21
keiri imagine we can get most ops to within 20% of hg and git11:24
lifelessI'm aiming to be no slower than twice targz11:24
lifelessfor initial commit11:24
lifelesswhich is incidentally faster than hg IIRC11:24
keirwhat approach are you taking to making the initial case so fast?11:25
keirare you special casing it?11:25
lifelessnot as such no11:26
keirthat's good11:26
keiris the 1:48 figure with some pyrex?11:27
keirwow, nice11:27
lifelessno pyrex, commit -q11:27
keirwould there be any benefit to combining add * and commit?11:27
lifelessthough add is very fast11:27
keiri still want a single command 'GO' which adds all non-hidden files and commits11:27
keirinit + add + commit11:28
lifelessyou can do that trivially in a plugin11:28
keiri know :) and i will, just not today11:28
keiri'd like it to be upstream, rather than a plugin11:28
keirso you can show peoplle how easy bzr is11:28
keirright now it's as easy as 1) init 2) add 3) commit11:28
lifelessthats an extremely special cased situation11:29
keirbut with go, it's as easy as 1) go :)11:29
lifelesscommit -A is something I think is agreed on11:29
lifelesswhich is add/remove automatically during commit11:29
keirperhaps init -A?11:29
lifelessit would have to live on init I think if we were to do such a special case11:30
lifelessbtw, I dunno if you know but you can import tarballs directly11:30
keirwoah, i didn't know that11:30
lifelessits in bzrtools11:30
lifelessbut I have been thinking its such a nice thing we could move it in11:31
keir+1 on that11:31
keirwhen i look at my use of bzr, it's always 'bzr init; bzr add .; bzr ci -m"Initial commit"'11:31
keirso i don't see the point in not having that as a single command11:32
lifelessyou must start lots of projects :)11:32
keiri version little stuff, because it's so easy with bzr11:32
keirwith svn it's annoying11:32
keirok, i'm out on the bus11:33
datoI agree to that11:33
keirwe'll see if i can get dict reading working by the time i get back from TO11:33
datocreating lots of independent branches for not-so-big stuff11:33
=== hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr
=== mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr

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