| dOxxx | good evening | 00:05 |
|---|---|---|
| poolie | lifeless, could you please aswer https://answers.edge.launchpad.net/bzr/+question/105503 | 00:18 |
| poolie | spiv, hi | 00:25 |
| poolie | spiv, is there a bug tag for per-file merge configuration? maybe there should be | 00:25 |
| igc | morning | 00:28 |
| poolie | hi igc | 00:30 |
| dOxxx | poolie: any idea why bzrlib.urlutils doesn't use python's urlparse.urljoin but rather rolls its own? | 00:30 |
| poolie | not off hand | 00:33 |
| poolie | but most likely is that the python one is buggy, or was buggy in python2.4 | 00:34 |
| poolie | second most likely is that it should but doesn't | 00:34 |
| poolie | should use it but doesn't | 00:34 |
| poolie | there should be a comment either way | 00:34 |
| poolie | all, lifeless: what do you think of, in the context of <https://answers.edge.launchpad.net/bzr/+question/102562> just not repacking pack files that are already fairly large (say 500MB) | 00:34 |
| Peng | Maybe have an option for it? :D | 00:35 |
| * Peng ducks. | 00:35 | |
| poolie | yes, it would make sense to have an option with a default | 00:43 |
| poolie | igc do we still need to talk about the windows installer-building vm? | 00:45 |
| igc | poolie: yes | 00:46 |
| poolie | here or the phone? | 00:46 |
| igc | here's fine | 00:46 |
| poolie | so basically i suggest you make a snapshot using their web console | 00:46 |
| igc | poolie: I'd like to try building a 2.0.1 installer this morning | 00:46 |
| poolie | that would be great | 00:46 |
| igc | I still need to fix bug 534548 first | 00:47 |
| ubottu | Launchpad bug 534548 in bzr-windows-installers "Bzr Error: missing sqlite library" [Undecided,New] https://launchpad.net/bugs/534548 | 00:47 |
| igc | I'm working on that now | 00:47 |
| poolie | ok | 00:49 |
| poolie | so you were asking the other day if it's ok to reboot it | 00:49 |
| poolie | and aiui it's fine to reboot, but if you halt that instance will go away | 00:49 |
| poolie | and you will lose its state | 00:49 |
| igc | poolie: "halt?" | 00:51 |
| poolie | shutdow | 00:51 |
| poolie | shutdown* | 00:51 |
| igc | poolie: ok | 00:52 |
| dOxxx | poolie: re urlutils and why it doesn't use urlparse.urljoin, it seems that the python module doesn't throw errors and doesn't make it easy to detect when updir segments ('..') go above the root | 00:57 |
| dOxxx | for instance, urljoin('.', '..') produces '/' | 00:59 |
| dOxxx | sorry I meant urljoin('/', '..') | 00:59 |
| poolie | right | 01:00 |
| dOxxx | I'm wondering how important it is to detect that particular case | 01:01 |
| dOxxx | and apparently it doesn't like joining 'lp:foo' with 'bar'... it just produces 'bar', which breaks the appendpath stuff :P | 01:03 |
| dOxxx | perhaps I could use urlsplit and do my own join logic... | 01:04 |
| spiv | dOxxx: the chroot functionality at least depends on those errors | 01:08 |
| spiv | dOxxx: what are you trying to do, btw? :) | 01:08 |
| dOxxx | spiv: trying to fix bug 534787 | 01:08 |
| ubottu | Launchpad bug 534787 in bzr "pull does not understand lp: URLs in branch.conf" [Medium,In progress] https://launchpad.net/bugs/534787 | 01:08 |
| dOxxx | I already have a somewhat crude fix for it | 01:09 |
| dOxxx | but poolie suggested I fix the url joining instead | 01:09 |
| poolie | so i do think urljoin('lp:foo', 'bar') should give lp:foo/bar | 01:10 |
| spiv | Yeah, that would be good. | 01:10 |
| dOxxx | poolie: oh for sure. it just means I can't cop out just calling urlparse.urljoin ;) | 01:11 |
| spiv | I wonder if for this particular bug we ought to be doing the directory-service lookup before joining the relative dir to it? | 01:11 |
| spiv | Oh, btw, urlutils.join('lp:foo', 'bar') already gives lp:foo/bar | 01:11 |
| dOxxx | spiv: yes, I was referring to the python urljoin | 01:12 |
| spiv | Although by accident, I suspect :) | 01:12 |
| spiv | (Yep, by accident, compare urlutils.join('lp:foo', '../bar')) | 01:13 |
| dOxxx | ouch | 01:14 |
| dOxxx | yeah there are some pretty magical expectations of this function :P | 01:15 |
| spiv | The directory service concept hasn't really been fully integrated yet. | 01:18 |
| dOxxx | when I run bzr selftest, I get the errors and failures printed out twice... | 01:20 |
| dOxxx | the second time in a slightly different format | 01:21 |
| lifeless | poolie: we should repack large packs | 01:21 |
| poolie | in constant memory | 01:21 |
| SamB_XP_ | poolie: at most linear, anyways | 01:22 |
| poolie | um | 01:22 |
| SamB_XP_ | but yeah, constant is nice too | 01:22 |
| poolie | it's easy for people to get bigger pack files than will comfortably fit in ram | 01:23 |
| SamB_XP_ | true | 01:23 |
| poolie | so ok, it can be linear as long as a<1 | 01:23 |
| lifeless | poolie: thats fine, we don't buffer the pack on a repack | 01:23 |
| lifeless | memory use to repack is made up of: | 01:23 |
| SamB_XP_ | just ignore me | 01:23 |
| lifeless | - index data | 01:23 |
| lifeless | - current gc compressor state | 01:23 |
| lifeless | - read-cache from the source packs | 01:24 |
| lifeless | if someone is seeing a memory spike during a repack, its most like that they committed an ISO | 01:24 |
| lifeless | because of the forth element: | 01:24 |
| lifeless | - current object being inserted | 01:24 |
| SamB_XP_ | forth uses very little memory! | 01:24 |
| lifeless | oh, there is also a 1MB write buffer, but its approx constnat | 01:25 |
| lifeless | we expect packs to grow to many multiples of main memory | 01:25 |
| SamB_XP_ | so, yeah, that probably *is* linear with a<<1 | 01:26 |
| lifeless | that said, the main thing we want to do is combine packs to reduce linear lookup growth, a big pack with one commit in it is certainly something we could leave for a while, but thats a matter of tuning the 'what packs should we combine' to choose them a little later, rather than excluding large packs from that algorithm | 01:28 |
| poolie | lifeless: there have been a spate of out-of-memory during commit of small things | 01:47 |
| poolie | at least some are due to repacking | 01:47 |
| lifeless | poolie: due to, or occuring during | 01:48 |
| lifeless | ? | 01:48 |
| lifeless | poolie: because I don't think that that is the same thing at all | 01:48 |
| poolie | occurring during | 01:48 |
| lifeless | what that primarily says to me is that they probably don't have enough memory on their machine to work on that project - I'd expect random 'diff', 'log' and other commands to fail on that repository too | 01:50 |
| lifeless | though there may be a bug in the slab cache | 01:51 |
| lifeless | we may want to investigate that | 01:51 |
| lifeless | and related to that we might want to handle an OOM error by dropping all related caches and retryinh | 01:51 |
| poolie | yes, but that isn't what seems to be happening | 02:13 |
| poolie | (*) i have not systematically checked all the reports | 02:13 |
| lifeless | what seems to be happening then ? | 02:16 |
| lifeless | should we do voice for this; sems to be quite a drawn out conversation | 02:17 |
| dOxxx | seeya guys | 02:34 |
| poolie | lifeless: let's not bother until we actually start on it; it was just a random thought | 02:35 |
| quotemstr | Is there anything wrong with running, in a branch, bzr log -r ../trunk ? | 03:20 |
| quotemstr | Ah, I want bzr log -rancestor:../trunk right? | 03:21 |
| spiv | quotemstr: yeah, probably | 03:21 |
| spiv | Or perhaps "bzr missing --mine ../trunk" | 03:21 |
| quotemstr | Thanks! | 03:21 |
| spiv | Or maybe "bzr log -rsubmit:" will do the same thing for you with less typing :) | 03:22 |
| spiv | (if ../trunk is the submit branch) | 03:22 |
| quotemstr | Ah, I see. Is it normal for that to print out just one commit? | 03:23 |
| spiv | Well, if there's just one commit in your branch that isn't in ../trunk, then yes. | 03:23 |
| quotemstr | Ah! .. :-) | 03:24 |
| fullermd | Yes, because you're only asking for one rev. If you want a range, you want to say a range (e.g., "-rsubmit:..") | 03:24 |
| quotemstr | -rsubmit.., that is. | 03:24 |
| spiv | Oh, right. | 03:24 |
| spiv | My bad :) | 03:24 |
| fullermd | (which is short for -rsubmit:..-1) | 03:24 |
| quotemstr | Hrm, it's still running. | 03:26 |
| quotemstr | Okay, this is getting more complicated than I thought. I have a branch that's a little stale with respect to the trunk. I've done some feature development on it, but also backed out a change from the trunk that was causing a bug. In the log, that backing-out is marked as a merge. To merge from the latest trunk, I need to undo that backing-out of the bug so the trunk's bugfix will apply correctly. | 03:30 |
| quotemstr | So how do I undo that particular entry? I don't see any functionality in bzr merge for unmerging, as it were. | 03:30 |
| spiv | quotemstr: you can pass a backwards revisionspec to merge | 03:32 |
| quotemstr | Right, but the revisions are with respect to the trunk I'm trying to merge from. | 03:33 |
| spiv | quotemstr: e.g. "bzr merge -r 101..100 ." will reverse the changes in revision 101 | 03:33 |
| Peng | If you merged revisions, they're in the local branch too, even if "bzr log" collapses them by default. | 03:33 |
| spiv | quotemstr: so the situation is that at some point you did "bzr merge ../trunk; bzr revert [some files]; bzr commit" on this branch? | 03:34 |
| quotemstr | spiv: Exactly. The changelog for the commit after the revert is "revert cc-mode breakage from revision 98938" :-) | 03:35 |
| quotemstr | spiv: But there are lots of changes I made after that revert. | 03:35 |
| spiv | Right. | 03:35 |
| quotemstr | Should I just manually grab a diff from the trunk, apply it with patch(1), then commit that? | 03:35 |
| spiv | Hmm, perhaps a second branch would be easiest: | 03:35 |
| quotemstr | (For revision 98938, that is.) | 03:35 |
| spiv | bzr branch -r [just-before-back-out] . ../before-back-out; cd ../before-back-out; bzr merge ../trunk; bzr commit -m 'merge trunk'; bzr merge -r [back-out-rev] ../feature; bzr revert .; bzr ci -m "Undo backout"; cd ../feature; bzr merge ../before-back-out; bzr ci -m "Un-revert cc-mode breakage from revision 98938." | 03:39 |
| spiv | There's probably a less convoluted way to do that. :) | 03:39 |
| fullermd | First, you fast-export and import it into monotone... | 03:40 |
| spiv | fullermd: hah | 03:40 |
| fullermd | Having update -r in base now, it's probably conceivable that a commit-daggy could be implemented as a plugin. Would only really work for single-commit fixes, but... | 03:41 |
| spiv | Hmm, maybe could use shelve rather than a second branch, something like "bzr up -r [before-back-out]; bzr merge ../trunk; bzr shelve --all; bzr up; bzr unshelve" | 03:41 |
| quotemstr | Wouldn't that re-apply the backing-out of revision 98938? | 03:42 |
| spiv | Maybe I'm being overly general... | 03:43 |
| spiv | Is it literally that you wish to reapply the changes in trunk -r98938? | 03:44 |
| spiv | If so, just "bzr merge -c98938 ../trunk" would work, I think. | 03:44 |
| verterok | hi! I would really appreaciate some help with a 'log' (actually a xmllog) test :) | 03:44 |
| quotemstr | Ideally in a way that will make the revision disappear from history, but that works too. | 03:44 |
| spiv | To make revisions disappear from history you'd need to generate a new history (e.g. using the bzr-rewrite plugin) | 03:45 |
| quotemstr | Scratch that then. I'll try merge -c. :-) | 03:45 |
| spiv | verterok: tell us more! :) | 03:46 |
| verterok | spiv: :) I would like to create the history specified in this bug: https://bugs.edge.launchpad.net/bzr-xmloutput/+bug/517937 | 03:46 |
| ubottu | Ubuntu bug 517937 in bzr-xmloutput "bad XML in fringe case" [High,Confirmed] | 03:46 |
| lifeless | branch builder | 03:47 |
| quotemstr | Hrm, all that does is say that it modified a ChangeLog, and even that is an empty diff. | 03:47 |
| quotemstr | I'll try the separate branch approach. | 03:47 |
| verterok | lifeless: ooh, nice! (xmloutput log tests are quite outdated) | 03:48 |
| poolie | igc, so is everything good on desolation now? | 04:09 |
| quotemstr | Anyway, merge -c worked fine. | 04:23 |
| quotemstr | I just had to specify [backout-revision] instead of the original revision from the trunk. | 04:23 |
| igc | hi poolie | 05:33 |
| poolie | hi there | 05:45 |
| igc | poolie: I've build a 2.1.1 installer that I'm downloading and testing | 05:52 |
| igc | built | 05:52 |
| igc | poolie: next on the list is to build a 2.0.5 installer set | 05:52 |
| igc | poolie: then it's back to sorting out the new build scripts and working out why buildout is grumbling about stuff | 05:54 |
| === quotemstr_ is now known as quotemstr | ||
| vila | hi all ! | 07:11 |
| MvG | Are help topics expected to be restructured text? | 08:36 |
| lifeless | MvG: yes | 09:40 |
| MvG | I found out that the command line output has plain=True unconditionally, which might cause some reformatting, which might explain why "bzr help configuration | rst2html.py" may result in errors, I guess. | 09:41 |
| lifeless | I wouldn't expect bzr help configuration | rst2html.py to work | 09:43 |
| MvG | I did, because the thing looked close enough to rst, but seeing that there is a a plain argument to the help text formatting method, I'm not surprised any more. | 09:45 |
| MvG | I wonder whether a --rst option to bzr help might be a good thing, though. | 09:45 |
| MvG | And a "export to temporary html and open in browser" as well, while we are at it. | 09:45 |
| MvG | The latter could be a plugin, though. | 09:45 |
| === LenZGr is now known as LenZ | ||
| * xnox gcc svn trunk import on launchpad 98077 out of 99076 revisions done =) can't wait | 11:21 | |
| ubottu | Launchpad bug 98077 in zope3 "No title ?fixme?" [Medium,Invalid] https://launchpad.net/bugs/98077 | 11:21 |
| xnox | ubottu, you are being silly =) | 11:22 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 11:22 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| meoblast001 | hi | 15:07 |
| meoblast001 | how do you use fast-export to strip a directory and its files from a tree? | 15:07 |
| meoblast001 | i tried bzr fast-export ./ | bzr fast-import-filter -x plugins/ > ../cnitrobot.fi but i got a broken pipe error | 15:22 |
| edgimar | can someone explain the pull --remember option? I tried doing 'bzr pull' recently from a repo which I had previously checked out via 'bzr checkout --lightweight URL', and I was given an error "Not a branch: PATH" where PATH was something I had not set. Doesn't it make sense to use URL as the path automatically? | 15:46 |
| edgimar | (PATH pointed to some local directory on another person's computer) | 15:47 |
| fullermd | If you're in a checkout, pull probably isn't what you want to do. | 15:47 |
| edgimar | So my question: how does it all work? what is the logic behind requiring --remember? | 15:47 |
| edgimar | fullermd, what should I have done? | 15:48 |
| fullermd | You probably want 'update'. | 15:48 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| edgimar | and update will pull the latest changes from the remote repository? | 15:48 |
| fullermd | Pull is for updating the branch. The branch in this case is that thing you checked out, so 'pull' is using the saved parent from it, which probably doesn't make sense when interpreted from your machine. | 15:48 |
| edgimar | I think it might just be a terminology problem for me -- in mercurial, "update" is just a local operation which changes the revision of the working directory -- what is the equiv in bzr? | 15:49 |
| fullermd | Same thing. | 15:49 |
| fullermd | That's what you're trying to do; update your working directory to match the branch. | 15:50 |
| edgimar | What I mean by 'local operation' is that there is no network activity required at all. | 15:50 |
| fullermd | There would be if the branch were across the network. | 15:51 |
| fullermd | But mercurial doesn't swing that way. bzr can, when you ask it to (which you did) | 15:51 |
| edgimar | Ok -- so the branch in bzr can be stored locally or remotely, I take it? | 15:51 |
| fullermd | In bzr, your working tree, branch, and repository can each be in [at least somewhat] arbitrary locations relative to each other. | 15:52 |
| fullermd | In your case, you did a checkout, so all you have locally is a working tree; you don't have a local branch. | 15:52 |
| edgimar | So, working tree= a directory corresponding to 1 revision. | 15:54 |
| fullermd | I guess that would be one way of saying it. Working tree == the files you fiddle with. | 15:54 |
| edgimar | But I'm confused if branches and repositories are somehow distinct from each other -- I figured that after you've specified a repository, then that intrinsically includes the branches associated with that repository ? | 15:55 |
| edgimar | (specified the location of a repo) | 15:56 |
| fullermd | Not really. You almost never talk about a repo directly; you talk about a branch. | 15:56 |
| === salgado is now known as salgado-lunch | ||
| edgimar | then what technically is a repository (or how does it differ from a branch)? | 15:56 |
| edgimar | (or relate to a branch) | 15:57 |
| fullermd | A repository is what stores revisions. A branch defines a set of revisions interesting in a particular context (i.e., a "line of development") | 15:57 |
| fullermd | It's useful to separate the two concepts because you often have multiple branches that share [some,most,all] history, and if the repo couldn't be considered independently, you'd be storing multiple copies of that. | 15:58 |
| * fullermd really needs to knuckle down and polish his docs on the matter :( | 15:59 | |
| fullermd | <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/core_concepts.html> gives some overview. | 16:00 |
| edgimar | right- from mercurial, I get the concept of branches. While it is possible to clone a specific branch of a hg repository, oftentimes one clones the entire repository and can then work on whatever branch one pleases. | 16:00 |
| edgimar | But in bzr, it's not possible to clone an entire repo? Or people usually just clone / checkout branches? | 16:01 |
| fullermd | I'm fuzzy on mercurial. It seems like they sorta use clones as branches, except when they use named heads as branches, except... | 16:01 |
| fullermd | But no, aside from making them and occasional special things, you never address or talk about repositories directly in bzr. | 16:02 |
| fullermd | You just talk about branches, and a branch finds its repository (either internally private, or externally shared) as necessary. | 16:02 |
| fullermd | bzr's "clone" command is just an alias of "branch". | 16:03 |
| edgimar | fullermd, ok- so when you do 'bzr branch' it duplicates a branch (the associated history of a branch). But when you do 'bzr checkout', it just gets a specific revision, and an associated branch-name/source is somehow connected with the checkout? | 16:13 |
| === deryck is now known as deryck[lunch] | ||
| fullermd | Mmm. That's... that's probably not _wrong_ per se, but I think it's a wildly confusing way of thinking about it. | 16:14 |
| fullermd | To compile your program and read files and make changes and make new commits, you need a working tree to do that in. Checkout creates a working tree for a given branch. | 16:15 |
| fullermd | bzr makes no inherent distinction between that working tree being colocated with the branch (as you get after a 'hg clone'), and the WT being somewhere completely different, on teh same system, or across a network. | 16:15 |
| fullermd | (this also implies you can have multiple WT's on a single branch at once, leading to a setup and workflow much like using CVS/SVN) | 16:16 |
| fullermd | The WT, among its metadata, has a pointer saying "hey, that there is the branch I'm a WT of". | 16:17 |
| fullermd | So when you do operations that touch the branch, like commit, or log, etc, it knows to go look there. | 16:18 |
| fullermd | (the branch in turn knows where its repository is, and goes there to save or retrieve revisions) | 16:18 |
| fullermd | When you phrase it as "just gets a specific revision", it can be read as if you were talking about a shallow branch/clone, which is off the rails. | 16:20 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| vds | hello, anyone can help with this trace back: http://paste.ubuntu.com/401898/ ? | 16:58 |
| === salgado-lunch is now known as salgado | ||
| jelmer | MvG: hi | 17:23 |
| MvG | jelmer: hi there | 17:24 |
| jelmer | MvG: Good, you're still here :-) | 17:24 |
| jelmer | MvG: Are you still interested in having a cache of last-modified data for directories? | 17:25 |
| jelmer | MvG: bzr-git needs something like that as well | 17:25 |
| jelmer | MvG: If that'd be useful, I'm happy to talk about it later. | 17:27 |
| MvG | jelmer: Yes, I'm interested. | 17:27 |
| MvG | Busy just now, I guess I'll have time in 30-60 min or so. | 17:27 |
| jelmer | mvg: same here | 17:28 |
| jelmer | just wanted to catch up before you ran off for the weekend :-) | 17:28 |
| meoblast001 | ok, i just did `bzr init --format=1.9` and got "Created a repository tree (format: 2a)" | 18:01 |
| jelmer | meoblast001: you're creating it inside of a shared repository which is already in the 2a format | 18:06 |
| meoblast001 | ooh | 18:07 |
| jelmer | though I'm the first to admit that ignoring what you asked for is a bad idea, it should instead tell you | 18:07 |
| l0nwlf | does bazaae supports installing branch behind a proxy with authentication ? | 18:09 |
| l0nwlf | my system time out while running "bzr branch lp:repo-name" | 18:10 |
| MvG | jelmer: you available now? | 18:48 |
| === radoe_ is now known as radoe | ||
| jelmer | MvG: hi | 19:14 |
| jelmer | MvG: yep | 19:14 |
| MvG | jelmer: OK, so where do we start? | 19:15 |
| jelmer | I think we should figure out whether what we need is actually the same thing | 19:15 |
| MvG | jelmer: We want a map from (d, r), a tuple between directory fileid and revision id, to a specific revision id, either the same or an ancestor of the r requested. | 19:16 |
| MvG | So let's say (d, r1) -> r2 for clarity. | 19:16 |
| MvG | We want the path and contents of d in r2 to be exactly the same as in r1. | 19:17 |
| jelmer | right, so the last revision id that touched a particular part of a repo ? | 19:17 |
| MvG | And we can judge this from deltas. | 19:18 |
| MvG | Starting from r1, we can compare parents and descend into a parent where the delta doesn't mention the path of d in any form, until we end up in a revision with no such parent, which will be r2. | 19:18 |
| jelmer | I'm not sure I follow | 19:19 |
| MvG | OK, so we look at revision r1, the one requested. It has a list of parents, p[0] ... p[n]. | 19:20 |
| MvG | We can compute the delta between r1 and p[i], and see what files are modified, what paths renamed, and so on. | 19:20 |
| MvG | For every such file, we can find out the paths, both old and new, and if either is equal to or lies within the path of our dir d, then the delta does touch the dir. | 19:21 |
| jelmer | ah, right | 19:22 |
| MvG | Come to think of it, if d lies within a dir touched by a rename, we should consider the delta to touch d as well. | 19:22 |
| jelmer | I was actually thinking of keeping a cache with this information | 19:22 |
| jelmer | rather than having a API that found it | 19:22 |
| MvG | Yes, well, that's point 2 on the agenda. | 19:22 |
| MvG | I'm still at the phase of finding out whether we want the same thing. | 19:23 |
| MvG | So now we should have a working definition of the info we want, and an idea how to obtain it in the first place. | 19:23 |
| MvG | Possible next steps are how do we obtain it efficiently, how do we store it from a data organization point of view, and how do we store it from a file format point of view. | 19:24 |
| MvG | It's the data organization I have given the most thought so far. | 19:24 |
| MvG | Seeing as the set of keys (d, r1) scales with both the number of dirs and the number of revisions, storing all these kees seems terribly inefficient. | 19:25 |
| MvG | Might be there is a way to tie the information efficiently to what bzr already does, but I know too little of the internal workings of bzr to decide this. | 19:25 |
| MvG | So what I have in mind is a tree. For every revision r1, determine a base revision b(r1) by clearing the least significant bit set in the history length (or gdfo if you convince me that's better) and choosing an ancestor with that history length (resp. gdfo) as the base. For r1, only record changes relative to its base. | 19:27 |
| MvG | As an effect, the vast majority of revisions have a base pretty close to them, with few changes. On the other hand, the tree ensures logarithmic path lengths, so for any revision you can find the last modified revisions in at most O(log histlen) steps. | 19:28 |
| MvG | You follow me so far? | 19:29 |
| MvG | jelmer: So much text you're still reading, or so boring stuff you fell asleep? | 19:40 |
| jelmer | MvG: Sorry, got distracted into coding :-) | 19:40 |
| MvG | Coding this, or coding something else? | 19:41 |
| jelmer | something related | 19:42 |
| * jelmer reads | 19:42 | |
| === khmarbaise_ is now known as khmarbaise | ||
| jelmer | MvG: right, so how would we go about implementing this - and where? | 19:51 |
| MvG | jelmer: Originally I had planned to implement this in trac-bzr, test and use it there, and move it somewhere else if there is need. | 19:52 |
| MvG | But now that you say you'd need something similar, maybe we should start out with a plugin. | 19:52 |
| MvG | I've just read how the bzr-revnocache plugin is organized, maybe we can crib some parts from there. | 19:53 |
| MvG | If I see things correctly, there is no way apps can benefit from this plugin unless they know about it, right? | 19:53 |
| jelmer | yeah | 19:54 |
| jelmer | that' | 19:54 |
| jelmer | s the problematic bit | 19:54 |
| jelmer | bzr-git needs this to operate properly | 19:54 |
| jelmer | so I'm a bit reluctant of having this code in a plugin | 19:54 |
| jelmer | ideally it would be copied into bzr-git or live in bzrlib | 19:54 |
| MvG | We could sync code between bzr-git and trac-bzr, but I guess sooner or later loggerhead or others would want it, too. | 19:55 |
| jelmer | yeah, ideally it'd be in bzrlib. | 19:55 |
| MvG | bzrlib would be ideal from a user point of view, but would impose much severe restrictions on robustness, testing, documentation, and so on. | 19:55 |
| jelmer | or perhaps the cache can be a plugin but we could have the API in bzrlib? | 19:55 |
| MvG | You read my thoughts. | 19:56 |
| MvG | By the way: do we need the same for files? I.e. if two branches modify a file, does bzr give the merge point as last modification revision? | 19:58 |
| jelmer | MvG: it gives the merge point if the revision was changed there | 19:58 |
| MvG | Changed by either maunal or automatic means? | 19:59 |
| jelmer | MvG: If you just take the version present in one of the parents it'll record the revision of that parent | 19:59 |
| MvG | OK. That's consistent then. | 19:59 |
| jelmer | I don't need that info though | 19:59 |
| MvG | Well, if we do this, we should do it right, so files and dirs should provide the same info. | 19:59 |
| jelmer | MvG: Should we provide any info for files at all ? | 20:00 |
| MvG | Yes, I think so. No need to cache anything there, but the API should give that info for dirs and files using a single method name, I believe. | 20:01 |
| MvG | jelmer: Seems to me that InventoryEntry would be the appropriate place for this API. | 20:05 |
| MvG | Is it justified to introduce an API into core although we know it will be slow? | 20:06 |
| MvG | jelmer: How would you store stuff? sqlite? pickled python? handwritten format? | 20:10 |
| MvG | Keep in mind that we have to store that b function I proposed as well, as calculating it the way I described might be too expensive. | 20:10 |
| jelmer | MvG: It should be the same API | 20:20 |
| jelmer | MvG: but we could have a hook that allowed you to provide a different mechanism to retrieve that info, that a plugin could use | 20:21 |
| jelmer | MvG: Yeah, InventoryEntry seems like the most appropriate place, indeed | 20:21 |
| MvG | So how do we go about this? 1. set up some shared branch, 2. implement fallback mechanism, 3. start plugin project? | 20:22 |
| MvG | Do you have time for this? I probably won't have much time till mid may or so. | 20:23 |
| jelmer | MvG: I don't have much time at the moment either | 20:25 |
| jelmer | we might have a look at UDS | 20:25 |
| MvG | ? | 20:25 |
| jelmer | there's a Bazaar sprint during the Ubuntu Developer Summit in Brussels in May | 20:28 |
| MvG | Dunno if I can afford going to Brussels, money-wise but more importantly time-wise. | 20:30 |
| MvG | Haven't given all that sprint stuff a closer look yet, as I mostly got the impression it's targeted at canonical staff. | 20:31 |
| jelmer | MvG: Sorry, I meant we as-in the attendees of the sprint : | 20:31 |
| MvG | I see. | 20:31 |
| jelmer | MvG: You're more than welcome to attend, I think more than half of the people there will be community | 20:31 |
| MvG | So you could try working on this there, maybe find some cooperation? | 20:31 |
| jelmer | MvG: Yeah, at least discussing the API bits | 20:31 |
| MvG | Should we write a few lines of blueprint or whatever to ensure this isn't forgotten? | 20:33 |
| jelmer | we don't really use blueprints for bazaar anymore | 20:34 |
| jelmer | I guess we should send a [RFC] to the list | 20:34 |
| MvG | I had started writing a mail while you were away coding, but it seems my thunderbird crashed on me. And in any case, I hadn't gotten much beyond the subject. | 20:35 |
| jelmer | perhaps we should put something up on the wiki? | 20:37 |
| MvG | Fine with me. | 20:38 |
| MvG | http://wiki.bazaar.canonical.com/LastModified ? | 20:38 |
| MvG | Or is there some naming convention we should follow? | 20:38 |
| jelmer | A lot of the specs are under Specs/ | 20:45 |
| jelmer | I think we need a clearer name though | 20:45 |
| MvG | Specs seems empty to me, I only find DraftSpecs... | 20:50 |
| MvG | Specs/DirLastModified might be better. Should we be more verbose than that? | 20:50 |
| MvG | jelmer: Unless you object (soon), I'll create http://wiki.bazaar.canonical.com/DraftSpecs/DirLastModified from SpecTemplate | 20:56 |
| MvG | jemer: Can you explain the rationale for bzr-git? | 21:07 |
| jelmer | MvG: That sounds fine | 21:10 |
| jelmer | MvG: bzr-git needs to create Git Tree objects | 21:10 |
| jelmer | which are roughly equivalent to subinventories | 21:11 |
| MvG | jelmer: Do you know if there is any "last modified" UI for files right now? | 21:28 |
| MvG | jelmer: http://wiki.bazaar.canonical.com/DraftSpecs/DirLastModified saved. Edit at will. | 21:35 |
| adiroiban | hi , any idea what is causing this error http://paste.ubuntu.com/402059/ ? | 22:11 |
| Peng | adiroiban: Most likely, .bzr/checkout/dirstate is corrupt, like it says. | 22:23 |
| Peng | adiroiban: Uhh, it's not a critical file, so it's easy enough to work around, but I forget how exactly... | 22:23 |
| adiroiban | Peng: I will try to search about how can I fix the dirstate | 22:24 |
| adiroiban | but I was expecting from bzr to hint a sollution in the error message | 22:24 |
| Peng | adiroiban: Is this a lightweight checkout or a full branch? | 22:27 |
| adiroiban | a full branch | 22:27 |
| Peng | adiroiban: Have any uncommitted changes in the branch or anything? | 22:28 |
| adiroiban | yes, but I have alreade created a new branch and copied the changed files | 22:28 |
| adiroiban | I was just wondering what is the user-friendly way of solving this problem | 22:28 |
| Peng | Bahhh, I don't remember. | 22:29 |
| Peng | BTW, please do keep a copy of .bzr/checkout/dirstate so someone can investigate what went wrong, if they want to. | 22:30 |
| Peng | Did anything interesting happen, like a power outage or computer crash? Or awful network file system? | 22:30 |
| Peng | You could try renaming .bzr/checkout out of the way and running "bzr co", but it might get mad and produce a massive number of conflicts, which would be a pain to clean up. | 22:31 |
| adiroiban | there was a power failure | 22:31 |
| adiroiban | that caused this mess | 22:32 |
| Peng | You could also "bzr remove-tree && bzr checkout", but it'll delete and re-create the working tree, causing a lot of I/O, and probably conflict horribly. | 22:33 |
| abk | hello | 22:45 |
| abk | any one there | 22:45 |
| abk | echo | 22:45 |
| Peng | abk: Perhaps not, but you should ask your question. | 22:59 |
| Peng | Also: Are you really IRCing as root? D: | 22:59 |
| abk | :D | 22:59 |
| abk | noop | 22:59 |
| Peng | Some channels ban root, you know. | 23:00 |
| Peng | .... | 23:00 |
| Peng | Anyway, I'm certainly not here. | 23:00 |
| Meths | Anyone looking at bzr on OpenSolaris? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!