=== mw is now known as mw|out [00:17] abentley: pon [00:18] So I started hacking on per-file base selection yesterday, and I found a locality-of-reference problem. [00:18] ok [00:18] The file content is stored in the versionedfile. The file type is stored in the inventory. [00:19] So to do it absolutely correctly, I'd have to retrieve all the trees for the selected revisions. [00:20] Because the selected revision may not be a file-- it may be a directory, symlink or tree reference. [00:21] ok [00:21] I see [00:21] now, if the kind is the same on both tips [00:21] does that make it easier ? [00:21] In fact, we're already assuming it's a file on both tips. Otherwise, we wouldn't need a base at all. [00:22] so if its the same on both tips [00:22] 3-way merge says that if the base is a different kind [00:22] -> we'd treat is as empty of the same kind ? [00:23] Not quite. We'd still emit foo.BASE in the correct kind. But wrt the file merge, yes. [00:24] now symlinks and dirs have an existing empty text for their revisions [00:25] AFAIK, correct. [00:25] So we can shortcut the kind check 99% of the time. [00:25] so; and I realise this is hacky; [00:26] if doing a 3-way custom base on two currently-file-texts, w.get_lines(custom_base) will give us [] when the kind has changed. [00:27] I hate to have it shortcutted 99% of the time, though. It makes me fear the full path won't get adequately tested. [00:27] are you doing custom bases for symlinks and dirs too? [00:28] No. Those will get handled by the standard merger, which also handles inventory issues such as renames and executability. [00:29] I don't think those things change enough to require the same care as text files. [00:30] so I guess I'm saying; if we're only doing custom base on (text, text) pairs; and get_lines(custom_base) will always return a suitable set of lines, ([] when the common base has a different kind), then its not a shutcut situation [00:31] By shortcut, I mean that we're avoiding retrieving the file kind from the relevant inventory. [00:31] But in the case where it's [], we will have to do so. [00:32] I don't see that we ever need the file kind for the base if the parents are both texts; other than to write foo.BASE. [00:32] Right. But we will have to write foo.BASE. [00:32] ok [00:32] so lets look at that [00:32] we write foo.BASE when we ended up doing a merge right [00:33] Right. [00:33] now, will we avoid doing 'merges' sometimes with custom file bases ? [00:34] No, but if the BASE is not a file, we will do a two-way merge between THIS and OTHER. [00:34] which is where [] is useful because it's just a clean degradde. [00:35] A clean what? [00:35] degrade [00:35] it's what 3-way degrades too [00:35] Okay. [00:35] hmm, one sec local interrupt [00:39] back [00:40] wondering if we will ever get base == left or base == right with custom merge bases [00:40] I think we can [00:40] consider this [00:41] at the graph level we have two lca's [00:41] so we recurse [00:41] its easy then for at the file level for one side to be purely an extension of the other for a single file [00:41] so when we are considering that single file we'll not need to merge at all [00:42] I'm going to think out lout now [00:42] and enumerate what I think the possible cases are [00:43] * Base is one side (common I suspect in criss-cross merges; many files won't be actually unmerges) [00:43] * Base is the revision the graph level base had [00:44] * Base is another inventory [00:44] s/another inventory/from &/ [00:44] done [00:54] abentley: ^ === josep17 is now known as linuxpararato === linuxpararato is now known as josep17 [01:03] buenas noches [01:03] desde venezuela [02:24] lifeless: I would expect base==left or base==right to be rare. But I would imagine we can get it. I'm not sure why it matters. [02:25] We need a general solution. [02:27] Sure, I can hack up something gross to do per-file bases, but I think you ought to consider how an upcoming repo format could give us cheap access to file kind, symlink target, and maybe execute bit. [02:27] Right now, I'm re-implementing annotate merge, and it's going swimmingly. [02:50] dato: resubmitting bzr-svn fixed it [02:50] dato: your upload of 0.4.4-2 hadn't been processed yet, apparently [03:19] jelmer: Have you noticed that the bzr-gtk test suite is completely borked if run as part of the bazaar test suite? [03:25] abentley: I'm pretty sure I hit it all the time. [03:25] abentley: anyhow, our current format can give use kind/target/execute quite cheaply [03:25] abentley: just use the same parse-a-delta-fragment logic. [03:27] Oy. Can't we do up a format where that works by design instead of being a tremendous hack? [03:28] abentley: yes, both the ones poolie and I have been fiddling/mailing about will work by design [03:29] Awesome. [03:29] abentley: but they largely formalise useful properties we have been able to leverage from the current format. [03:30] abentley: I have been thinking that content object information should be pushed down to the per file graph anyhow; as metadata on the node [03:32] Well, I know the new format will do comparisons much faster, but that sounds like it would slow them down. [03:42] abentley: I'm thinking some duplication actually [03:42] abentley: but also there is locality of data possibilities. [03:42] abentley: this would be a 2nd or 3rd iteration out. [03:42] abentley: one possibility is: [03:42] Oh, by "pushing down", I thought you'd be taking it out of the inventory. [03:43] kind + exec + content in the 'knit' [03:47] inventory has parent + name + pointer to the knit version [03:47] 'knit' index can pull kind + exec into it. [03:48] abentley: the open things in my mind about whether this makes sense are what datum we actually need at the same time [03:50] For our tree-manipulation functions, we generally use inventory and file texts simultaneously. [03:51] When building a tree, to create a file, we need file_id, name, parent, kind, execute bit, and content basically simultaneously. [03:52] That's not a hard requirement. TreeTransform could work efficiently if you learned names, parents and file-ids in one pass, and everything else in a second pass. [03:58] abentley: so its the case of status/diff when the last-mod is different and the value is the same that would be hurt [03:58] abentley: -> how common is that [03:58] (assuming we don't want false positives for st [03:59] another possibility here though is to decouple the metadata graph from the content graph [03:59] This is assuming we're not diffing against a DirstateRevisionTree? [03:59] right [03:59] So we wouldn't have the md5sum in the inventory? [04:00] so you'd have (fileid, parentid, name, content-pointer[revid, validator]) as a graph [04:00] and (kind, exec, content) as a graph [04:00] I'm not sure at all how common that is. Merges can produce it, though. [04:00] you'd have a sha1, but not of the lines, of the lines & kind and exec bit [04:01] this would for instance, allow us to start only storing one copy of 'COPYING' etc, depending on how we want to take it. [04:01] this is all still wildly speculative [04:01] I don't think kind is a big concern. If it changes, we definitely need to get all the data. [04:03] I dunno, though. I think having all the data in the inventory might well be a win. [04:04] I'd like to be in a position to experiment [04:04] Just because there are many operations that just want to know which files changed. [04:04] write some arbitrary benchmarks outside bzr that simulate access patterns and the like [04:06] maybe this is something we can reason about in march [04:17] Also, some stats on real trees might help us answer these questions about what's common better. [04:27] abentley: indeed. So having an analyser that can report what a transformed tree would look like would be good [04:28] I'm not sure what you have in mind. The PreviewTree thing? [04:28] nah [04:28] just a script to take a branch [04:29] and break it out into the things I'm talking about, without doing disk transformations, just in-memory, and report [04:30] Oh, to simulate a changed repo format? [04:30] right [04:50] lifeless: what breaks about it? [04:50] s/lifeless/abentley/ [04:51] ah, I see [05:16] meh [05:16] sorry about disappearing; what did I not respond to [05:16] ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [05:16] 05:03:21 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has quit [Read error: 113 (No route to host)] [05:16] 05:15:45 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr [05:16] Oops, got the trackbar. [05:17] But yeah, nothing. :p [05:17] thanks === n2diy_ is now known as n2diy [08:07] hello, I'm considering using bazaar for a project of mine... we're using subversion right now, because subversion is offered on Google Code, and Gna! (http://gna.org). Are there any free repository hosts that our GPL program can use (using bazaar)? [08:08] alecwh, sure, https://launchpad.net/ [08:08] it also works as a bug tracker [08:09] (and a bunch of other stuff) [08:09] no way... it hosts a free bazaar repository? that's awesome. [08:10] how do I set it up? [08:10] https://code.launchpad.net/phpns/ [08:10] This is our project [08:10] Register branch? [08:17] alecwh, let me fetch you a how-to real quick [08:17] Hmm. I just started using LP a bit. I should look into the launchpad plugin. [08:18] alecwh, https://help.launchpad.net/FeatureHighlights/BazaarHosting might help a bit [08:19] but you basically just push to the right address with bzr [08:19] and the branch gets created [08:19] the folks at #launchpad might be able to give you more details though [08:20] it's a bit over 5am here, so I'm going to bed [08:20] good luck :D [08:21] ok, thanks a lot bueno. ;_ [08:21] ;) [08:23] Might be even simpler using lp: URIs. [09:19] New Pyrex release. [09:32] How do I import a subversion repository into a bazaar repository? [09:33] alecwh: You could use bzr-svn. [09:34] what does that do? [09:34] alecwh: bzr-svn can even allow pushing from bzr to svn. It's pretty neat. [09:34] alecwh: Well, for one thing, it imports svn repos into bzr repos. [09:34] yeah, that's what I'm looking for. =D [09:34] how does that look like? [09:34] the bash command. [09:35] Not sure. [09:35] "bzr branch" might do it. [09:35] Read the docs. [09:35] ok, thanks Peng. =) [09:47] alecwh: www.bazaar-vcs.org/svn IIRC [09:47] This page does not exist yet. You can create a new empty page, or use one of the page templates. [09:47] lifeless: I got that error. [09:48] alecwh: there is a link on it [09:48] alecwh: to BzrSvn :) [09:48] ok, thanks lifeless. I'll read over it. [09:50] Hey there [09:50] Tried to get things working with olive, but no dice/ [09:50] hey JordanC. =D [09:52] JordanC: Define 'no dice'. :p [09:53] Odd_Bloke: It didn't work. [09:53] Yeah, I got that much. :p I was hoping for something a little for specific. :D [09:53] s/for/more/ [09:55] I came in here a while back, and yeah [09:55] JordanC: Are you using Olive or bzr-gtk? [09:55] I spoke to some developers, and they said that because of the SSH factor, I can't connect to launchpad using olive [09:55] Ah, OK. [09:55] Have you looked at QBzr? [09:56] Hmm, lesee [09:56] KDE Bazaar proggy? [09:57] JordanC: http://bazaar-vcs.org/QBzr [09:57] no, in two ways [09:57] Qt, not KDE. [09:57] not a program, not kde [09:57] Damnit === kiko-zzz is now known as kiko [13:01] yo [13:01] is there a way to get more easy to parse output from bzr ? [13:02] (im parsing the status output for an ide, an its really tricky to get it together atm) [13:22] ronny: There's an xmloutput plugin, I believe. [13:22] ronny: https://edge.launchpad.net/bzr-xmloutput [13:22] ronny: Which IDE were you thinking of? [13:22] luks: I'm looking at your patch more carefully now. [13:23] thanks :) [13:23] I think a nicer way to extract the name would be to have a pattern that only matches if there's "name ", and if it fails to match, just return the original string. [13:24] Odd_Bloke: pida [13:24] well, I think returning "email" from short_author is better than "" [13:25] unless you want to match "(name )?", which is exactly what the patch does [13:25] I think that's highly unlikely. [13:25] Odd_Bloke: right now we parse the command output, cause the subsystem for python-api based vcs tools is basically nonexistant [13:26] abentley, "" is the use case from the bug report [13:27] the bad thig is - we get wrong data sometimes, but cant figure the exact source, cause the bzr output aint nice to parse (so the parser is tricky) [13:27] Also, I don't know if lazy_regex was meant to be used in new code. [13:27] I thought it was just to make existing code faster. [13:28] And I really doubt there's a performance win by using it. [13:29] but what's the point of compiling a regular expession you are not going to use [13:29] sure, it's not a big win, but there is a lot of small things like this [13:29] There's no win, there's loss in compiling a regular expresion. I was talking about not compiling at all. [13:30] hm? you mean parsing the string manually? [13:31] no, just using re.match [13:31] that compiles it every time you use it [13:31] Right. [13:31] so about 3k times for log on bzr [13:32] actually its cached [13:32] luks: I really doubt that performance difference is observable. [13:33] the more often a re is used, the more sense it makes just to compile it [13:34] but the difference is only small, cause all re's u use are cached in re._cache [13:37] abentley, I mean, bzrlib already has code to delay regex compilation, pre-compiled regex is faster than re.match, there is a patch that use it -- why make is slower? even if the difference is small [13:37] Because it's clearer to just write re.match [13:38] Takes fewer lines. Doesn't require people to grok lazy_regex. [13:38] hmm - how does lazy_regex work ? [13:39] compiles the regex when it's first used [13:40] *first time [13:40] im more intrested how the store works [13:40] cause i doubt it has any notable gain compared to re.match [13:42] ronny: It allows the "lazy_compiled" patterns to be substituted for really compiled patterns-- that's what it's for. [13:42] So you can fix import slowness without rewriting the module. [13:43] "import slowness" ? [13:43] regexes that compile at import time reduce cause latency problems for programs like Bazaar. [13:44] You run bzr, it imports a whole bunch of modules, they compile a whole bunch of regexes, and then, finally, it starts doing what you asked. [13:45] hmm - why do you guys need so many regexes ? [13:45] The libraries we import need them. [13:47] (well, they *have* them. *need* is debatable) [13:47] btw - any timeframe when bzr will be as fast as hg ? [13:47] For example ConfigObj has regexes that produce a noticeable compile delay. [13:48] ronny: It depends what you're talking about. With the packs format, commit speed is pretty similar. With the smart server, pull time is similar. [13:49] status has been comparable for some time now. [13:50] ah - so its mostly cause bzr has tonns of other operation modes ? [13:50] Well, it depends what operation you want to speed up. [13:51] all i care for is fast sync and fast commit [13:51] I think 1.0 will give you that. [13:52] hmm - i didnt exactly use bzr for quite some time [13:53] does it still try hide the existence of multiple heads (for example by allways enforcing merges) [13:53] I think we've got the pieces in place to support good performance for most commands. [13:53] I don't know what you mean by hiding the existence of multiple heads. [13:54] But in some cases, the commands must be updated to take advantage of them. [13:54] last time i used it it dodnt allowme to hae multiple heads in my repo [13:55] Repositories typically have many heads due to people uncommitting revisions. [13:55] But we don't have multiple heads for a single branch. Instead we allow multiple branches per repository. [13:56] hmmk - thats a problem for me [13:56] Why? [13:58] enforces me to split one semantical branch into multiple branches if more than one person is working on that [13:58] No, they can use heavyweight checkouts. [13:58] ronny: That's what you're doing with multiple heads anyways... [13:58] That lets them commit locally. [13:59] And then sync up with the main branch when they're ready. [13:59] damn - how many modes of operation does bzr have ???? [14:00] We support a range from svn-like to fully distributed. [14:00] hmm - having too many choices tends to be confusing [14:04] Well, we have three: a "tree" has a branch and working copy at the same location. A "heavyweight checkout" has a branch in one location and the working copy is at different location, but has a local copy of the branch to act as cache. A lightweight checkout is like a heavyweight checkout with no local cache. === kiko is now known as kiko-afk === mwhudson_ is now known as mwhudson === aosida is now known as iSoron [19:28] I just created a bazaar branch at launchpad (https://code.launchpad.net/~alecwh/phpns/devel), and now I want to upload my project (which is in /var/www/devel) to the repository. In the terminal, my working directory is /var/www/devel, and I gave the command: bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel , but it doesn't seem to be working. I get the error: bzr: ERROR: Not a branch: /var/www/devel/ , can anyone help me upload [19:29] cd /var/www/devel; bzr init; bzr add; (check if it added only files you want); bzr commit [19:30] and then you can use bzr push [19:30] http://doc.bazaar-vcs.org/bzr.0.92/en/mini-tutorial/index.html#putting-files-under-version-control [19:31] ok, I'll try that. will 'bzr add' add every single directory and file inside /var/www/devel? [19:31] moin [19:31] moin? [19:35] alecwh: yes, add adds recursively, obeying your ignore rules [19:36] thanks lifeless. I've got one more question: when I was using svn, every 'commit' you made actually uploaded your changes to the online repository. Is this not the case with bazaar? [19:37] alecwh: if you have a checkout it acts like svn [19:38] a checkout? [19:38] alecwh: that is, if you do 'bzr checkout bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel local-dir-name' [19:38] then you can cd local-dir-name, and do [19:38] that will download the project, right? [19:38] 'bzr commit', which will commit back to bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, just like svn [19:38] oh. [19:39] alecwh, or, when you want to send all your commits, just use "bzr push" [19:39] alecwh: if you have a separate 'branch' though, then your commits are performed just on your machine [19:39] ok, that makes sense. [19:39] https://code.launchpad.net/~alecwh/phpns/devel [19:39] (when using branches instead of checkouts) [19:39] I just finished uploading everything... [19:39] alecwh: and then when you want them to be in bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, you do 'bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel' (bzr will remember the push location the first time, so you don't need to type it every time0 [19:40] how do I make it so every time I 'commit' it will update this repository? [19:40] alecwh: bzr bind bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel [19:40] ok lifeless, that worked. =D [19:41] I was using 'cia.vc', which puts a bot inside your channel on freenode, and then it will post a message inside the channel whenever a commit/change is made. Is there something like this for bazaar? [19:42] alecwh: there is a plugin for bzr to announce to cia [19:42] alecwh: you can also subscribe to the branches on launchpad [19:42] alecwh: or install bzr-email to send emails to arbitrary email address's on commits [19:43] ok, cool. Do you know what the plugin was called? I'm just looking for it... [19:44] http://www.google.com/search?q=bzr+cia&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a [19:44] 3rd and 4th hits look relevant to me [19:46] https://launchpad.net/bzr-cia [19:50] lifeless, uhm, how do I get the plugin? =P [19:51] alecwh, with bzr, of course :D [19:52] https://code.launchpad.net/~jelmer/bzr-cia/main [19:52] is this the one I'm looking for? [19:52] alecwh, yeap [19:52] bzr branch http://bazaar.launchpad.net/~jelmer/bzr-cia/main? [19:52] use that command? [19:53] alecwh, yeah, you download it with that command [19:53] ok, done. =D [19:53] I think I got it now [19:53] now, follow the instructions in: https://launchpad.net/bzr-cia === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as turbo0O === turbo0O is now known as me_too === me_too is now known as too_short === too_short is now known as me_too === adib is now known as theAdib [22:17] success; we have a 1.0 build on dapper-amd64 [22:17] i386 testing now [22:17] brb foodstuff time === mwhudson_ is now known as mwhudson [22:34] jelmer: very well [22:35] jelmer: btw, I guess there is no way to convert from svn a trunk and a branch, if I somehow say which revisions from the trunk are merges from the branch, right? [22:40] dato: only if you can go back in history and set some magic svn properties [22:40] jelmer: can I a dump of the repository, load it locally, set the properties there, and redump? that ought to work? [22:42] dato: yes, but you would want to change the uuid [22:42] ok. is there a document explaining what properties I should set? [22:43] and pulling from the original in the future may be problematic [22:43] http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping [22:46] basically, you'd want to set the bzr:ancestry:vX-SCHEME property [22:47] dato: is it really worth doing? why not just do a merge after the conversion? [22:47] jelmer: it's a one-time conversion [22:48] lifeless: I seem to find a strange pleasure fiddling with the tools. [22:49] dato: :) [22:53] jelmer: ok, thanks for the link. I'll try to do it. also, I svn-import trunk didn't work for me yesterday, but the packaged version worked fine. I'll try again tomorrow. finally ;), changing the UUID is just a matter of editing the dumpfile by hand, or? [23:08] dato: the trunk branch for bzr-svn is highly experimental [23:08] dato: 0.4 is the branch that is packaged [23:09] dato: yep, editing the dumpfile should be all that's needed to change the uuid [23:09] lifeless: What do you consider a good way to decide if something should be a separate module or not? [23:11] I was expecting plan_merge to be bigger than it is, which is why I originally did it. [23:11] abentley: I don't have a good rule; sometimes I get there and combine; sometimes I start in the same module and split. [23:13] wtf ? test_revision.TestIsAncestor.test_is_ancestor is failing just under the comment: [23:13] # NB: if you see an assertion error here, its probably access against [23:13] # an unlocked repo. Naughty. [23:13] I guess by analogy, I'd think if merge3 has its own module, then annotate merge can have one, too. [23:14] the problem is I'm working on http response parsing rewrite and I can't find any link >-/ [23:15] Worse, the same test on bzr.dev@3059 fails too, midnight bug ? [23:16] and on top of that, I see (when doing bzr missing in my bzr.dev branch) revno: 3061, deprecate bzrlib.revision.is_ancestor [23:18] Ran 9939 tests in 437.020s [23:18] FAILED (failures=1, known_failure_count=5) [23:19] bah, time to sleep anyway, a bit frustrating though [23:21] not failing anymore in bzr.dev@3065... at least.... [23:27] jelmer: where is bzr-gtk for 1.0 ? [23:30] abentley: oh it can have one if you think it should; I was asking the question. [23:31] Sure, and I've actually decided to move them into versionedfile and merge. [23:31] Just because there's so much related stuff in those modules. [23:49] lifeless: phanatic is doing release management these days, I'll ping him by email