=== Spaz is now known as Kittens === kiko-afk is now known as kiko-zzz [00:33] morning all [02:06] heh, oldest bzr bug: https://bugs.edge.launchpad.net/bzr/+bug/3708 [02:06] Launchpad bug 3708 in bzr "progress indicators are often buggy" [Wishlist,Confirmed] [02:06] (open bzr bug) [03:05] Peng_: are you around? [03:16] james_w, woo, i wouldn't say it's fixed now but it should be when the new system is used by all transports i [03:16] imo [03:19] heh, compressbench was compressing 22K copies of the same text. Oooops. [03:27] bet that compressed fairly well [03:34] mwhudson: knits got it down to 141MB [03:34] mwhudson: which is an epic fail if you ask me [03:34] mwhudson: gc got it to 500K [03:39] I was wondering how it managed to work on my laptop when I only had 1.5GB free and the corpus is 3.4GB [03:39] Is there any way to exclude directories from a checkout? I am trying to import a svn repo into bzr which has a directory of huge binaries. [03:39] 'slowly' [03:40] bob2: btw I'm here [03:40] alevine: not really; you could filter a fastexport stream to remove them, or something like that I guess; are you using bzr-svn? [03:42] lifeless, yeah I am. Tried a branch with --stacked but it said that was experimental and I couldnt branch after that [03:42] And when I try to download the whole repo the connection inevitably fails [03:48] alevine: try branch -r 1 svn://foo bar; cd bar; bzr pull -r 2; bzr pull -r 3 etc [03:48] (use bigger gaps if you like) [03:49] hehe, oy [03:49] suppose that will probably work [03:49] thanks [03:52] hi arjenAU [03:53] lifeless: hey. in Tas @ LCA [04:12] <`mousey> I've been reading the bzr documentation and noticed this "Bazaar has out of the box integration with Bugzilla, Trac and Launchpad's bug tracker." [04:13] <`mousey> how can I integrate my bzr repo with my bugzilla system? [04:23] <`mousey> ohhh i found it after some digging around on the offline hel [04:47] arjenAU: me too [05:26] <`mousey> does anyone know if it's possible to load up an external diff tool when diffing revisions in tortoisebzr? [05:26] `mousey: I'm not sure sorry [05:26] markh: ^ [05:30] lifeless: yea found out... duh [05:36] arjenAU: :) [05:37] hi lifeless [05:38] so does that mean all the compressbench numbers are wrong? [05:38] yes [05:38] :( [05:38] I have no sense of the vector yet [05:38] clearing enough disk space to find out [05:54] lifeless, so once I get this huge svn repository downloaded, will I be able to quickly branch a subdirectory of this new bzr repo (assuming those huge binaries are not ancestors of anything I am branching) [05:59] alevine: maybe; it depends on exactly how you are converting; you should read the bzr-svn docs some more I think. svn and bzr are verry differnet in what they consider a branch [06:01] lifeless, I guess what I'm asking is this: if I have a regular bzr repo that I branch that has folders a and b. a has txt files and b has 800MB files [06:01] if i then branch repo/a will that copy over all the 800MB files? [06:11] alevine: the terms 'branch' and 'repo' are not interchangable; but you used them as such above. [06:11] alevine: a branch is a branch, you can't 'branch' a subdir of a branch, unless that subdir is itself a seperate branch [06:18] lifeless, so you're saying that you can't make a subdirectory of a branch into a branch? [06:26] i think you inferred that but I dont want to assume [06:45] hi igc [06:49] jelmer: don't suppose you're around? [06:57] hi all [06:57] poolie: I rarely saw jelmer here so early :) [07:00] yeah, but you know students and sleep cycles [07:00] how are you, vila? [07:00] hehe, students [07:00] fine [07:03] hi poolie [07:03] hi vila [07:06] Hey Ian [07:07] vila, igc, do you want to catch up before i go? (i'm leaving tomorrow morning) [07:08] poolie: sure [08:54] * igc dinner [09:18] guilhembi: ping [09:19] vila: pong [09:32] I've got a local repo bound to a remote one so when I commit locally the changes are automatically pushed up. That's great and I'd like to keep that but I'd also like to trigger a remote update at the same time... Is that something I can do? [09:32] branch, not repo? [09:32] sorry yes [09:34] so a cross between binding and the push-and-update pluging, I guess [09:40] hi folk, i've a question about merging; Lets say theres three people A, B and C which all have their own branch of the same project. What if A makes a change, which B merges directly from A and person C merges from both A and B (which both seems to have modified branches, not knowing it's the same commit). Now when person A finally merges some changes from person C, the bzr log of person A will look very ugly, something like circular merge commits. Ho === kiko-zzz is now known as kiko === bac` is now known as bac === abentley1 is now known as abentley === bac is now known as bac_snow_whee === bac_snow_whee is now known as bac [12:27] I see alot of people joined lately. I'll paste my question again: [12:27] hi folk, i've a question about merging; Lets say theres three people A, B and C which all have their own branch of the same project. What if A makes a change, which B merges directly from A and person C merges from both A and B (which both seems to have modified branches, not knowing it's the same commit). Now when person A finally merges some changes from person C, the bzr log of person A will look very ugly, something like circular merge commits. Ho [12:29] speakman: even though your message seems to have been truncated, you will probably need to come up with a test-case which demonstrates exactly how person a's log is ugly and explaining how you thing it should look instead. That doesn't sound trivial, so it might be better suited on the mailing list... [12:32] markh: Thanks for your comments. I think I'm too new to distributed versioning to really have an idea how it should look like. But in one of my current project, and web developing project, there will be like three or four parallell developers which I will randomly merge from to get their eventually changes. [12:33] speakman: it won't end up circular [12:33] And if I'm person A and person B just merged from me (and commited it to his branch) it will, when I merge from him next time, look like he had done some real changes. [12:33] speakman: is this a real problem you are seeing, or a theoretical problem you are concerned you might see? [12:34] speakman: yes, there will be an extra revision which is B's merge from you [12:34] markh: we havn't started really yet, but I did some test with three different branches on my local machine and it ended up like this. [12:35] Actually; we're trying to find a suitable workflow for improving the phpBB3 code base for our own purpose (we're running a public forum which will customize the forum code to our needs) [12:35] If anyone have a better idea how to manage the development, I'm really listening :) [12:37] speakman: as james_w says, the log will show the merge - is that your concern? [12:37] (i'm also thinking of another option where there will be a PQM which handles merge of patches/bundles through a mailinglist/mail account. But I've never setup an PQM and I'm not 100% sure of how it's working) [12:38] if not, you will need to be more specific... [12:38] markh: person A's log will show persons B's merge of person A, and the log from merge from person C will show his merge from both person A and person B. Alot of spam in the log, but no code change. [12:38] I'll make a test right away, please hold on. [12:40] speakman: alternatively, do a log of bzr.dev or something similar, and identify the revisions you think are noise? [12:43] This is how it could look: http://pastebin.com/f27a1b1d [12:44] speakman: if you don't like that then alias "merge" to "merge --pull" [12:46] speakman: IOW, oerson B should have done a simple 'pull' instead of a merge as his branch doesn't seem to have diverged. james_w: is that correct? [12:47] but if person b's branch had diverged, he would have checkins which would have been merged and would be shown. [12:48] (IOW, only merge when you have actual changes to merge) [12:48] * markh thinks... :) [12:48] or investigate rebase, but it's not really recommended [12:48] oh, never though of "pull". What's the difference with "bzr pull" and "bzr merge --pull" ? [12:49] merge --pull will do a merge if needed [12:49] pull will tell you a merge is needed [12:49] if the branches have diverged then a merge is required [12:49] the only way to avoid the extra revisions is to re-write history [12:50] oh, so the default action should actually be "bzr pull" for everyone? [12:50] and use only "bzr merge" when really needed? [12:50] depends how you look at it [12:50] (this should *really* be included in the docs!) [12:50] speakman: yeah, and yeah, it should! [12:50] if you always use "bzr merge" then your mainline records what happened to your branch [12:51] if you ever use pull then it synchronises your branch to the other, so the mainline shows what happened to their branch [12:51] I think the Docs are really good in general, but it lacks real world issues. Something like a web developing project example. [12:51] either one of those could be desirable [12:51] speakman: if you point to where you would have expected to find this in the docs we can fix it [12:51] lifeless: pong :P [12:52] bzr suffers from an "embarrassment of riches" in some respects - too many possible workflows... [12:52] james_w: I guess somewhere close to the "Workflows"-section imo [12:53] I think the Workflows-section is really good, but the "Real world examples" sounds like a section on its own [12:53] it could be said there are lots of scenarios, but not much in the way of real world guidance... [12:53] I think web developing (in php) is pretty commong [12:53] -g [12:53] I think what I do is pretty common too ;) [12:54] (which isn't that ;) [12:54] And the mess PHP programming can result in, it's a pretty hard case too ;) [12:54] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#team-collaboration-distributed-style [12:54] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#pseudo-merging [12:54] markh: I don't like PHP very much myself, but I really think it's one of the most wide spread languages and even used [12:55] so the doc explains the recommended workflow [12:55] which you didn't want [12:55] it could perhaps do with more on the difference between merge and pull [12:56] james_w: well, I'm not sure I agree with that :) In fact, I've heard jam argue that in many cases, asking every core developer to use a *checkout* of the trunk is best practice - particularly to avoid the whole "overwriting of history" thing which push can do and the details of which currently escape me... [12:57] yeah, and that's in the doc [12:57] if you have a trunk [12:58] * speakman 's reading the docs... [12:58] the broader point is that for someone completely new, the "best practice" isn't always clear - especially when coming from a VCS which only has *one* workflow :) [12:58] true [12:59] markh +1 [12:59] but you appear to have decided that you wanted the no-mainline approach [12:59] Anyone knows how "git" handles this? [13:00] you just wanted the less preferred "pull" workflow to go with that [13:00] which isn't documented, to reduce the number of documented workflows [13:00] I could go with a mainline, but then more people than me must be able to merge things into it. [13:00] it does "merge --pull" by default [13:02] The main problem is more that I need to introduce an easy way to real bzr newbies (and not very skilled users at all) to make use of bzr through the PHP development. [13:02] The actual problem is the PHP language which seems too easy to start with, and therefor will never filter some sort of people out ;) [13:03] speakman: so *my* preferred approach is to have a nominated "trunk" which people do *checkouts* from into a local dir. They then *branch* this local dir into another dir for performing changes, and make checkins to the second dir. When ready, they merge the second dir back into the first. This merge will leave an uncommitted merge into the initial checkout. They then test the merged changes, and perform a "checkin" into this checkout of [13:03] (this would probably never be a big issue if it was skilled C programmers) [13:04] markh: your message got truncated after "into this checkout of..." [13:04] speakman: i doubt it has much to do with the language :) If the developers may struggle with the dvcs concepts, you may be best "emulating" SVN with pure checkouts everywhere... [13:05] ... They then test the merged changes, and perform a "checkin" into this checkout of the trunk - the checkin then actually changes the remote trunk. [13:05] markh: They've no clue what's SVN... [13:06] speakman: conceptually, a single "checkout" they use and perform a simple "checkin" to with a single set of changes might be easier to convey... [13:06] But your example above seems like a way that could work... [13:06] which would change my example to avoiding the use of the second dir completely... [13:06] How about setting up an PQM and make them "bzr send" their changes? [13:06] ie, just do a checkout, make changes, test, checkin. [13:07] speakman: that's more than I know about, but probalby something you might consider further down the track... [13:07] markh: that seems like the easiest way, but then I could go with SVN as well right? :) [13:08] speakman: well, with svn you would be *limited* to that approach [13:08] With SVN I could setup an SVN server which they could commit their changes to, which even handles authentication and ACL. A thing i really miss with bzr serve. [13:08] but the more advanced developers could still use branches and merging if you use bzr [13:08] hi! we're deciding on a vcs to use here [13:09] markvandenborre1: go with bzr :) [13:09] and my colleague is wondering if there is some kind of visual studio 2k8 integration [13:10] markvandenborre1: not a functioning one I am aware of :) However, there is a good "tortoise" for general integration with explorer, "file open" dialogs, etc... [13:10] markh: point taken, next thing is to setup permissions for some users to commit checkouts to the mainline. That wouldn't be a problem if the mainline pulled them itself :) [13:10] I can only find a reference to a google summer of code project from 2007 [13:10] but no code at first sight [13:10] speakman: I'd love to, but I need cold hard technical arguments [13:10] over svn [13:11] speakman: if the trunk is behind sftp for example, then it manages write access IIUC. I've no clue about auth and the smart-server though... [13:11] markh: you mean tortoisebzr? [13:11] markvandenborre1: look at the tortoisebzr project on launchpad - the code is very current and very active - by me :) [13:11] yes [13:12] ah, I see [13:12] nice [13:12] markvandenborre1: IIUC? [13:12] sry, markh [13:12] "if i understand correctly" [13:16] markvandenborre1: the 1.11rc1 binaries are stable and include tortoise... [13:16] (the 1.10 binaries have a somewhat broken tortoise :( ) [13:21] markh: leaving ftps access to each committer will make the whole repository very vulnerable. If bzr serve could make use of authentication what would work as a command filter making sure people can only do commits and nothing else. [13:22] speakman: I'm afraid I'm not familiar with the various server options or their auth at all... [13:22] There is another option; using bzr as a CGI/WSGI interface. Then use Apache's own digest for authentication. [13:23] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#id80 [13:23] sorry: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/#serving-bazaar-with-fastcgi [13:24] to clarify, I've no actual *interest* or desire for knowledge in that either ;) [13:24] (here at my company we use smart serve with inetd and it works really good, but then it's a local protected network) [13:25] yeah, I've too much experience in integrating NTLM authentication with various servers to find it remotely interesting... :) [13:26] I'd rather keep auth as officially "somebody else's problem" [13:27] NTLM? [13:28] windows auth [13:28] Windows? (kidding... :) ) [13:29] :) [13:29] I still think there should be a real world use case based on web developing in the docs. [13:30] +1 [13:30] but then again, I'm too lazy to write that out myself [13:31] (doing other work to help free software, though, like helping to organise FOSDEM) [13:31] markh: thx for the helpful hint on tortoisebzr [13:32] After this web project has start working in a great maner, I might write one. But until then I really need a working solution to start with :) === kiko is now known as kiko-phone [13:36] speakman: there are lots of working options - the most appropriate depends on lots of things though [13:36] popd [13:36] oops :) [13:37] bzr break-lock isn't working for me for some reason: http://paste.pocoo.org/show/100522/ [13:38] I tried it several times, but it doesn't want to break [13:38] vadi2: there is no evidence there of you having run 'bzr break-lock lp-46717904:///~vadi-mapper-dev/vadi-mapper/main/.bzr/branch/lock ' [13:39] It still says just error, unsupported [13:40] http://paste.pocoo.org/show/100523/ [13:42] sorry, no idea :( [13:44] "bzr break-lock lp:vadi-mapper [13:44] Augh, I keep copying newlines. [13:44] vadi2: "bzr break-lock lp:vadi-mapper"? [13:45] The error message giving the wrong URL is either a known bug or was fixed a month or two ago. [13:45] ey that worked, thanks! === bac is now known as bac_afk === bac_afk is now known as bac === aumontabe is now known as abeaumont [15:18] Hi there. I made the mistake to bzr add a big directory of never changing binaries, and now I have a huge .bzr. How can I "unversion" the directory and drop it from the .bzr repository forever? === fawek_ is now known as fawek [15:26] Le-Chuck_ITA: was this in the last revision, or has it been going on for a while? [15:29] it has been going on for a while [15:29] james_w: googling around it seems that the easiest solution is to re-init the repository! [15:30] there's not a good answer for that yet [15:30] you could re-write the repository to remove that data, but the code hasn't been written yet as far as I know [15:31] james_w: thanks at least now I know this... will be more careful next time. [15:33] You could rebase your repo [15:33] branch it at -r [15:34] awilkins: that won't make the .bzr smaller [15:34] Hmmph, I'm not thinking this through [15:34] and I like to pass the .bzr along by email :) [15:35] Once you've eliminated the revision with teh binaries you can branch it off to a separate repo and send that instead. [15:35] But I'm now not sure rebase will do that :-( [15:36] thanks I may try later but the history until now was "monotonic" in the sense that we didn't erase anything yet :) Thus if I throw it away I am just fine [15:37] That's certainly the easiest route :-) [15:37] jam: ping === asac_ is now known as asac [15:56] can anyone tell me when I should merge and when I should pull changes? [15:57] in my case I have a development branch and branched from it a testing branch. now when the development branch evolved should I merge or pull the changes into the testing branch? [15:59] as far as I understand it a pull does pulls in the changes from the development branch which results in two equal branches (assumed the testing branch has not evolved separately) [16:00] while a merge will reflect the merge in the testing branch's history [16:00] vila: pong [16:01] so I get two different branches because the testing branch shows in its history a merge. [16:01] am I correct? === kiko-phone is now known as kiko-fud [16:21] hey guys i need a little help getting my head around setting up a bzr repo [16:21] i have created /home/bazaar/repository/web/project/example.com/ [16:21] then bzr init in example.com [16:22] i then do a checkout from a ssh user e.g. /home/developer1/dev/example.com [16:22] I have apache setup so that i can view the dev version for my developers e.g. dev1.example.com [16:23] which has a document root at /home/developer1/dev/example.com [16:23] but I want to have branches in my repo e.g. /home/bazaar/repository/web/project/example.com/developer1/ /home/bazaar/repository/web/project/example.com/developer2 [16:23] which i am not sure how to do [16:24] or in fact how i would manage the branch changes and merge them back into the trunk [16:24] the idea is that every developer has their own space on the server to develop and then i can push from the trunk to a live server when i am happy with the changes [16:25] so really just after some advise or pointers. Odly, there seems to be very little that a google returns on this [16:28] what's the problem with trac on bzr ? [16:29] see http://bazaar-vcs.org/TracBzr [16:29] someone told me that DVCS aren't very manageable with trac [16:29] 'couse it's slow [16:29] https://launchpad.net/trac-bzr [16:37] How do you start the QBzr bundled with the Mac OS X .dmg? [16:38] bzr qbzr [16:44] regarding my case I just explained, please let me just know what you would do...? [16:47] trac or launchpad ? [16:47] I can't decide === BjornT_ is now known as BjornT [17:23] hi [17:25] I installed bzr but bzr is not working behind proxy with authentication. [17:26] what to do? === abadger19991 is now known as abadger1999 [17:52] shankhs: What os are you using? [17:52] I know you can set the $http_proxy environment var on linux [17:53] Not sure if it works on windows though. [17:54] export http_proxy=http://username:password@host:port/ [18:12] I am getting GPG verify error when using the PPA repository. Has anyone else been getting this error? [18:14] ericvw: it's signed now [18:15] you could add the key to avoid MITM attacks [18:16] james_w: how can I do that? [18:16] apt-key [18:17] you can get the key from keyserver.ubuntu.com [18:17] id is 8C6C1EFD [18:18] you can then check the fingerprint at https://edge.launchpad.net/~bzr/+archive/ppa [18:18] if you are using the "bzr" ppa that is [18:19] james_w: Sorry I am a bit new to using apt-key and adding sources to apt-get, so how do I use apt-key with keyserver.ubuntu.com? [18:19] dunno :-) [18:19] interesting. I'll search around a bit. Thanks! [18:20] I am having a few problems with bzr ignore. The directory I am trying to ignore is not versioned and has been added using bzr ignore config/*. shows in .bzrignore but when i do a bzr st the folder comes up as unknown and the files in config/* are not shown when i do a bzr ignored. This leads me to believe that it has not worked properly. My terminal output can been seen here http://pastebin.com/m7deae95e. Any ideas? [18:22] ericvw: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xD702BF6B8C6C1EFD is where the key is [18:22] ollie: bzr ingore config [18:23] *ignore [18:23] Warning: the following files are version controlled and match your ignore pattern: [18:23] concrete/config [18:23] wget -O - "http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xD702BF6B8C6C1EFD" | egrep -v "^<" | sudo apt-key add - [18:23] ericvw: ^ [18:24] I got it [18:24] james_w: thanks [18:24] no problem [18:24] ollie: bzr ignore ./config [18:26] garyvdm: is it possible to remove a rule? [18:26] i edit it using vi but it just seems to come back [18:26] Ollie: I normaly just edit .bzrignore by hand [18:26] yeah thats what i am doing weird [18:27] ollie: Not sure why [18:27] bzr ignore ./config/* that should just ignore the directory config in the root dir right? [18:28] Your shell should expand that to all of the files in config. [18:29] yeah it does so ./config/site.php then ./config/site_theme_paths.php (great) then config (doh). If i manually remove the last one config it gets written back in [18:30] it seems to be trapped in a loop [18:31] :( [18:34] cracked it :) [18:34] still don't see why bzr ignore ./config/site.php doesn't work [18:34] but hey [18:36] garyvdm: thanks for the help :) [18:37] ollie: Pleasure [19:15] I am having trouble serving up my branch with the dedicated 'bzr serve' server [19:15] client says 'foo' not a branch [19:16] rather bzr://foo/root [19:16] bzr info on server branch says it is the 'branch root: .' [19:17] I am following the instructions at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server === beaumonta is now known as abeaumont === spm_ is now known as spm [19:46] sevenseeker: bzr:// requires a domain name or IP address [19:48] I have an entry in my /etc/hosts file, plus I tried using IP... same results [19:50] sevenseeker: what command do you run on the server, from which directory? And what exact command do you run on the client? [19:52] ok, I had a relative path for the --directory directive, that was the problem. I read about that but remembered incorrectly that it applied to only the bzr+ssh option [20:11] morning [20:12] igc, hi! [20:12] just FYI, your plugin for caching revnos has made me extremly happy [20:12] haven't started testing it, but I will tomorrow [20:19] thanks beuno. I thought you'd like it [20:20] would it help under loggerhead? [20:20] or in combination? [20:21] igc, it would ROCK in loggerhead [20:21] if we had that, and I understood how to access merge points partially, we may be able to solve a lot of the performance issues [20:22] as well as change the underlying madness I've been wanting to re-write [20:22] beuno: so I think our goal should be to make the two plugins complementary [20:22] it was on my ToDO list to write exactly what you did, so I'm very happy that just popped out [20:22] I don't think we want to cache twice [20:23] in two separate places [20:23] igc, absolutely [20:24] bzr push:parent works only with developer version? [20:24] beuno: I'm also planning to extend it to store depth information and to keep the data in top sorted order, allowing me to make log go faster [20:24] igc, this doesn't, OTOH, make the initial hit cheaper [20:25] ie, I'll have to generate the full revision graph at least once [20:25] beuno: right, but you only get that once after the tip moves [20:25] s/top/topo/ [20:25] igc, how about caching the merge-points between them as well? [20:25] gsuveg: you need a fairly recent version [20:25] 1.10 perhaps [20:26] * james_w waves to igc and beuno [20:26] Bazaar (bzr) 1.11 [20:26] hi james_w [20:26] * beuno waves back to james_w [20:26] ive this and dont wokrs :) [20:26] beuno: one step at a time :-) [20:26] :) [20:27] igc, if the tip changes, the cache gets invalidated? [20:27] beuno: I thought it was a good effort for a day's work [20:27] beuno: currently [20:27] igc, it would of taken me over a week, so it's an amazing effort for a day IMHO ;) [20:28] anyway, I'll start diving into it tomorrow, and will try to actually contribute patches and other useful things [20:28] beuno: if there are no merge revisions in the new revisions, I'd like to append to the cache rather than wipe it but that's not done yet [20:29] ah! that sounds interesting [20:30] igc, I wonder if I combined the partial revno access jam worked on, with this plugin, I can make an even bigger cut in performance [20:30] beuno: I'd expect so [20:30] igc: as long as the mainline doesn't change, you can always append to the cache [20:31] so even if you merge, etc [20:31] so if old_tip is in branch.revision_history() then you can append new values [20:31] that said, only the lazy_revno branch is able to compute just some of the numbers [20:31] so you wouldn't save any time with bzr.dev [20:31] the trouble is that with really large branches like emacs and OOo, no amount of "make the algorithm faster" competes with "just cache the end result" [20:32] igc: sure, there are just various ways to reduce the amount needed to cache, etc. [20:32] jam, by "some of the numbers", do you mean "only mainline revnos"? [20:33] beuno: if you don't change the mainline revisions, dotted revnos never change [20:33] so if you append new mainline revisions [20:33] the existing dotted revnos won't change [20:33] only if you 'push' a new mainline would things change [20:33] igc: at one point though, you'll hit the "loading cache result" is longer than "calculating only some revnos" [20:33] right, vila. that was the goal to get to [20:33] but really hard to achieve from my experience [20:34] * beuno is very happy that the revno performance topic is back on the table [20:34] jam, vila: right. [20:34] I *am* curious what effect my lazy_revno branch would have on your timing numbers [20:34] for emacs, revno-cache comes in at 5M or so [20:34] since I think for emacs it would actually do pretty darn good [20:35] load time in 1.1 secs on my laptop [20:35] as they don't (yet) have complex merging ancestry [20:35] IIRC [20:35] right: 100K revs, 93K on mainline [20:36] so some merges but nothing like mysql say [20:36] igc: hehe [20:36] igc: how are you persisting the cache [20:36] ? [20:37] mwhudson: simply as revno\trev-id\n, one per line [20:37] ah ok [20:37] it's readable :-) [20:38] igc: You could easily use a btree to do so [20:38] btw [20:38] how bad would it be to create files with the revid as their name, and the revno as their content? [20:38] and then you could look up a single value without having to read the whole thing [20:38] I think you still need the merge depth [20:38] igc: should be easy to index.. (jam was faster :P) [20:39] ah, btree's accomplish that [20:39] beuno: you want to create 100k files ? [20:39] i guess for large caches (ab)using sqlite might be faster [20:39] or yes, a btree [20:39] bye [20:39] vila, well, I want to access a revid without going through a big list. 100k files is a side-product. But I get it, it's not good :) [20:41] jam: yes, I still want and need to cache the merge depth too. [20:42] igc: https://code.edge.launchpad.net/~jameinel/bzr/lazy_revno [20:42] If you want to play around with what I worked on [20:42] You may want to wait for the next mirror, since I merged bzr.dev and resolved the conflicts [20:43] or get it from http://bzr.arbash-meinel.com/branches/bzr/1.6-dev/lazy_revno [20:44] thanks [20:45] I think it currently has some bugs wrt numbering of ghost revisions [20:46] Partly because internally we are a bit inconsistent about how we handle them and NULL_REVISION === mDuff is now known as nDuff [20:49] BNF-Austin, howdy. [20:50] hello, that you Duffy [20:50] BNF-Austin: Greetings from near Mopac & US-183 [20:50] all, BNF-Austin is Basim Faris, one of the partners behind NossaTV (an early adopter of Bazaar, several years ago) [20:51] davidstrauss, heh -- I'm over by Braker and 183. [20:51] i'm off 620, close to Lakeway. Working from home. [20:53] * nDuff is only working with NossaTV on an occasional and informal basis these days, and thus in the process of introducing BNF-Austin &c. to community support resources. [20:57] Thanks for all the work that you has gone into. bzr. It has been great to use over the years. Duff suggested that I join, so that I can bug you guys, when i make beginner mistakes as I try to manage remote bzr instances... thanks ahead of time, I will do my best to avoid wasting your time. [20:57] igc: so in my quick (and limited) testing, doing: [20:57] 'ian.clatworthy@canonical.com-20090120040338-yxg0r2ab45lqtks9' [20:57]