=== Rotund [n=rotund@d28-101.rb2.lax.centurytel.net] has joined #bzr [12:21] Hey, is there a way to get bzr branch to get the latest revision first, copy it out so it's a working copy *then* get the history. === Treeform [n=me@c-76-104-152-100.hsd1.wa.comcast.net] has left #bzr ["rats] [12:21] ? [12:23] grimboy_uk: No. That would mean fetching a bunch of data twice. [12:26] But it would also mean starting quicker. [12:26] Since sometimes history takes ages. === fog [n=fog@debian/developer/fog] has left #bzr [] [12:29] grimboy_uk: the only way to get the latest revision is to build it from the entire history, afaik. [12:30] so your first step would: 1) fetch all the history, 2) make a working copy from it. [12:30] then your second step would: 3) fetch all the history. [12:30] It works as it currently does for a reason. :) [12:31] It may work differently if/when horizon branches/checkouts are implemented. [12:31] But my guess is that that would require a smart server. [12:32] grimboy_uk: Fetching partial history is something that jelmer's working on. But fetching the working tree, and then fetching all history as one operation doesn't make sense. It takes longer. [12:33] abentley: plus, not all repositories will have a working tree. [12:33] and you can't rely on the working tree being up to date. [12:38] NfNitLoop: Oh, fetching from the remote working tree would be total crack. [12:39] aah, ok. :) [12:39] abentley: any idea how you'll end up with a working tree with a partial history, then? [12:40] abentley: am I right in assuming you'll either need a smart remote server, or you'll still have to fetch the whole history? [12:40] I was talking about fetching only the data to build the working tree from the repoistory, and then fetching all the data. [12:40] NfNitLoop: No, there's no reason you'd need a smart server. You just fetch what you want. [12:41] abentley: wouldn't you possibly need the whole history of a file to rebuilt it in its current state? [12:41] Sorry if I'm way off... I don't actually program vcs back-ends. :) [12:41] No. The storage format has periodic snapshots of the complete text. [12:42] Oh really. As it is now? Or as it will be with horizon support? [12:42] As it is now. [12:42] It's a performance thing. We must not scale with the length of history. [12:43] Yeah, I wondered about that. [12:43] Hmm. What's the (rough) algorithm for deciding when a new snapshot should be stored? [12:44] is it per file, or per the entire repo? [12:44] I don't know the current status. Originally, it was every 25 revisions, but it might be "every time the size of deltas exceeds the size of the fulltext". [12:44] It is per file. [12:46] As it turned out, we do scale with the length of history, due to the indexes. Which is the problem keir is working on. [12:54] Hmm. How so? because the entire index must be read for an operation? [12:54] And that's O(n) and not O(log(n))? [12:57] NfNitLoop: Yes. === marcus [n=user@gnu/the-hurd/marcus] has joined #bzr [12:58] The new pack format is designed to make recent data fast, at the expense of making old data slow. [12:59] hi. when I use a shared repository, is there anything I need to pay attention to when removing branches? or should I just use rm -fR branch? [12:59] rm -R branch should do fine. [01:00] No need for the -f. [01:00] There aren't any caveats, except that removing the branch doesn't remove the revisions you've committed. [01:01] Just a pointer to them. [01:01] abentley: I was talking about this earlier with someone. Isn't there a command that will prune your shared repo? [01:01] or was it a plugin? [01:02] Yeah, there's a plugin. [01:02] marcus: worst case, though, you create a new shared repo, branch your remaining branches over there, and delete your old/bloated repo. (if its size becomes too big.) [01:03] but that should only happen if you're working with lots of patches that you're throwing away. (ie: rarely) [01:03] lots of *big* patches. :p === pygi is now known as pygi_test [01:13] NfNitLoop: you mean that is semantically what the pruning plugin does? [01:14] thanks, guys. I didn't check out all plugins. It makes sense for a pruning operation to exist. [01:15] marcus: Yeah, it does, but only for security or if you've accidentally committed an ISO. === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr [01:19] abentley: maybe I was just confused because I don't have the right mental model about internal details. from a newbie point of view, it's more comforting if the operation that removes a branch is available through bzr, or at least documented that rm -R is safe. === jml [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr [01:19] irregardless of pruning. [01:22] Yeah, we should probably make it clearer that rm -R is safe. [01:24] while I am here. I recently imported an SVN repository, but not via bzr-svn but using a different stand alone tool (svn2bzr.py). Trying to push bzr changes back to svn failed with an "no merge base revision specified", but I couldn't figure out how to set a merge base revision. === phanatic [n=phanatic@dsl54009CAF.pool.t-online.hu] has joined #bzr [01:25] marcus: Because you didn't use bzr-svn, you can't push back. === sii [n=sii@tranquillity.sii.se] has joined #bzr === dholm [i=dholm@gentoo/developer/dholm] has joined #bzr === SteveA [n=steve@canonical/launchpad/SteveA] has joined #bzr === quicksilver [n=jules@212.69.38.59] has joined #bzr === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #bzr === metze_food [n=metze@ip-217-172-181-76.mx-netz.de] has joined #bzr === taaz [n=dlehn@66.37.66.32] has joined #bzr === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr === Basic [n=Basic@gatekeeper.real-time.com] has joined #bzr === ThomasAH [n=thomas@aktaia.intevation.org] has joined #bzr === siretart [i=siretart@ubuntu/member/siretart] has joined #bzr === AndyP [n=andyp@ubuntu/member/welshbyte] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === dato [n=adeodato@debian/developer/adeodato] has joined #bzr === marcus [n=user@gnu/the-hurd/marcus] has joined #bzr === gldnspud_ [n=gldnspud@72.171.93.139] has joined #bzr === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #bzr === meuh [n=meuh@pdpc/supporter/active/meuh] has joined #bzr === Theuni [n=ctheune@uter.gocept.com] has joined #bzr === dirker [n=dirker@woosome.net] has joined #bzr === alla [n=alla@soy.cyber.com.au] has joined #bzr === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr === thatch [n=thatch@pool-71-170-167-50.dllstx.fios.verizon.net] has joined #bzr === jeremyb [n=jeremy@unaffiliated/jeremyb] has joined #bzr === mw [n=mw@189.146.24.28] has joined #bzr === james_w [i=jw2328@jameswestby.net] has joined #bzr === Rotund [n=rotund@d28-101.rb2.lax.centurytel.net] has joined #bzr === bigdo1 [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr === jml [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr === niemeyer [n=niemeyer@200-103-134-216.ctame705.dsl.brasiltelecom.net.br] has joined #bzr === grimboy_uk [n=grimboy@85-211-251-75.dsl.pipex.com] has joined #bzr === Kamping_Kaiser [n=kgoetz@gnewsense/friend/kgoetz] has joined #bzr === pygi_test [n=mario@83-131-64-132.adsl.net.t-com.hr] has joined #bzr === sverrej [n=sverrej@tul-1x-dhcp017.studby.uio.no] has joined #bzr === herzel [i=herzel@gateway/tor/x-b6c989ddb8048cdc] has joined #bzr === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === cory [i=cory@zeus.penguinhosting.net] has joined #bzr === statik [n=emurphy@canonical/launchpad/statik] has joined #bzr === ddaa [n=ddaa@canonical/launchpad/ddaa] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === uws [n=mathilda@213.207.93.150] has joined #bzr === NfNitLoop [i=codyc@cpe-70-112-28-217.austin.res.rr.com] has joined #bzr === ion [n=ion@70-58-119-250.phnx.qwest.net] has joined #bzr === pete__c_ [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr === kanhaiya_kk [n=kanhaiya@freemap.in] has joined #bzr === arjenAU [n=arjen@mysql/community/arjenAU] has joined #bzr === michelp [n=michelp@70.103.91.130] has joined #bzr === jelmer [n=jelmer@157pc196.sshunet.nl] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === _logger [n=_logger@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has joined #bzr === welterde [n=welterde@trujillo.srv.pocoo.org] has joined #bzr === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === bigdog [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr === ryanakca [n=ryan@ubuntu/member/ryanakca] has joined #bzr === jdong [n=jdong@ubuntu/member/jdong] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr === troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net] has joined #bzr === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === rotty` [n=user@81.223.119.66] has joined #bzr === ipkiss [i=ipkiss@nat/ecp/x-0fa243067226cbc6] has joined #bzr === jrydberg_ [n=johan@213.115.45.46] has joined #bzr === dennda [n=dennda@ubuntu/member/dennda] has joined #bzr === sevrin [n=sevrin@ns1.clipsalportal.com] has joined #bzr === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr === hmeland [i=29578@klodrik.uio.no] has joined #bzr === Odd_Bloke [i=oddbloke@compsoc.sunion.warwick.ac.uk] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr === radix [n=radix@70.91.133.157] has joined #bzr === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #bzr === johnlr2 [n=johnlr@203-206-162-97.perm.iinet.net.au] has joined #bzr === thumper [n=tim@canonical/launchpad/thumper] has joined #bzr === fullermd [n=fullermd@adsl-072-148-013-213.sip.jan.bellsouth.net] has joined #bzr === Kinnison [n=dsilvers@spoo.flarn.net] has joined #bzr === Peng_ [n=mnordhof@fl-69-69-148-134.dyn.embarqhsd.net] has joined #bzr === gldnspud_ is now known as gldnspud === NfNitLoop [i=codyc@cpe-70-112-28-217.austin.res.rr.com] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1088826610.dsl.bell.ca] has joined #bzr [01:32] Oh, netsplit. Haven't seen that for a while. [01:33] 24.2 second lag. Wheee. [01:33] Usually I'm not on the wrong end of one. [01:33] 46.1-second lag! 18.2. === Peng_ is now known as Peng === Verterok [n=ggonzale@184-220-114-200.fibertel.com.ar] has joined #bzr === pygi_test is now known as pygi === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [01:55] morning === marcus [n=user@gnu/the-hurd/marcus] has left #bzr ["ERC] [02:07] hi abentley [02:07] abentley: I'm not here today :) - just whipping past [02:08] lifeless: Okay. I may have a CommitBuilder.abort patch for you in a bit. === beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr === beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr === beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr === mw is now known as mw|out === jbailey [i=jeffbail@nat/google/x-d54745752e4d3e55] has joined #bzr === grimeboy [n=grimboy@85-211-247-55.dsl.pipex.com] has joined #bzr === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [02:34] my osx has even stumped the gurus (for now) [02:34] was hoping it was something specific to my box [02:36] Are you the guy with the WoW? [02:36] no comment :-P ... yes [02:37] all my guild osx people are poking fun at me and how this line-x thing doesn't "work" under osx [02:39] will work through some of the ulimit things I saw today. will do the selftest and get with ulimit on open files at 4096 and see what happens. [02:40] Well, I'm the TreeTransform guru and I'm hardly stumped. [02:41] oh? What's John's guru-ness? :-) [02:41] John's guruness? The patience diff code and checkouts are the first things to come to mind. [02:42] But I am the principal creator of TreeTransform. [02:42] Anyhow, the first thing to do is disable TreeTransform.finalize(). It's masking the real error. [02:44] Just edit transform.py and make finalize return early. [02:44] Then rerun the operation that usually fails. [02:47] I'll give it a try, thank you for the advice, rid here, I'll work on it on the commute home. === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === keir [n=keir@76-10-155-93.dsl.teksavvy.com] has joined #bzr [02:58] lifeless, ping! [03:02] Speaking of patiencediff, Hmm, easy way to run patiencediff on a directory? python -m bzrlib.patiencediff only accepts files. [03:02] :( [03:04] keir: lifeless may not be around (much) today - public holiday [03:04] oh, i thought that was yesterday [03:04] aah timezones === abadger1999 [n=abadger1@65.78.187.68] has left #bzr [] [03:15] keir: I am serious when I say if you implement your graph index in C, we will not merge it. We write in python first, and optimize in pyrex if justified. Look how long it's taking your patience diff to get merged. === Rotund [n=rotund@d28-101.rb2.lax.centurytel.net] has joined #bzr [03:16] i did not write patience diff === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr [03:17] and i'm writing it in python [03:17] so please, chill! [03:19] You said you were very tempted to write it in C. I wanted to be clear about this, because I didn't want you to write it in C and then be upset when it didn't get merged. [03:20] there has to be a python version because of all the funky transports [03:20] but i will write a C version for local disk, just not immediately. [03:21] For compiled code, I think we have a preference for Pyrex over C. [03:22] well, the issue is that i can see this bit of code useful outside of bzr [03:22] And it may well be that only a small section is performance critical. [03:22] in which case pyrex is out === herzel [i=herzel@gateway/tor/x-c35cba79cc778ab0] has joined #bzr [03:22] but whatever, python first === NamNguyen [n=namnt@203.162.163.50] has joined #bzr [03:24] Cool. Thank you for working on this. [03:24] i'm writing this up for the ML as we speak [03:24] i have a few questions before i send though [03:25] which you can prob answer [03:25] in the pack-based repo, what is different graphs are stored? [03:25] and what is the size / type of each bit of data? === bigdog [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr [03:26] rather, average number of edges out from a node, in from a node [03:26] i'm not looking for exact numbers, just trying to get a feel [03:26] Well, there are four things we store: revisions, inventories, signatures, and file texts. === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [03:26] i've been working on the graphindex without *really* understanding the rest of bzr, because i enjoy these types of fast compact data structure problems [03:27] revisions and inventories have the same graph layout and revision-ids. [03:27] ok [03:28] file-texts are subset of the revision graph. [03:28] You have one for each file, and it only gets a new revision when the file is modified. [03:29] So given two nodes in a file graph, they have the same relationship as their corresponding nodes in the revision graph. [03:29] hmm, ok [03:29] Take the NEWS file for an example. [03:30] If NEWS is modified in revision A and revision B, there will be entries in its graph for those revisions. [03:30] i see === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [03:30] If B is descended from A in the file graph, B will descend from A in the revision graph. [03:31] ok, i understand. so file texts are the revision graph if you eliminate all other files from the revision graph [03:31] or rather, the subset of the revision graph in which that file was modified [03:32] I don't follow you. Many files may be altered in the same revision. [03:32] so in the rev graph, the storage is revID->???, and edges are more revID's [03:32] There is a graph for NEWS, another for builtins.py, another for README, etc. [03:33] Yes, revision ids are the same in all of our graphs. [03:34] abentley, as in, if you imagine a graph is k->v and k->k*, for the rev graph, what are the values? [03:34] For the revision graph A -> B -> C, let's say NEWS is only modified in A and C. This means that the NEWS graph will be A -> C. [03:34] yes, i understand [03:35] so the rev graph has no actual values in each node? just the references to other revids? [03:35] What are the values associated with nodes in the revision graph? [03:35] yes [03:35] They are the commit metadata. [03:36] basically, I think my current graphindex is so cool we may want to store more than just an index in it :) [03:36] Commit message, timestamp, commiter, etc. [03:36] The cat-revision command should show you exactly what is stored for a revision. [03:37] e.g. bzr cat-revision -r -1 [03:37] ah, neat [03:38] woah, xml [03:38] do you actually store XML internally? [03:38] or lzw'd xml or something? [03:38] Yes, we do. [03:38] Don't hate us for it :-) [03:39] I should draw your attention to the properties list; this is arbitrary data. [03:39] i'm usually with jwz on the quote 'some people, when faced with a problem, think "I know, lets use xml.". Now you have two problems.' [03:39] but whatever, this is fine [03:39] See the header of xml_serializer.py for a similar sentiment. [03:40] ok, then my next question is, how is the rev graph stored on disk? [03:40] It is stored in kndx files. [03:42] The specifics of the knit index format are outside my area of expertise. But you're working on replacing it, so it can't be altogether perfect. [03:42] The implementation is KnitIndex in knit.py [03:43] ok [03:43] The particular kndx is revisions.kndx === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [03:46] So revisions.kndx serves dual purposes: describe how to extract the revision XML for a given revision, and describe the revision graph. [03:47] ok [03:49] You can call repository.get_revision_vf() to get an object to play with. Or you can call revision.get_revision_graph to get a dict-style graph. [03:50] Another thing about the revision graph is that it applies to all projects in a shared repository. [03:50] Whereas the per-file graphs are almost always for a single project. [03:52] even though they are stored in the same file [03:53] The per-file graphs and revision graph are not stored in the same file. [03:54] (I'm not sure what "they" referred to) [04:04] keir: When you come back, just say "abentley: ping" [04:04] (on phone 3 mins) [04:06] ok, back [04:07] as in, there is one big file-text file, even when the per-file graphs are for a single project [04:07] in a shared repo [04:08] abently: ping! [04:13] keir: oops. Needs "ey" at the end. Anyhow, I'm back. [04:13] ah, heh [04:13] now i see that knitindex and graphindex are parallel :) [04:14] There is not one big file-text file. There is one knit & knit index per file. === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr [04:15] aaah, ok [04:15] They are identified by their file-id, which is used elsewhere in bzr to uniquely identify files. [04:16] And because the file-id is semirandom, two projects containing a file named README will have different ids and knits for it. [04:16] even with the same contents? [04:17] Yes. Bazaar doesn't care about content the same way git and hg do. [04:17] is this a weakness or a strength? [04:17] We consider it a strength, because it allows us to import from other systems losslessly. [04:21] and why would it be considered a weakness? [04:23] To an extent, other systems will identify some tree-shapes as "the same" even when they were produced separately, and so bzr would consider them different. This approach also provides obvious ways to validate a tree. [04:29] ok [04:32] Anyhow, our current systems stores revisions, inventories, signatures and file texts separately. Packs centralizes them. [04:34] We still need different indexes, because our code expects them to be separate. [04:35] ok [04:35] why? [04:35] more accurately, what does the code need that can't be put in one file? [04:36] In theory, a single file could store all four indices. [04:37] It's the in-memory representation that needs to treat them differently. [04:38] the way i'm writing my stuff, the in memory representation can be (almost) the same as the on disk format [04:40] In the current pack format, there's an adaptor that converts the index into an index for just a particular file. [04:40] GraphIndexPrefixAdapter [04:41] I think one reason for splitting them up is that they have different access patterns. [04:41] that's reasonable [04:41] and relevant to me; are they mostly repeated traversals? [04:41] right now, my stuff optimizes for that [04:41] aka follow links repeatedly [04:42] Following the same set of links? [04:42] because in the 'dumb' implementation, that's exactly what's slow [04:42] as in, you are on file ref A, then you want to go to its successor [04:42] then that nodes' successor, and so on and so forth [04:42] and yes, same 'set' of links [04:43] in my version, there is only one graph represented (aka not multiple adjacency lists) [04:43] because then you can't order things nicely for repeated traversals [04:43] Well, there are two kinds of access patterns: tree-wide and history-deep. [04:44] "bzr checkout" would be tree-wide. We want one copy of the text, for each text in the tree. [04:44] which is repeated DFS type of thing? [04:45] So we build each text by finding the all the deltas until we hit a fulltext. Then we apply the deltas to the fulltext to get the version we need. [04:45] I'm not sure what DFS is. [04:45] depth first search [04:45] in my current code, that should be _very_ fast [04:46] one question: how do you decide which link to follow if there are multiple links? [04:46] Yes. Really, it's depth-only search, because only the lefthand ancestry must be traversed. [04:46] ok, i don't quite understand that === orospakr [n=orospakr@bas4-ottawa23-1096745064.dsl.bell.ca] has joined #bzr [04:47] Okay, do you know that Bazaar treats node parents differently depending on their position? [04:48] no! good to know [04:48] You get multiple parents in merge situations, right? [04:48] i apologize for not knowing all this stuff [04:48] yes [04:48] OH! i think i get it [04:49] So the lefthand parent is always the revision you had before you did the merge. [04:49] That's how Bazaar does it, anyhow. [04:49] you creat a new edge from before the 'branch' which contains the merge diff [04:49] or am i talking crazy [04:49] No, we don't do it like that. [04:50] say there's a file that branches, then on each branch there's a few revs, then it merges [04:50] Okay, let's draw a quick graph: A -> B, A-> C, A->D, [C, D] -> E [04:51] when you go backwards, how do you know which edges to traverse? [04:52] ok, i drew the graph [04:52] Oops. [04:52] I goofed on it. [04:52] :) [04:52] Ignore A->B [04:53] and B itself? [04:53] Yes. [04:53] So the story is I commited revision A. You branched me, and committed revision D. At the same time, I committed revision C. [04:54] Then I merged your branch, and committed the result as E. [04:54] Because I did the merge, C is the lefthand parent of E. [04:54] If you had done the merge, D would be the lefthand parent. [04:54] i see [04:55] and if there was another branch, F, taking the same path A->F->E [04:55] and you _also_ merged F, then it would be the same [04:55] Yes. [04:55] even though there are edges c->e and f->e [04:55] ok [04:55] that's really neat [04:55] Yes, heads are ignored in the parent list. [04:55] Sorry. [04:56] Only heads are *listed* in the parents list. [04:56] and that's to prevent repeated merging [04:56] So [C, F, E] becomes [C, E] [04:56] Oh, repeated merging still happens. [04:57] ok [04:57] Anyhow, deltas also follow the lefthand ancestry. [04:58] so, to be clear, the left hand edge c->e implicitly contains the deltas a-> and a->f [04:58] So for my graph, there is no E -> D delta, only an E -> C delta. [04:58] yes, exactly [04:58] the link exists but there is no delta change [04:58] Right. We could record it, but don't. [04:59] so in a pack, why not store all this consecutively? [04:59] for a single node, you store refs to your children, and some arbitrary edge-value [05:00] So if A is a fulltext, we get A, apply A -> C, apply C->E. [05:00] it sounds like the new packs store the deltas in a big list, and then those are indexed in the GraphIndex [05:00] abentley, yes, i understand now. i was confused about the merging. [05:00] That's the only possible recipe to produce E. [05:01] So that's why *for building texts*, it's a depth-only search. [05:01] great [05:01] and that search would happen in the fulltext graph, which is a subset of the revisions graph [05:01] I would expect that packs do store entries topologically-sorted, but not necessarily ajacent. [05:02] i imagine in almost all cases, the number of edges is < 5 [05:02] in which case toposort would do pretty well [05:03] Yes. about 75% have only 1 parent. I would guess less than 2% have more than 2 parents. [05:03] ok. is there many cases where you want to traverse the graph _without_ also grabbing the related diffs? [05:04] We would do that when running "log". [05:04] i.e. log FILE [05:05] That's pretty rare. [05:05] ok [05:05] We are still just talking about files here. [05:05] yes [05:05] For revisions, we use the graph quite differently. [05:05] i am starving, i'm going to go grab something to eat; will you be around in 15 mins? [05:05] Sure. [05:05] Ping me. [05:05] great! ttyi15 [05:28] abentley, ping! [05:29] Hey. [05:29] look at that, xchat can spell better than me === BasicOSX [n=Basic@fortress.tanners.org] has joined #bzr [05:29] so: revision graph usage [05:29] Right. [05:30] We use the revision graph for log all the time. I think breadth-first is the right term for the "log" access pattern. [05:30] Because we show all parents of each revision. [05:31] Sorted topologically. [05:31] ok [05:31] actually i think that's a DFS [05:31] rather than a left-child-traversal [05:31] err, hmm. nevermind, you are right [05:31] Okay. I never studied graph theory. [05:32] We also use the revision graph for merge base selection. [05:32] This is done by merge, pull, push, update. [05:33] This is again breadth-first traversal, but we stop when we hit an LCA. [05:33] LCA? [05:33] Least Common Ancestor. [05:33] ah, ok [05:34] So for this access pattern, incremental reads are a big win. [05:34] yes [05:34] Ideally, the data is topologically sorted with newest data first [05:34] yes [05:35] this is what i have now [05:35] however, topological sort is ambiguous [05:35] there are many topological sorts for a given graph [05:35] my current plan is to take the left-link when doing the topo sort [05:36] We do already have a topo-sort routine. [05:36] (tsort.py) [05:37] But yes, there may be gains in favouring left-parent ancestry. [05:39] ok [05:39] so, the tradeoff if you store all the data (diffs, etc) in with these graphs [05:39] is that in the merge case, you only want ancestry [05:40] it looks my design still makes a bunch of sense. [05:40] i'm going to send it out to the list [05:40] Okay. [05:41] I was only describing part of the merge process. [05:41] The other parts have the 'checkout' access pattern. [05:42] Making checkout as fast as it can be is definitely a goal. [05:42] oh :) [05:43] keir: The first part of merge is you find a base. Then you get three inventories and compare them. [05:43] three? [05:43] Then you get selected file texts from two of the inventories. [05:44] Yes, three: My tree, the tree I am merging, and the merge base tree. [05:45] ok [05:45] Oops, actually, you get selected file texts from *three* of the inventories. [05:47] and then you do a three-way merge? [05:47] Right. [05:48] Though if only one side changed the file, we take that side's version without doing the equivalent of diff3. [05:49] ok [05:51] abentley: note that I've already replaced knit indices with index.py; keir is working on a better implementation of index.py [05:51] lifeless: I know, but good point. [05:52] keir: It's nice that the generalised interface I crafted for bzr may be useful elsewhere, thats a good property. But the important thing to note is that that we are doing the work for bzr, so bzr's needs and process are paramount. [05:52] keir: nothing stops you later rewriting it to your hearts content :) [05:52] lifeless, i'm about 5 mins from sending out my design [05:52] re topo sort grouping [05:53] I would wager breadth first grouping is most suitable [05:53] keir: So in your version of the file graph, you will have different subgraphs, one for each file. [05:53] but if its parameterisable that would allow benchmarking [05:53] lifeless, well, it's easy to test different strategies; we just re-sort and benchmark [05:53] ok. back to the email. i'll be back in a sec [05:53] abentley: also are you aware that in packs the compression tree and the ancestry graph are decoupled ? [05:54] lifeless: I wasn't sure whether that was exposed. [05:54] abentley: so we can without changing the index format have arbitrary compression parents [05:54] abentley: its not somthing that knit.py is yet able to take advantage of, no. But it is exposed for folk that want to work directly on e.g. text_all_index for operations [05:55] s/format/logic/ two lines up [05:55] ok, I'm off again, drive by commenting done :) [05:56] hmm [05:56] keir: Because the checkout pattern requires fast access to a lot of recent versions of a lot of texts, you would probably want the sorting to pay attention to where snapshots happen. [05:56] So that it can switch files when it hits a snapshot. [05:58] so the fulltexts link back to previous revisions even though a checkout would stop at the fulltext? [05:59] Yes, AIUI. [05:59] In fact, the revision knit is all fulltexts. [05:59] Yet we can use its graph. [06:00] well, the revisions only store metadata not actual file content do they? [06:01] The XML you saw earlier is stored in the revisions knit the same way file texts are stored in file knits. [06:02] ok === hacklberry [n=hacklber@ppp167-251-99.static.internode.on.net] has joined #bzr [06:11] sent! === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] === Rotund [n=rotund@d28-101.rb2.lax.centurytel.net] has joined #bzr === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === hacklberry [n=hacklber@ppp167-251-99.static.internode.on.net] has joined #bzr === n2diy [n=darryl@wlk-barre-208-103-148-76.dynamic-dialup.coretel.net] has joined #bzr === sverrej [n=sverrej@tul-1x-dhcp016.studby.uio.no] has joined #bzr [07:59] we require python 2.4 right? === metze_food is now known as metze [08:05] keir: impressive post about Graphs to the mailing list the other day. [08:12] AfC thanks! [08:12] that was just a couple hours ago === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:24] keir: Some bits (maybe just tests) require 2.4. [08:24] keir: I assume it's mostly 2.3. [08:32] ok === tca [n=tom@ti541110a080-5238.bb.online.no] has joined #bzr === g0ph3r [n=g0ph3r@p57A0AA22.dip0.t-ipconnect.de] has joined #bzr === sverrej_ [n=sverrej@tul-1x-dhcp017.studby.uio.no] has joined #bzr === sverrej_ [n=sverrej@tul-1x-dhcp017.studby.uio.no] has joined #bzr === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr === ieei [n=ieei@62.70.2.252] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [09:40] Peng: afraid not. [09:40] keir: 2.4 is a hard requirements. === asabil [n=asabil@ti0035a340-0802.bb.online.no] has joined #bzr [10:02] dato: Oh, really? Okay. === mvo [n=egon@p54A677A5.dip.t-dialin.net] has joined #bzr [10:22] night all [10:23] Peng: yeah :) === Zindar [n=erik@host217-42-238-84.range217-42.btcentralplus.com] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === gabe_ [n=gabriel@91.84.56.254] has joined #bzr === asabil [n=asabil@62.70.2.252] has joined #bzr === tca [n=tom@ti541110a080-5238.bb.online.no] has left #bzr [] === pygi [n=mario@83-131-74-255.adsl.net.t-com.hr] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === luks [i=lukas@unaffiliated/luks] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr === jnair [n=jayesh@203.123.188.10] has joined #bzr === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === metze is now known as metze_food === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr [01:46] running `bzr upgrade` in a lightweight checkout makes a backup of the light .bzr, not of the real .bzr. would that be considered a bug? === metze_food is now known as metze [01:50] no, because its upgrading the lightweight checkout [01:51] but it changes the "remote" branch as well [01:51] ok thats a bu [01:51] bug [01:51] it should only alter the lightweight checkout === sverrej [n=sverrej@213.236.208.247] has joined #bzr [01:52] okay, I'll double-check it does that, and file one [01:53] lifeless: It would be nice to have a bit more API for handing branch references. [01:53] yea [01:53] "bzr switch" has some pretty gross aspects. === mrevell is now known as mrevell-lunch === Rotund [n=rotund@d28-101.rb2.lax.centurytel.net] has joined #bzr === matkor [n=matkor@beauty.ant.gliwice.pl] has joined #bzr === mw|out [n=mw@189.146.24.28] has joined #bzr === ddaa [n=david@canonical/launchpad/ddaa] has joined #bzr === asabil [n=asabil@62.70.2.252] has joined #bzr === mrevell-lunch is now known as mrevell === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr [03:29] Is the Cygwin client broken? === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has left #bzr ["Leaving"] === sverrej_ [n=sverrej@213.236.208.247] has joined #bzr === sverrej [n=sverrej@213.236.208.247] has joined #bzr [03:40] New bug: #137976 in bzr "`bzr upgrade` in a lightweight checkout upgrades the parent branch" [Undecided,New] https://launchpad.net/bugs/137976 [03:41] er [03:41] oh right === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === pygi [n=mario@83-131-73-161.adsl.net.t-com.hr] has joined #bzr [04:09] hello folks [04:10] joe99: not AFAIK === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === mw|out is now known as mw === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === BasicOSX [n=Basic@fortress.tanners.org] has joined #bzr === matkor [n=matkor@beauty.ant.gliwice.pl] has joined #bzr === alfborge [n=alfborge@bacchus.pvv.ntnu.no] has joined #bzr [04:43] I've been using bzr for my module of a project for some time now, and finally the project as a whole has adopted bzr. Is there a way I can merge my existing bzr repos with the project repos so that I keep my history? [04:43] I've got an existing Products/Timeline/.bzr which is the one I've been using. [04:44] Now there's a .bzr in Products... [04:45] alfborge: yeah, there is, it might be in a plugin === radix tries to remember the command [04:47] hrmph [04:48] I can't find it :\ [04:49] Me neither. [04:49] I think jam wrote it, but I guess he's not around. [04:54] join Combine a subtree into its containing tree.' [04:54] Might be it. [04:57] I don't really understand the helptext to join. Could someone take a look at it and help me out? [04:58] Seems I need to create a branch and then join into this branch. But it's not really clear to me exactly how to go about it, and where I should run the commands from (the target tree or the source tree) and so on. [04:59] alfborge: I don't think join is the one I used [05:00] alfborge: to be clear, you have two branches and you want to merge them into one, such that all the files in one are in a directory of the other? [05:01] I'm not really very familiar with bzr. I did "bzr init" on the part of a code tree that I've been working on. [05:01]