| poolie | good morning spiv, igc, lifeless | 00:11 |
|---|---|---|
| poolie | jam, are you still around? | 00:11 |
| * Peng_ goes insane. | 00:14 | |
| mwhudson | Peng_: goes? | 00:17 |
| Peng_ | mwhudson: Good point. But now I'm even less sane! | 00:22 |
| dash | isn't sanity just a one-trick pony anyway | 00:23 |
| Peng_ | Loggerhead is refusing to serve one branch over http. :\ | 00:23 |
| Peng_ | Which is kind of annoying when I wanted to use that branch to *test* serving over HTTP. :P | 00:24 |
| Laney | did bzr push --fixes disappear? | 00:24 |
| poolie | fullermd: what do you mean by "inability to upgrade from dev formats"? | 00:24 |
| spiv | Good morning. | 00:25 |
| Peng_ | Laney: --fixes is an option on commit, not push. | 00:25 |
| Laney | Peng_: oh right, tahnks | 00:25 |
| Laney | thanks | 00:25 |
| fullermd | poolie: % bzr init --development6-rich-root x ; bzr upgrade --development7-rich-root x | 00:32 |
| fullermd | For any permutation of dev6, dev7, 2a in the init/upgrade. | 00:32 |
| fullermd | bzr: ERROR: Cannot convert to format <RepositoryFormatCHK2>. Does not support nested trees | 00:32 |
| fullermd | I don't know of a filed bug on it. It's come up here and on the ML a few times; I was under the impression that somebody was working on it. | 00:34 |
| fullermd | jelmer, maybe. | 00:34 |
| poolie | could you search or file one please? | 00:35 |
| mwhudson | poolie, fullermd: i think that bug is fixed in bzr.dev, from things i overheard | 00:36 |
| fullermd | Well, the error I just posted is from trying it on my up-to-date bzr.dev... | 00:36 |
| fullermd | (well, OK, I'm missing jam's win32 packaging fix, but I'm guessing that doesn't solve it ;) | 00:37 |
| poolie | the upgrade bug? | 00:37 |
| Peng_ | mwhudson: ping | 00:37 |
| mwhudson | Peng_: hi | 00:37 |
| Peng_ | mwhudson: Is it just me, or is Loggerhead serving .bzr over HTTP broken? | 00:37 |
| mwhudson | Peng_: no idea | 00:37 |
| * mwhudson tries | 00:38 | |
| Peng_ | bzr+http works (I just landed that), but regular old nosmart+http does not. | 00:38 |
| fullermd | Well, nothing in my =bazaar-bugs is jumping out at me, so I guess there isn't one filed... | 00:38 |
| mwhudson | Peng_: jelmer said something about the smart server support only working for standalone repositories, i think? | 00:39 |
| mwhudson | standalone branches, sigh | 00:39 |
| Peng_ | mwhudson: Yeah, thanks to bug #348308, but my issue is HTTP. | 00:39 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 | 00:39 |
| Peng_ | It should be possible for Loggerhead to monkeypatch around that bug, but it's probably a bad idea. | 00:40 |
| mwhudson | Peng_: yes, seems .bzr requests are 404ing | 00:40 |
| Peng_ | mwhudson: Thanks for confirming it. | 00:40 |
| mwhudson | you know what would make loggerhead better? | 00:41 |
| mwhudson | tests | 00:41 |
| Peng_ | I manually test several different things, but I never run the test suite. :P | 00:42 |
| mwhudson | Peng_: | 00:43 |
| mwhudson | Invalid url supplied to transport: "readonly+file:///home/mwh/canonical/repos/loggerhead/": local urls must start with file:/// | 00:43 |
| mwhudson | lalala | 00:43 |
| Peng_ | I was just going to say: NotBranchError: Not a branch: "readonly+file:///trunk/.bzr/branch-format/". | 00:43 |
| === afk is now known as mthaddon | ||
| fullermd | It's also kinda annoying how upgrade moves everything into backup locations BEFORE blowing up in that case... | 00:44 |
| fullermd | bug 388727 | 00:45 |
| ubottu | Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed] https://launchpad.net/bugs/388727 | 00:45 |
| Peng_ | mwhudson: Looks like both get_local_path and check_is_a_branch fail, in different ways. I'll file a bug. | 00:46 |
| === afk is now known as mthaddon | ||
| igc1 | morning | 00:53 |
| === igc1 is now known as igc | ||
| poolie | hello igc | 00:54 |
| igc | morning poolie | 00:54 |
| * Peng_ goes /away to eat. | 00:55 | |
| garyvdm | Hi poolie. | 01:08 |
| garyvdm | poolie: create_by_apply_delta is only available in CHKInventory | 01:08 |
| jelmer | garyvdm: You can also use Repository.add_inventory_by_delta() | 01:09 |
| jelmer | garyvdm: which works on all repositories | 01:10 |
| * garyvdm look | 01:10 | |
| garyvdm | Hi jelmer | 01:10 |
| jelmer | hi Gary | 01:10 |
| jelmer | I ran into the same problem trying to find what function to use for bzr-svn/bzr-git | 01:10 |
| garyvdm | jelmer: I want to create a in memory inventory. | 01:11 |
| garyvdm | jelmer: won't Repository.add_inventory_by_delta add an inventory to the repository? | 01:12 |
| jelmer | garyvdm: yeah, it'll write out to disk | 01:12 |
| garyvdm | i.e. write it to disk? | 01:12 |
| jelmer | garyvdm: You can steal some of its logic though | 01:12 |
| jelmer | garyvdm: which it uses to apply deltas to non-CHKInventory's | 01:12 |
| * garyvdm looks :-) | 01:13 | |
| garyvdm | There's Inventory.apply_delta - I need to test if that just changes the inventory in memory, or to disk. | 01:16 |
| jelmer | garyvdm: it changes in memory | 01:16 |
| garyvdm | jelmer: even WorkingTree.inventory? | 01:17 |
| jelmer | garyvdm: yeah, but you'd probably don't want to change that directly since WorkingTree would just return its own copy | 01:17 |
| jelmer | garyvdm: WorkingTree.inventory.apply_delta() will not directly write out to disk, but will probably cause strnage behaviour | 01:18 |
| garyvdm | jelmer: is there a way to create my own copy of the inventory? | 01:18 |
| jelmer | garyvdm: you can make an in-memory copy of WorkingTree.inventory though, and apply the delta to that | 01:18 |
| lifeless | garyvdm: in general no. | 01:18 |
| lifeless | garyvdm: you shouldn't be working with Inventory | 01:18 |
| lifeless | s/working with/mutating or modifying/ | 01:19 |
| garyvdm | lifeless: Hi | 01:19 |
| lifeless | the only objects that should modify inventories are implementations of Repository or Tree | 01:19 |
| Peng_ | ...I just pulled down 1 revision of bzr.dev. It took 100 seconds, nearly all of which was bzr-search indexing. o_O | 01:19 |
| garyvdm | lifeless: even a in-memory copy? | 01:19 |
| Peng_ | Sorry, _two_ revisions of bzr.dev. | 01:19 |
| lifeless | garyvdm: an in memory copy of a working tree inventory is shared with the tree and will be saved when write lock is released | 01:20 |
| lifeless | garyvdm: it is the trees /internal/ state | 01:20 |
| lifeless | garyvdm: so no, you should *never* modify an inventory unless your code is part of the implementationof the appropriate Tree or Repository subclasss. | 01:20 |
| Peng_ | ...Wait a minute, why did Loggerhead work? Shouldn't the ProgressBarStack thing have broken it? | 01:21 |
| garyvdm | lifeless: Is there not a way to create a copy that does not affect the internal state? | 01:21 |
| lifeless | garyvdm: there is but its slow and expensive | 01:22 |
| lifeless | garyvdm: and as previously noted Inventory can't represent the concepts you want like unversioned or ignored files. | 01:23 |
| garyvdm | lifeless: ok. | 01:23 |
| garyvdm | lifeless: btw - I was wrong about iter_changes returning ignored files. It does. | 01:23 |
| lifeless | :) | 01:24 |
| garyvdm | That makes things easier for me :-) | 01:24 |
| lifeless | jml: perhaps this channel works for you?... | 01:27 |
| garyvdm | lifeless: would it be safe to set a new instance var on a inventory item? e.g. tree.inventory[fileid].status = "modified" | 01:27 |
| lifeless | they use slots; it won't work. | 01:29 |
| garyvdm | ok | 01:29 |
| lifeless | jelmer: what does alioth need | 01:33 |
| lifeless | jelmer: in more precise terms than 'another config file' | 01:33 |
| poolie | jml, as you probably saw, there are some new bugs targeted to 1.16 | 01:38 |
| Peng_ | Pulling another revision of bzr.dev took 45 seconds. Again, almost all bzr-search. :\ | 01:47 |
| Peng_ | Are bzr.dev's search indices supposed to be 61 MB? | 01:48 |
| dash | indexing is hard | 01:48 |
| Peng_ | 18 MB is just from the last 2 days. | 01:49 |
| Peng_ | lifeless: ping ^ | 01:49 |
| lifeless | Peng_: yes | 01:50 |
| lifeless | Peng_: can it be shrunk? yes. There are several things that can be done. The index contents can be revisited now we have faster facilities for 'what path is this fileid.revisionid at'. | 01:51 |
| lifeless | We got to bit indices rather than int indices | 01:51 |
| lifeless | we can filter extremely common terms[though this is not necessarily a win] | 01:51 |
| Peng_ | I don't really mind the index size. What I mind is that 1/3 of it is from the last 2 days, and indexing during pull is taking 40-45 seconds per revision of bzr.dev. | 01:52 |
| Peng_ | Maybe it autopacked? | 01:52 |
| lifeless | Peng_: so it autopacks | 01:52 |
| lifeless | I really doubt that 1/3 is new from 2 days of changes | 01:53 |
| lifeless | further, indexing requires extracting much data and we're not in bbc yet. | 01:53 |
| Peng_ | Yeah, you're right. I just checked the obsolete directory. ~4.3 MB from the last week. | 01:53 |
| Peng_ | No crisis, then, I guess. :) | 01:54 |
| * Peng_ /away! | 01:56 | |
| thumper | do we have a way yet to say "Don't stack" even if the remote server suggests a branch to stack on? | 02:04 |
| lifeless | no | 02:04 |
| thumper | arse | 02:04 |
| lifeless | not exactly a common use casse | 02:05 |
| lifeless | if the server is misconfigured, fix it :) | 02:05 |
| thumper | the server isn't misconfigured | 02:05 |
| thumper | sometimes we want to say this | 02:05 |
| lifeless | sure; like I said its not _common_. | 02:05 |
| jelmer | lifeless: somethin that can run as a system service basically | 02:10 |
| lifeless | jelmer: BZR_HOME=/etc/bazaar | 02:10 |
| jelmer | lifeless: something sustainable, not a quick hack | 02:11 |
| lifeless | jelmer: that is sustainable | 02:11 |
| jelmer | lifeless: at the very least it would be nice if that was more easily accessible, e.g. serve-branches --config=foo would do BZR_HOME=foo under the covers | 02:13 |
| lifeless | jelmer: that would be problematic for me | 02:13 |
| lifeless | because it makes BZR_HOME=foo server-branches --config=foo less clear | 02:13 |
| jelmer | lifeless: also, it's a bit redundant to have every variable in a configuration file prefixed with "http_" | 02:14 |
| lifeless | jelmer: that seems unnecessary and likely inaccurate - public_url's etc should be from the stock bzr information | 02:16 |
| jelmer | lifeless: loggerhead prefixes all its variables with http_ in ~/.bazaar/bazaar.conf at the moment | 02:17 |
| jelmer | lifeless: this specifically is about those variables, not about whatever would usually live in .bzr/branch/branch.conf | 02:19 |
| lifeless | jelmer: well, up to beuno etc. I don't think a specific config file is a good idea though. | 02:20 |
| lifeless | Because using the stock stuff lets you use locations.conf to configure different loggerhead servers | 02:20 |
| lifeless | and if a global config is needed, well there is a bug open on bzr to support /etc configuration already. | 02:20 |
| jelmer | lifeless: I don't see how locations.conf is related here, this isn't about branch-specific settings | 02:20 |
| lifeless | I definitely think BZR_HOME will work reliably for alioth | 02:21 |
| jml | poolie, yeah, I haven't had a chance to look at them yet today, but I will | 02:23 |
| lifeless | jml: testresources: review requested. | 02:24 |
| jml | poolie, I haven't had a chance to do anything other than _react_ | 02:24 |
| jml | lifeless, yeah, I saw the email and flagged it for answer. | 02:24 |
| jml | with luck & a spare energon cube I'll get it done tonight. | 02:24 |
| poolie | all jml, you don't need to look at them now, just making you aware | 02:26 |
| jml | poolie, cool :) | 02:27 |
| jelmer | lifeless: alioth wants a backport package with init script etc they can use, but I'd like to see loggerhead settle on something first so I don't have to worry about providing an upgrade path in two months | 02:27 |
| AfC | I see a lot of conversations in Git projects (cairo being the present instance) saying things like "rebase your work to current master" as a long lived branch gets closer to being considered for acceptance into the project. | 02:27 |
| AfC | Isn't that just "hey, merge current 'mainline' into your branch, please"? Followed by healthy use of things like `bzr diff -r ancestor:....../mainline` ? | 02:28 |
| lifeless | jelmer: I don't see why BZR_HOME would stop working. | 02:29 |
| lifeless | AfC: in bzr we would just merge yes. because that preserves prior testing etc. | 02:29 |
| AfC | lifeless: (not to mention not creating new revisions that say exactly the same thing). Ok, that's what I thought. | 02:30 |
| lifeless | AfC: rebasing deletes test results :). If it wasn't long lived, and would just a short lived private branch rebase would matter a lot less. | 02:30 |
| AfC | lifeless: is it because of their "I want to see individual patches building towards a result which are the only thing I'm [to be] looking at" culture? | 02:31 |
| lifeless | yes | 02:31 |
| AfC | hm | 02:31 |
| lifeless | which is the history presentation aspect of the RFC I put together | 02:31 |
| lifeless | and it *is* easier to review a series of small patches than a single monolith | 02:32 |
| AfC | So, while I'm over that, I do wonder what on earth we can do to make Bazaar acceptable to that desired workflow [without needing rebase] | 02:32 |
| AfC | lifeless: granted | 02:32 |
| lifeless | looms | 02:32 |
| AfC | hm. Yeah, I guess | 02:32 |
| lifeless | thats what they are designed for | 02:32 |
| AfC | ah | 02:32 |
| lifeless | implementation bugs and polish aside | 02:32 |
| lifeless | I do think we need rebase as a core polished utility | 02:33 |
| lifeless | but we need to have versioned versions of the same tools for when people are collaborating | 02:33 |
| AfC | lifeless: so taking a slightly different gloss on this, if individual patch or revision {1,more} cherry picking worked in some way that explicitly and strongly said "this «new» revision came from and essentially is _that_ revision" | 02:34 |
| AfC | lifeless: then rebasing (hypothetically using that) would be a lot less evil to us. | 02:34 |
| AfC | s/us/our viewpoint/ | 02:34 |
| AfC | [right?] | 02:34 |
| AfC | I realize that "what tree state did you test" is very important... but if we can have a dotted line between "what I'm merging" and "what actually was tested by its author" maybe things would be ok | 02:36 |
| AfC | dunno | 02:36 |
| lifeless | AfC: I think such cherrypicking would be necessary but not sufficient | 02:36 |
| lifeless | merge is the key | 02:36 |
| AfC | [I do know that I don't think I'm going to be able to work on any Git based projects ... the DVCS culture I've been taught here is too different from what goes on there] | 02:36 |
| AfC | lifeless: (well, cherrypick as in `bzr merge ../other_branch/.../filename` | 02:37 |
| AfC | cherrypick is another brutal overload around here | 02:37 |
| lifeless | AfC: merging *after* the cherrypick for people that had merged the original revision | 02:37 |
| AfC | up there with history editing ^W commit message fixing | 02:37 |
| jelmer | lifeless: If loggerhead started reading settings from some other file, I wouldn't necessarily expect it to also check http_* in BZR_HOME/bazaar.conf | 02:37 |
| lifeless | mwhudson: ^ can you reassure jelmer | 02:37 |
| AfC | lifeless: yeah, after | 02:37 |
| AfC | lifeless: that really is the key, isn't it | 02:38 |
| lifeless | its easy to cherrypick | 02:38 |
| lifeless | its relatively easy to record that you did | 02:38 |
| mwhudson | lifeless: this hasn't been my work, i have no real opinions | 02:38 |
| AfC | lifeless: (I would be impressed if I didn't have to because the tool & it's UIs did said recording for me) | 02:38 |
| jelmer | lifeless: Or to put it in a different way, I wouldn't expect apache to read settings from /root/.apache.conf either by default | 02:38 |
| lifeless | its still freaking-hard to merge the cherrypicked thing accurately without security issues or spurious conflicts | 02:38 |
| mwhudson | though i prefer reading http_* options from a bazaar.conf to inventing our own formats and locations | 02:39 |
| jelmer | lifeless: and not have an easily disocverable way to override that | 02:39 |
| lifeless | mwhudson: has there been a release of loggerhead that does | 02:39 |
| AfC | lifeless: so I gather. | 02:39 |
| mwhudson | lifeless: no | 02:39 |
| AfC | Right. Lunch time rush at this cafe. Time to move. | 02:39 |
| * mwhudson is not paying attention here any more, sorry | 02:39 | |
| mwhudson | send me email if you want a conversation on this | 02:40 |
| Peng_ | When pulling, what happens after post_change_branch_tip hooks fire? In other words, if the hook throws an exception, what didn't happen? E.g., it looks like the branch updated correctly, but not the working tree. | 02:50 |
| * Peng_ randomly goes /away again. | 02:50 | |
| lifeless | right | 02:51 |
| lifeless | update to recover | 02:51 |
| RenatoSilva | if I clone a branch, and that branch is updated after I did a few commits on the clone, what should I do to merge the clone with that branch? | 03:10 |
| garyvdm | RenatoSilva: Clone? did you do a checkout, or branch? | 03:12 |
| garyvdm | RenatoSilva: if you create a checkout, you can do bzr update. If you did a branch, you can do bzr merge. | 03:16 |
| RenatoSilva | by clone I mean bzr branch | 03:16 |
| lifeless | RenatoSilva: you can bzr pull, if no changes were made to the origin branch in the interim, or you can (bzr merge; bzr commit) | 03:19 |
| RenatoSilva | imagine the original branch is at rev 40, then I copy it and commit 5 revisions (my local branch is now rev 45), but in the meatimeremote branch was updated and is now in rev 43. A merge between the branches woulnd't get confused? | 03:19 |
| lifeless | not at all | 03:19 |
| lifeless | its what bzr merge is meant to be used for | 03:20 |
| RenatoSilva | yeah I can do a bzr pull, but what happens if I don't? | 03:20 |
| RenatoSilva | bzr merge will pull the changes before merging? | 03:20 |
| spiv | You can't do bzr pull (try it), it will tell you it's can't pull because the branches have diverged. | 03:21 |
| spiv | So you need to bzr merge, because you changes to merge. It won't get confused, because bzr is not CVS :) | 03:22 |
| krisfremen | lol | 03:22 |
| spiv | s/you changes/you have changes/ | 03:22 |
| RenatoSilva | spiv: ok | 03:27 |
| * igc lunch and medical appointment - bbl | 03:56 | |
| RenatoSilva | can multiple tags point to the same version? | 04:00 |
| lifeless | yes. technically to a revisionid | 04:05 |
| === timchen1` is now known as nasloc__ | ||
| garyvdm | lifeless: how come item.revision for a item from a WorkingTree.inventory is allways none? | 04:11 |
| garyvdm | Could it not tell you the revision from the basis tree? | 04:12 |
| spiv | jml: I'm working on https://bugs.edge.launchpad.net/bzr/+bug/388675, do you want this fix in 1.16? | 04:19 |
| ubottu | Launchpad bug 388675 in bzr "automatic stacking format upgrade doesn't work over the smart server" [High,In progress] | 04:19 |
| spiv | jml: I have the issue diagnosed and a quick fix, just making proper patch with tests etc now. | 04:19 |
| ablmf1 | I typed "bzr branch lp:oah/gst-plugins-base", it starts to download, but it only download a directory containing ".bzr", nothing else. Where is the code? | 04:24 |
| lifeless | garyvdm: the working inventory doesn't have that data | 04:28 |
| garyvdm | :-( | 04:28 |
| garyvdm | I'll just have to hide the revision columns when showing the wt. | 04:28 |
| lifeless | garyvdm: the basis inventory does (but we're looking at getting rid of most of the basis inventory stored in the tree because we don't need to look at it very often, its largely dead weight) | 04:28 |
| ablmf1 | [###########/ ] http > 2638KB 3KB/s | Copying content texts:Copied | 04:29 |
| ablmf1 | It looks like it have download a lot things | 04:29 |
| lifeless | ablmf1: it's building a local bzzr branch. Once it has the history it will build the working tree | 04:29 |
| ablmf1 | lifeless: Should I wait till all the progress bar reach the end | 04:31 |
| ablmf1 | or should I give up now? | 04:31 |
| lifeless | ablmf1: wait | 04:31 |
| lifeless | ablmf1: its all working normally | 04:32 |
| Peng_ | ablmf1: Why do you want to give up? | 04:32 |
| ablmf1 | Peng_ : because it has been downloading for 20 m but only give me a .bzr ... Quite slow to access lp from here | 04:33 |
| lifeless | ablmf1: it *only* does a .bzr until right at the very end | 04:35 |
| lifeless | ablmf1: thats normal. | 04:35 |
| RenatoSilva | ablmf1: the .blz contains the whole history | 04:35 |
| Peng_ | Hmm, that branch is like 25-30 MB. | 04:35 |
| RenatoSilva | s/blz/.bzr | 04:35 |
| ablmf1 | Is there any quicker way? | 04:36 |
| lifeless | ablmf1: if you're using http, you probably have a broken http proxy, based on the discussion from yesterday. | 04:36 |
| ablmf1 | lifeless: No. I am the one discussing proxy with you yesterday. | 04:37 |
| ablmf1 | Toady I stayed at home for downloading the source code I need | 04:37 |
| lifeless | ablmf1: do you mean yes? | 04:37 |
| lifeless | oh, ok. | 04:37 |
| lifeless | so anyhow | 04:37 |
| lifeless | over http bzr has to do many readv operations | 04:38 |
| lifeless | it shouldn't be *that* slow | 04:38 |
| ablmf1 | svn has a "svn export" command which do not download the history | 04:39 |
| ablmf1 | does bzr have one? | 04:39 |
| RenatoSilva | It would be nice to download branches as zip files | 04:39 |
| lifeless | RenatoSilva: loggerhead can do that; its just not enabled on launchpads logerhead | 04:39 |
| lifeless | ablmf1: bzr has one, but it works by downloading the history | 04:39 |
| RenatoSilva | lifeless: good to know | 04:39 |
| lifeless | ablmf1: (svn doesn't download history *ever* anyway, svn export isn't as different as you might think) | 04:40 |
| RenatoSilva | Well, I just merged a directive to a branch, and it opened a file with the commit messages of the patch now that I'm trying to commit the directive changes | 04:40 |
| RenatoSilva | -- This line and the following will be ignored --, what should I do? The command is waiting for the text editor. | 04:41 |
| lifeless | You should type in a commit message above the line | 04:41 |
| lifeless | whatever you want to say about the merge. | 04:41 |
| RenatoSilva | was this caused by an empty bzr commit as I did? | 04:41 |
| lifeless | no | 04:42 |
| lifeless | its normal | 04:42 |
| RenatoSilva | if I did, it would be 2 commit messages then? | 04:42 |
| RenatoSilva | if I put a message I mean | 04:42 |
| dash | 04:43 | |
| garage_seb | i messed up, but i dont know how much damage i caused | 04:43 |
| ablmf1 | [###########\ ] http > 6861KB 6KB/s | Copying content texts:Copied | 04:43 |
| garage_seb | i have a server with a shared repo with a bunch of related branches in it | 04:43 |
| ablmf1 | It looks like it has download 6MB | 04:43 |
| ablmf1 | But I only find 200kb in the working directory | 04:44 |
| garage_seb | on a development machine i have another shared repo with copies of those "central" branches, plus a bunch of local branches branched from them | 04:44 |
| garage_seb | my mistake was: | 04:44 |
| garage_seb | i accidentally pushed one of the development branches from the devel machine to the *repo* dir on the central server without specifying a target branch dir | 04:45 |
| lifeless | RenatoSilva: huh? You'll only get one commit message. | 04:45 |
| lifeless | RenatoSilva: I don't really understand what you're asking. | 04:45 |
| lifeless | ablmf1: you could try stracing the process to see what is happening | 04:46 |
| lifeless | ablmf1: as for how much is in the working directory, there are buffers on whats written to disk and so on; I assure you if you let it finish it will have achieved what you want. | 04:46 |
| RenatoSilva | lifeless: bzr commit -m "message 1", then shows text file, then I type in the file "message 2" | 04:47 |
| garyvdm | RenatoSilva: You may find it easier to use bzr qcommit - This shows a gui for commit | 04:47 |
| wgrant | garage_seb: I don't think that should break anything. Has it? | 04:47 |
| RenatoSilva | lifeless: the merge will contain all directive commits? Is it smart enough? | 04:48 |
| lifeless | RenatoSilva: it should not have popped up an editor if you used -m | 04:48 |
| RenatoSilva | lifeless: oh, so...was this caused by an empty bzr commit as I did? | 04:48 |
| RenatoSilva | lifeless: the answer is yes | 04:48 |
| RenatoSilva | you had said no and I get confused :) | 04:49 |
| lifeless | empty can mean 'no message' or 'no changes', I thought you meant the latter. | 04:49 |
| RenatoSilva | lifeless: ok sorry, my mistake then :) | 04:49 |
| RenatoSilva | it all makes sense now :) | 04:49 |
| lifeless | cool | 04:49 |
| RenatoSilva | btw, it will never allow empty message? | 04:50 |
| lifeless | I don't think so | 04:50 |
| RenatoSilva | bzr: ERROR: empty commit message specified | 04:50 |
| RenatoSilva | after I just closed the file | 04:50 |
| lifeless | thats right | 04:51 |
| lifeless | if you're doing a merge | 04:51 |
| lifeless | write a message describing what you are merging. You can skip the details as they will still be present in the commits you are merging. | 04:51 |
| RenatoSilva | ok, then it will deny only for merges | 04:51 |
| spiv | ablmf1: also, there's some overhead in figuring out what content to transfer before it actually transfers the content. | 04:51 |
| spiv | ablmf1: especially over a dumb transport like http | 04:52 |
| spiv | ablmf1: so you may well find that the final size on disk is noticeably smaller than the total network traffic. | 04:52 |
| lifeless | spiv: with readv batching it should be 1-2% no more | 04:53 |
| lifeless | for an initial branch | 04:53 |
| garyvdm | lifeless, poolie, jelmer: Thanks for the advice. I have achieved what I wanted to (a browse tree widget, that shows unversioned files and change status) | 04:54 |
| RenatoSilva | I think as they're little changes, it makes more sense to aplly them manually, because I just have to reason to give a bout the merge. The reason is just because they were 2 commits at work, and I couldn't push them there :) | 04:54 |
| lifeless | RenatoSilva: if you haven't made local changes you can just pull from the directive | 04:54 |
| RenatoSilva | s/to reason/no reason | 04:54 |
| lifeless | rather than merging | 04:54 |
| RenatoSilva | humm, nice! | 04:54 |
| garyvdm | lifeless, poolie, jelmer: If you are intrested in what I have done, the code it here: http://bazaar.launchpad.net/~garyvdm/qbzr/trees/annotate/head:/lib/treewidget.py | 04:55 |
| RenatoSilva | how do I undo the merge? | 04:55 |
| RenatoSilva | bzr revert? | 04:55 |
| lifeless | RenatoSilva: yes | 04:55 |
| lifeless | 'bzr revert' | 04:55 |
| RenatoSilva | ok | 04:55 |
| RenatoSilva | bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them. | 04:59 |
| lifeless | so you do need to merge | 04:59 |
| RenatoSilva | bzr missing > Using saved parent location: bzr+ssh://bazaar.launchpad.net/~renatosilva/bzr-email/mail-customization/ Branches are up to date.zr+ssh > 0KB 0KB/s | | 04:59 |
| lifeless | I would just merge them with -m "Small fixes from work" or some such | 04:59 |
| RenatoSilva | ok but I'm trying to learn :) | 05:00 |
| RenatoSilva | Hummm let me see... | 05:00 |
| RenatoSilva | The work branch is a branch from bzr-mail! | 05:00 |
| RenatoSilva | My branch here is the mail-customization | 05:01 |
| RenatoSilva | You can skip the details as they will still be present in the commits you are merging. --> actually they're not there :( | 05:04 |
| RenatoSilva | After my last commit comment from lp, the next one is from the merge. | 05:04 |
| lifeless | RenatoSilva: run bzr log -n0 | 05:05 |
| RenatoSilva | it is in rev 41 in lp, there were 2 revs in the merge, but when I commited I'd expect the local branch go to rev 43 | 05:06 |
| garyvdm | RenatoSilva: try running qlog | 05:06 |
| garyvdm | err - bzr qlog | 05:06 |
| lifeless | RenatoSilva: have you tried running log -n0 | 05:07 |
| garyvdm | You should be able to expand rev 41 - under it you will see the revisions that you merged. | 05:07 |
| seb_ | lifeless, any words of wisdom on the situation i reported above, in a previous incarnation when i was known as garage_seb? | 05:08 |
| RenatoSilva | bzr log -r40.. | 05:08 |
| lifeless | RenatoSilva: with "-n0" | 05:08 |
| lifeless | so "bzr log -n0 -r40.. | 05:08 |
| lifeless | " | 05:08 |
| spiv | seb_: did you see wgrant's question? | 05:09 |
| seb_ | oops no that must have been while my dsl modem blinked out :-( | 05:09 |
| lifeless | seb_: nothing should be broken | 05:10 |
| spiv | seb_: < wgrant> garage_seb: I don't think that should break anything. Has it? | 05:10 |
| seb_ | oh good :-) | 05:10 |
| seb_ | things seem to be working just fine | 05:10 |
| lifeless | seb_: if you want to get rid of the branch you pushed, you can remove the .bzr/branch directory it will have created | 05:10 |
| seb_ | heh, i just did that and things *still* seem fine | 05:10 |
| RenatoSilva | http://pastie.org/515988, http://pastie.org/515990 | 05:10 |
| lifeless | [but be sure to leave .bzr/repository alone, as that is your shared repo :P] | 05:10 |
| seb_ | ok thanks guys :-) | 05:11 |
| seb_ | yes i didnt remove that one | 05:11 |
| lifeless | RenatoSilva: right, in 515990 you can see the messages | 05:11 |
| RenatoSilva | lifeless: so, the merge revisions become sub-revisions? | 05:12 |
| spiv | jml, mwhudson (and anyone else interested): https://code.edge.launchpad.net/~spiv/bzr/default-stacking-again/+merge/7601 fixes that stacking bug. | 05:12 |
| mwhudson | spiv: is it client side or server side? | 05:13 |
| lifeless | RenatoSilva: yes, thats a reasonable way to think about it | 05:13 |
| lifeless | mwhudson: client | 05:13 |
| mwhudson | cool | 05:13 |
| RenatoSilva | lifeless: ok thanks | 05:13 |
| lifeless | this is one of the key, critical diferences vs CVS | 05:13 |
| jml | spiv, thanks, I'll take a look at it. | 05:14 |
| spiv | mwhudson: client | 05:14 |
| spiv | Oh, I'm too slow today :) | 05:15 |
| RenatoSilva | pushed \o/ | 05:15 |
| garyvdm | RenatoSilva: have you tried bzr qlog? | 05:15 |
| RenatoSilva | garyvdm: yes | 05:15 |
| garyvdm | RenatoSilva: And? did it help? | 05:16 |
| jml | spiv, thanks I'll take a look at it. | 05:16 |
| jml | spiv, sorry for the lag -- I needed to have a lunch break afk :) | 05:16 |
| spiv | jml: I understand :) | 05:16 |
| RenatoSilva | garyvdm: now yes, I didn't note the "+" | 05:16 |
| spiv | jml: I'm actually planning on doing the same shortly :) | 05:16 |
| RenatoSilva | garyvdm: nice view, thanks! btw, Qt for windows? | 05:17 |
| garyvdm | RenatoSilva: qt is multi-platform | 05:17 |
| garyvdm | RenatoSilva: used by KDE | 05:17 |
| RenatoSilva | garyvdm: oh I didn't know that, the widgets look pretty native | 05:18 |
| RenatoSilva | garyvdm: it's embedded in bzr installer? | 05:19 |
| garyvdm | RenatoSilva: yes | 05:19 |
| RenatoSilva | garyvdm: ok, thank you! | 05:19 |
| garyvdm | /quit zzzzz | 05:26 |
| === _thumper_ is now known as thumper | ||
| mwhudson | spiv: thanks for fixing that bug so quickly :) | 05:29 |
| spiv | mwhudson: once I untangled the particular confusions it wasn't too hard. | 05:30 |
| * spiv -> lunch | 05:36 | |
| RenatoSilva | Does TortoiseBzr use Qt? | 05:40 |
| RenatoSilva | I'm afraidn to install it, because TortoiseCVS was not working well | 05:47 |
| poolie | lifeless, spiv, the bug editing collisions were i think bug 28459 | 06:47 |
| ubottu | Launchpad bug 28459 in malone "Handle mid-air collisions in bug reports" [Low,Triaged] https://launchpad.net/bugs/28459 | 06:47 |
| lifeless | poolie: our one wasn't, unless you'd had the bug open for 30 minutes or so... I guess that is possible ;) | 07:04 |
| lifeless | poolie: still, its a nice low bug number ;) | 07:06 |
| vila | hi all | 07:07 |
| poolie | i did have it open | 07:22 |
| poolie | because, probably someone started talking to me | 07:22 |
| poolie | also i was wondering what the magic number at the start was | 07:23 |
| poolie | hello vila | 07:23 |
| poolie | lifeless, re bug 308403, | 07:23 |
| ubottu | Launchpad bug 308403 in bzr "bzr add should optionally fail if explicitly named files are ignored" [Medium,Confirmed] https://launchpad.net/bugs/308403 | 07:23 |
| poolie | do you in pracitice commonly add files matching ignore patterns? | 07:23 |
| vila | hi poolie | 07:23 |
| lifeless | poolie: Its not that I commonly do it; its a design principle I have. | 07:24 |
| lifeless | poolie: which is that its better to do whats asked and make reverting mistakes easy. | 07:24 |
| lifeless | poolie: and we already have that. | 07:24 |
| lifeless | poolie: I don't object to bzr add having a --strict mode or something for people that prefer to have the command fail. | 07:27 |
| poolie | mm maybe there should be a global --strict | 07:28 |
| lifeless | Stopping on many little things and forcing things to be re-run is just irritating in my experience. Clippy leads down that road ;) | 07:29 |
| jml | some people like being irritated. | 07:29 |
| jml | perverse creatures that they are | 07:29 |
| lifeless | jml: Whats better for most of our users is the question. | 07:30 |
| jml | lifeless, I thought we were talking about an option? | 07:31 |
| lifeless | jml: Yes but: a) An option has its own overhead. b) options have defaults so they need to be chosen. | 07:31 |
| poolie | so specifically i want some satisfactory solution to bug 322767 | 07:35 |
| ubottu | Bug 322767 on http://launchpad.net/bugs/322767 is private | 07:35 |
| poolie | which complains about people adding conflict files | 07:35 |
| lifeless | .BASE/.OTHER/.THIS | 07:36 |
| poolie | blocking adds of ignored files is a somewhat indirect way to stop it | 07:36 |
| poolie | yes, and .moved | 07:37 |
| lifeless | so | 07:37 |
| lifeless | doesn't commit abort on conflicts? | 07:37 |
| poolie | yes, of course | 07:37 |
| lifeless | and doesn't resolve delete those files? | 07:37 |
| poolie | it's kind of user error | 07:37 |
| poolie | people are apparently just banging harder on it to resolve the conflicts | 07:37 |
| lifeless | well, specifically, I'm confused about *how they manage it* | 07:37 |
| poolie | because, i guess, they're confused | 07:37 |
| poolie | how they manage to do it? | 07:37 |
| lifeless | right | 07:37 |
| lifeless | running bzr resolve should delete those files; commit won't work until they have resolved, and then the files should be absent. | 07:38 |
| lifeless | So my first instinct is 'what bug in the resolve->commit cycle is permitting this to happen' | 07:38 |
| poolie | so | 07:38 |
| poolie | they may do 'bzr add foo.c.OTHER'; bzr resolve ;bzr commit | 07:38 |
| poolie | but why wouldn't resolve delete them? | 07:39 |
| lifeless | exactly. | 07:39 |
| jml | lifeless, on https://bugs.edge.launchpad.net/bzr/+bug/388727 you suggest that it's not critical for 1.16 because it dev6->2a works, but later it's revealed that it doesn't work. Does that mean it probably should be critical about it? | 07:40 |
| ubottu | Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed] | 07:40 |
| jml | s/about it/for 1.16/ | 07:40 |
| lifeless | jml: depends on whether we plan to delete dev6 during 1.17's cycle. | 07:41 |
| lifeless | if so we really have to fix the upgrade for 1.16 | 07:41 |
| lifeless | if not, it would be good but isn't life-ending if we don't, IMO. | 07:41 |
| === mthaddon is now known as afk | ||
| jml | do we plan to delete dev6 during 1.17? | 07:41 |
| lifeless | I think it is reasonably important to make dev6->2a upgrade ok. | 07:41 |
| jml | poolie, thoughts? | 07:41 |
| poolie | jml, i'd be most concerned to know whether it's because of an actual inconsistency in the format | 07:42 |
| poolie | as the patch seemed to indicate | 07:42 |
| lifeless | it is | 07:42 |
| lifeless | a bug, from when we disabled 'subtrees' for the format | 07:42 |
| poolie | so is it correct that 2a doesn't have the subtree flag set? | 07:43 |
| lifeless | yes | 07:43 |
| lifeless | the check in CHKFormat* for subtree during is_compatible orwhatever the method is called, is the bug | 07:44 |
| poolie | what i'm really getting at is, does this reflect any problems in 2a or code that will still be active there | 07:44 |
| poolie | or only for the dev formats? | 07:44 |
| lifeless | dev and 2a | 07:44 |
| lifeless | EOD time; {actually late, startedearly} | 07:45 |
| lifeless | ring me if you need me | 07:45 |
| jml | lifeless, ciao | 07:45 |
| poolie | lifeless: so why | 07:46 |
| poolie | do you say this matters only if we're going to delete dev6 in the 1.17 cycle? | 07:46 |
| bizarrefish | hi | 07:46 |
| bizarrefish | i have a problem - whenever i do a "push" to a master repository(over sftp), having committed changes, the entire repository is transferred and it takes AGES. | 07:47 |
| bizarrefish | why can't bzr just push the files that the server DOESNT have? | 07:47 |
| jml | spiv, your patch @ https://code.edge.launchpad.net/~spiv/bzr/default-stacking-again/+merge/7601 -- the tests it adds are just the test_bzrdir ones? | 07:48 |
| jml | bizarrefish, actually, bzr can be quite good at just pushing things the other side doesn't have | 07:49 |
| bizarrefish | jml: how do i tell it to do that, then? | 07:49 |
| bizarrefish | :-/ | 07:49 |
| jml | bizarrefish, how exactly do you have things set up? | 07:49 |
| bizarrefish | jml: i have a master repository, from which i have branches on different machines | 07:50 |
| bizarrefish | when each machine's repository is modified, i need to be able to push the changes to the master | 07:50 |
| jml | bizarrefish, it sounds like there might be other factors at play, but bzr+ssh is a lot faster than sftp -- particularly with bzr 1.15 or 1.16 | 07:50 |
| jml | bizarrefish, "bzr push sftp://server/master-branch" ? | 07:51 |
| bizarrefish | jml: yeah, that's what i'm doing | 07:51 |
| bizarrefish | the branches were created with: bzr branch sftp://server/master-branch | 07:51 |
| bizarrefish | and the pushes take place as you have stated | 07:51 |
| jml | bizarrefish, is it possible for you to try bzr+ssh? | 07:52 |
| jml | bizarrefish, you just need to have bzr installed on the server -- the more recent the better. | 07:52 |
| bizarrefish | jml: i suppose so, unfortunately the master repo is held on a machine with 32MB of RAM and no swap :-/ | 07:52 |
| jml | I see :) | 07:52 |
| bizarrefish | and svn+ssh didn't take too kindly to being run in such a machine :) | 07:52 |
| jml | bizarrefish, don't run bzr+ssh then | 07:52 |
| bizarrefish | kkl | 07:53 |
| bizarrefish | *k | 07:53 |
| jml | bizarrefish, what makes you think it's sending the whole thing? | 07:53 |
| bizarrefish | jml: oh...hang on, it seems to be because the branches have diverged | 07:54 |
| bizarrefish | :-/ | 07:55 |
| jml | bizarrefish, that makes sense | 07:55 |
| jml | bizarrefish, you need to merge your changes in, rather than simply pushing | 07:55 |
| bizarrefish | jml: yeah, that would normally have preceeded the push | 07:55 |
| jml | ok cool. | 07:56 |
| bizarrefish | the sync sequence: add -> commit -> merge -> commit -> push -> have a nice day | 07:56 |
| spiv | jml: yes | 07:56 |
| spiv | jml: it's a pretty simple patch, despite LP's attempts to make it look more complicated :P | 07:57 |
| jml | spiv, right. | 07:57 |
| jml | spiv, the reason for the confusion is that lp:bzr is a mirrored branch | 07:57 |
| jml | and can be as much as six hours out of date. | 07:57 |
| spiv | Right. And I made my branch off current bzr.dev. | 07:58 |
| jml | of course, bzr's pqm could easily trigger a mirror on commit. | 07:58 |
| mwhudson | clearly mirrored branches are only for hippies | 07:58 |
| jml | or there could be a post-commit hook | 07:58 |
| bizarrefish | what is the difference between doing a bzr update and a bzr merge | 07:58 |
| bizarrefish | ? | 07:58 |
| mwhudson | we really should write a post commit hook that launchpadlibs up a requestMirror | 07:59 |
| mwhudson | bizarrefish: quite a lot | 07:59 |
| jml | mwhudson, yes. | 07:59 |
| mwhudson | bizarrefish: though because you say 'up' i guess you're using checkouts? | 07:59 |
| jml | mwhudson, my plan at EuroPython is to write awesome launchpadlib/bazaar things | 07:59 |
| bizarrefish | mwhudson: no, a branch | 08:00 |
| jml | or to make it falling-off-a-log easy to write such. | 08:00 |
| bizarrefish | is there somewhere which actually details what these things do? | 08:00 |
| mwhudson | jml: cool | 08:01 |
| mwhudson | bizarrefish: then 'up' probably doesn't do anything | 08:01 |
| mwhudson | bizarrefish: the difference between pull and merge is that pull maintains a mirror and merge combines lines of development | 08:01 |
| jml | bizarrefish, 'bzr help merge' etc | 08:01 |
| jml | also... | 08:01 |
| jml | (looking...) | 08:01 |
| jml | (specifically, looking for the doc link on the wiki with my slow net connection) | 08:02 |
| jml | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html | 08:02 |
| jml | http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html | 08:02 |
| bizarrefish | hmm... | 08:03 |
| bizarrefish | This will perform a merge into the working tree, and may generate | 08:03 |
| bizarrefish | conflicts. | 08:03 |
| bizarrefish | ^from bzr help update | 08:03 |
| bizarrefish | so...update == merge?? | 08:03 |
| bizarrefish | :'( | 08:03 |
| mwhudson | if you're not using checkouts, pretend update isn't there | 08:04 |
| jml | bizarrefish, "merge" brings in a divergent line of history | 08:04 |
| mwhudson | (not a fantastic bit of ui) | 08:04 |
| bizarrefish | right...ok | 08:04 |
| jml | bizarrefish, which can cause conflicts | 08:04 |
| jml | bizarrefish, and only changes the working tree -- you still need to commit. | 08:04 |
| bizarrefish | so update brings in history too?? | 08:04 |
| bizarrefish | riiight... | 08:04 |
| bizarrefish | i see | 08:05 |
| jml | bizarrefish, 'update' brings a working tree up to date with a branch. | 08:05 |
| jml | bizarrefish, rather than combining two divergent lines of history (like merge)... | 08:06 |
| poolie | anyhow jml i think we should just merge jelmer's patch | 08:06 |
| jml | it simply updates a working tree | 08:06 |
| jml | poolie, yeah, that's what I was thinking. | 08:06 |
| poolie | and maybe test it fixes it | 08:06 |
| jml | poolie, I'm also going to bring in spiv's patch. | 08:07 |
| bizarrefish | jml: right, so bzr can work in a non-distributed fashion? | 08:08 |
| bizarrefish | (using checkouts/updates instead of branches/merges) | 08:08 |
| jml | because it's small and stacking bugs have given me a scar so deep it makes me look like a lost a samurai fight. | 08:08 |
| jml | bizarrefish, exactly | 08:08 |
| bizarrefish | i see | 08:08 |
| bizarrefish | in that case, i think i should be using checkouts.. | 08:09 |
| jml | bizarrefish, some people also use checkouts / updates in a distributed fashion, but that's very weird and complex and much easier for you to read about than for me to explain :) | 08:09 |
| bizarrefish | is "push" still used to update the main branch? | 08:09 |
| jml | bizarrefish, it sounds like lightweight checkouts would fit your situation better. | 08:10 |
| bizarrefish | yeah...it does. | 08:10 |
| jml | bizarrefish, if you used lightweight checkouts, i.e. 'bzr checkout --lightweight sftp://server/master-branch' ... | 08:10 |
| jml | bizarrefish, then each commit inside that checkout would contact the server and change the master-branch there. | 08:10 |
| jml | bizarrefish, just like a subversion commitc. | 08:11 |
| jml | poolie, is jelmer's patch in bzr.dev yet? | 08:11 |
| bialix | igc1: what's your short term plans for bzr explorer? | 08:11 |
| bizarrefish | hehe this sounds like just what i'm looking for | 08:12 |
| jml | bizarrefish, cool. :) | 08:12 |
| bizarrefish | i've been at this for a couple days | 08:12 |
| bizarrefish | thanks | 08:12 |
| jml | np. | 08:12 |
| jml | poolie, jelmer's patch is missing tests | 08:13 |
| jml | poolie, should we land it sans tests? | 08:14 |
| jml | poolie, or are you willing to write one? | 08:14 |
| poolie | sans gas | 08:14 |
| poolie | i mean sin gas | 08:14 |
| jml | rock & roll. | 08:15 |
| spiv | jml: is it really "easy" to make our pqm (via post-commit or whatever) trigger a mirror? If so, we should absolutely do that, please file a bug or something. I'd love that. | 08:15 |
| spiv | jml: (but first I'd rather you released 1.16 followed by having a pleasant evening's relaxtion basking in the glow of your shiny new release) | 08:16 |
| jml | spiv, http://paste.ubuntu.com/198291/ | 08:16 |
| RenatoSilva | My 1st merge proposal: https://code.launchpad.net/~renatosilva/bzr-email/mail-customization/+merge/7606 | 08:17 |
| RenatoSilva | Thanks to you guys! | 08:17 |
| spiv | jml: somehow that feels like about 2-3 more lines of code than I would expect, but cool nonetheless. | 08:18 |
| spiv | RenatoSilva: glad it's working out for you :) | 08:18 |
| RenatoSilva | spiv: thanks to all of you so helpful :) | 08:20 |
| jml | spiv, actually that also won't work with trunk launchpadlib. | 08:20 |
| jml | spiv, I made a branch to reduce the number of lines you need to cache authentication data | 08:20 |
| jml | spiv, so uhh if you want to make it work... | 08:21 |
| spiv | jml: I see :) | 08:21 |
| jml | you need to look at https://help.launchpad.net/API and change the load() method to be more like what that page suggests. | 08:22 |
| jml | also, that script has the same skeleton as the one I wrote for setting official package branches | 08:22 |
| jml | it probably doesn't *need* its own class :) | 08:22 |
| RenatoSilva | the whole idea of dvcs + personal branches + merge proposals is a very interesting approach | 08:23 |
| jml | RenatoSilva, it's an awesome approach. | 08:23 |
| RenatoSilva | yeah, I mean awesome :) | 08:23 |
| * RenatoSilva gtg | 08:25 | |
| jml | RenatoSilva, bye :) | 08:25 |
| RenatoSilva | bye, tahnks | 08:26 |
| jml | spiv, is your branch merged into trunk? | 08:38 |
| jml | spiv, would you mind submitting it to pqm for 1.16? | 08:38 |
| spiv | jml: It is. I'll submit it. | 08:42 |
| jml | spiv, thanks. | 08:42 |
| spiv | Well, I'll submit the cherrypick I prepared earlier, which is basically the same thing (being a cherrypick). | 08:43 |
| jml | :) | 08:44 |
| bizarrefish | I'm doing a bzr export to another dir, and it's STILL downloading it's up to 200MB now, which is at least twice the size of my checkout | 09:00 |
| bizarrefish | what is going on? | 09:00 |
| bizarrefish | what is this extra datas? | 09:00 |
| Peng_ | It has to download enough history to reconstruct each file. | 09:02 |
| bizarrefish | Peng_: but this is only 3 revisions deep | 09:03 |
| Peng_ | Maybe they're 3 really epic revisions? :D | 09:03 |
| bizarrefish | and i have only added a few hundred bytes worth of files in those revisions | 09:03 |
| bizarrefish | :'( | 09:03 |
| bizarrefish | well, something is epic | 09:03 |
| bizarrefish | the -v flag isn't telling me what it's currently exporting | 09:04 |
| spiv | It may just be that "bzr export" isn't particularly optimised for the network :( | 09:04 |
| bizarrefish | or there is some killer bug | 09:04 |
| spiv | With only 3 revisions, it is likely it has to fetch the full history to construct the current state of every file, though. | 09:05 |
| bizarrefish | i mean, the little "progress bar" isn't even past the first segment at the 200MB mark | 09:05 |
| bizarrefish | this is only 100MB worth of files heere | 09:05 |
| bizarrefish | *here | 09:05 |
| spiv | Yeah, I'd suspect a performance bug. Sorry :( | 09:05 |
| bizarrefish | you will be! | 09:05 |
| spiv | Please file a bug at https://bugs.launchpad.net/bzr | 09:05 |
| * bizarrefish runs up behind spiv | 09:05 | |
| * bizarrefish drags him by the eye into the sea | 09:05 | |
| bizarrefish | *filing* | 09:05 |
| spiv | (Did I just stumble into a role playing channel by mistake?) | 09:06 |
| bizarrefish | spiv: maybe...whos to say? | 09:06 |
| Peng_ | Version Control the Roleplaying Game? | 09:08 |
| spiv | Peng_: The Repository hits you. The Repository hits you. (more) | 09:09 |
| lifeless | power failures suck | 09:10 |
| Peng_ | spiv: I was trying to come up with a joke about a file system or power failure eating your history. | 09:16 |
| * igc1 dinner | 09:37 | |
| lifeless | Peng_: heh. It was only a short one. But I wish I knew why we're getting them. Or did spiv have a power outage too? | 09:39 |
| Peng_ | lifeless: No, it's just that RPGs had come up in the conversation, so I was trying to think of a hoke. | 09:45 |
| Peng_ | joke. Wow. | 09:45 |
| Peng_ | lifeless: You don't have a UPS? | 09:45 |
| lifeless | Peng_: surge protector only at home | 09:47 |
| Peng_ | Oh. You should get one! | 09:50 |
| Peng_ | O' course, half of my power failures are *because* of the UPS freaking out, but... :P | 09:51 |
| lifeless | so my theory is 'ext3 is solid' | 09:51 |
| lifeless | and most power failures are longer than a cheap UPS will survive | 09:51 |
| Peng_ | A cheap UPS can give you time to whine about it and shut down. | 09:52 |
| Peng_ | (depending on how cheap) | 09:52 |
| lifeless | right, but I don't care about that | 09:52 |
| lifeless | the most annoying thing is reconnecting to freenode | 09:52 |
| Peng_ | Use a bouncer/irssi. :D | 09:53 |
| lifeless | I do | 09:53 |
| lifeless | to keep up my link during a power failure I need: | 09:53 |
| lifeless | - UPS | 09:53 |
| lifeless | - firewall | 09:53 |
| lifeless | - adsl modem | 09:53 |
| lifeless | - server | 09:53 |
| lifeless | to be kept running during the failure | 09:53 |
| lifeless | assuming the exchange isn't affected | 09:53 |
| Peng_ | I mean a remote server. | 09:54 |
| lifeless | it is remote. its in the other room | 09:54 |
| lifeless | :) | 09:54 |
| Peng_ | I mean data-canter-with-UPSes remote. :P | 09:54 |
| jml | im in ur irc channel releasin ur software | 10:07 |
| LarstiQ | :) | 10:10 |
| jml | heoastuheoashiseo | 10:14 |
| jml | wrong submit branch :( | 10:14 |
| === mario_ is now known as pygi | ||
| jelmer | poolie: hi | 10:39 |
| jml | jelmer, g'day | 10:49 |
| jelmer | jml: Hey | 10:50 |
| jelmer | jml: Enjoying life as a RM? | 10:50 |
| jml | jelmer, it's certainly keeping me on my toes :) | 10:53 |
| jelmer | :-) | 10:57 |
| jelmer | I saw you submitted my upgrade fix, is a test still necessary for that? | 10:57 |
| jml | jelmer, it would be nice :) | 11:03 |
| jml | jelmer, but it won't go into 1.16 | 11:04 |
| bizarrefish | hi, i'm just playing around with bzr, and am currently at revision 6. i deleted "afile" at this revision, so the file existed at revision 5. | 11:15 |
| bizarrefish | i used this command to retrieve the file from revision 5: http://pastebin.com/m2e6af935 | 11:15 |
| bizarrefish | unfortunately, that produced an error :'( | 11:15 |
| bizarrefish | it's a checkout, not a branch, btw | 11:15 |
| bizarrefish | haha, got it: bzr revert -r5 afile | 11:21 |
| jml | doing a --dry-run before this pqm-submit | 11:32 |
| jtv | lifeless, have you heard of abentley's idea of committing a preview tree? | 11:56 |
| lifeless | jtv: I worked with him on it @ allhands | 11:59 |
| jtv | lifeless: then you're the person I need | 11:59 |
| lifeless | he had working code | 11:59 |
| jtv | lifeless: I'm probably missing something silly. | 12:00 |
| lifeless | jtv: If its quick I can give you a hand now, otherwise I suggest we look at it when you start your day tomorrow - its 9pm here | 12:00 |
| jtv | lifeless: I've got it running without bombing out (believe me, if you know as little as I do about bzrlib that's a lot) | 12:00 |
| jtv | lifeless: well the problem is I've got changes in my transform, and they seem to be going into my tree, but afterwards I open a new Branch on the same URL and don't see any files. | 12:01 |
| lifeless | Branch's don't have files | 12:01 |
| jtv | well, I do branch.repository.revision_tree(NULL_REVISION).walkdirs | 12:02 |
| jtv | (and I cargo-culted that off someone who got it handed down by one of the gurus) | 12:02 |
| lifeless | so | 12:03 |
| lifeless | NULL_REVISION is the empty revision | 12:04 |
| lifeless | it has no content | 12:04 |
| lifeless | I think what you may prefer is 'branch.basis_tree()' | 12:04 |
| jtv | ahhhh | 12:04 |
| jtv | I thought it was the starting revision for changes, and passing NULL_REVISION would give me everything from the beginning of time. | 12:04 |
| jtv | Running updated test. | 12:05 |
| lifeless | tree objects are not deltas | 12:05 |
| lifeless | they are snapshots | 12:05 |
| jtv | So I want the latest revision there. | 12:05 |
| jtv | Now I get "no such revision." | 12:05 |
| lifeless | from basis_tree ? | 12:06 |
| jtv | Oh, wait, basis_tree() is the tree I want to walk. Thank you, duck typing! | 12:06 |
| jtv | lifeless: bit of delay here... the change is suddenly exercising code that never ran in my test. Which is a good sign. :-) | 12:08 |
| * jtv does see certain advantages in a compiler... | 12:09 | |
| jtv | lifeless: more trouble, but I'm sure it's not worth keeping you for. You've helped me a lot though! | 12:09 |
| jml | 'make dist'! | 12:35 |
| lifeless | gnight | 12:36 |
| jml | lifeless, g'night. | 12:37 |
| jml | what do I have to do to get http://doc.bazaar-vcs.org/bzr.1.16/en/release-notes/NEWS.html regenerated? | 12:50 |
| jml | hmm. cronjob. | 12:51 |
| * jml gives it time. | 12:52 | |
| === jml changed the topic of #bzr to: Bazaar version control system | 1.16 released 18th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| jtv | Anyone up for another bzrlib question? | 13:01 |
| jml | don't ask to ask, just ask. | 13:04 |
| jtv | jml: ah yes. I'm doing a walkdirs(), and I'm expecting to find a file a/b/c.txt, but I seem to get only the b and c parts. | 13:12 |
| jml | jtv, walkdirs on which object? | 13:12 |
| jtv | jml: on branch.basis_tree() | 13:12 |
| fullermd | jml: Do you know why the md5/sig links for 1.16 are broken? Are they made by you or LP? | 13:13 |
| jtv | jml: each item in that iteration seems to be (dirname, id): [files] | 13:13 |
| jtv | jml: but for a/b/c.txt, dirname seems to be 'b'. | 13:13 |
| jml | fullermd, the links on which page? | 13:14 |
| jtv | Might be a bug in my code, but trying to figure out what's normal here. | 13:14 |
| jml | jtv, | 13:14 |
| fullermd | jml: https://launchpad.net/bzr/1.16/1.16 | 13:14 |
| jml | fullermd, by "broken", do you mean they 404? | 13:15 |
| jml | fullermd, the md5 link is made by Launchpad, I uploaded the sig files | 13:15 |
| fullermd | Well, they don't give me a MD5 or a signature ;) | 13:15 |
| jml | e18b38e2c4e33203c8f6c9b4029cea7a bzr-1.16.tar.gz | 13:16 |
| jml | http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-1.16.tar.gz/+md5 | 13:16 |
| fullermd | (the rc didn't either) | 13:16 |
| jml | that's what I get | 13:16 |
| jml | fullermd, what do you get? | 13:16 |
| Peng_ | jml: Congrats on the release. | 13:17 |
| jml | Peng_: thanks :) | 13:18 |
| fullermd | Hm. Well, I see the md5 on that page, but the links don't go there (even mod the edge thing) | 13:18 |
| fullermd | http://launchpad.net/bzr/1.16/1.16/+download/bzr-1.16.tar.gz/+md5 has the MD5 | 13:18 |
| fullermd | But the link from https://launchpad.net/bzr/1.16/1.16 goes to http://launchpad.net/bzr/+milestone/1.16/+download/bzr-1.16.tar.gz/+md5 | 13:19 |
| fullermd | (which gives Page Not Found) | 13:19 |
| fullermd | (the link on https://edge.launchpad.net/bzr/1.16/1.16 goes to the right place) | 13:19 |
| fullermd | So I guess it's a LP bug. | 13:20 |
| jml | if it works on the edge page, then it might well be a fixed lp bug | 13:20 |
| * jml checks | 13:20 | |
| jml | http://launchpad.net/bzr/+milestone/1.16/+download/bzr-1.16.tar.gz/+md5 | 13:21 |
| jml | http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-1.16.tar.gz/+md5 | 13:21 |
| fullermd | Yah. | 13:21 |
| jml | fullermd, https://bugs.edge.launchpad.net/launchpad-registry/+bug/383788 | 13:22 |
| ubottu | Launchpad bug 383788 in launchpad-registry "md5 and sig links are broken on the milestone-release page" [High,Fix committed] | 13:22 |
| fullermd | Good enough. | 13:22 |
| === mrevell is now known as mrevell-lunch | ||
| vila | jml: congrats for the release ! | 13:24 |
| jml | vila, thank you :) | 13:24 |
| fullermd | Always nice to get an update to the bzr port submitted before breakfast ;) | 13:27 |
| jml | :) | 13:27 |
| jml | jtv, sorry I got distracted. | 13:33 |
| jtv | jml: ah, I thought it was some form of IRC "RTFM" that I wasn't aware of. :) | 13:34 |
| jml | jtv, I don't know what's going on there, I'm afraid -- I haven't used that API much. | 13:34 |
| bialix | vila: hi | 13:34 |
| jml | jtv, perhaps mucking around with it in a Python interpreter might help figure things out. | 13:34 |
| vila | bialix: hi ! | 13:35 |
| jtv | jml: sort of what I'm doing. | 13:35 |
| bialix | can you recall what the bug #376582 was about? | 13:35 |
| ubottu | Launchpad bug 376582 in bzr "Authentication prompt goes to standard out" [Undecided,Fix released] https://launchpad.net/bugs/376582 | 13:35 |
| jml | jtv, alternatively, it's morning in Toronto soon, so you might be able to get abentley to lend you a hand. | 13:35 |
| bialix | you've fixed it recently | 13:35 |
| jtv | jml: yeah, thing is, it's already dark here. :/ | 13:35 |
| vila | bialix: yes. If we prompt on stdout, users can't redirect output (think diff or log) or they will not see the prompt | 13:36 |
| bialix | this is for password prompt? | 13:36 |
| vila | for any prompt, including password | 13:37 |
| bialix | hmm | 13:37 |
| bialix | I thoiught | 13:37 |
| bialix | I thought bzr uses direct access to console to get user input | 13:37 |
| bialix | at least on win32 | 13:38 |
| bialix | from getpass std module. is not? | 13:38 |
| vila | bialix: hooo, now that you mention it... yes, we were passing the prompt to getpass.getpass() | 13:39 |
| vila | and *there* there may have been some win32 specific code path | 13:40 |
| jtv | jml: \o/ figured it out, tests pass | 13:40 |
| jml | jtv, yay | 13:41 |
| bialix | you talk in past time | 13:41 |
| jtv | jml: just what I was writing into this commit message here... | 13:41 |
| bialix | vila: so today things are different, that's right? | 13:41 |
| jml | g'night all. | 13:42 |
| vila | bialix: yes, stderr is used instead, which should be easier to redirect | 13:45 |
| bialix | it seems like stderr forced to use utf-8 encoding. it's bad and wrong for win32 | 13:46 |
| vila | bialix: Are you sure it's not the default stderr behavior instead ? Anyway, AFAIK, stderr is left untouched as far as UIFactory is concerned... | 13:47 |
| bialix | well, in trace.py | 13:48 |
| bialix | oh no | 13:49 |
| bialix | it seems I have false memory | 13:49 |
| bialix | don't mind | 13:49 |
| bialix | .bzr.log is utf-8 encoded, it's ok | 13:49 |
| === mrevell-lunch is now known as mrevell | ||
| cocooncrash | Hi. I want to writea pre_commit hook which rejects commits if they contain certain words. | 14:08 |
| cocooncrash | I can't work out how to access the diff though. | 14:08 |
| === visik71 is now known as visik7 | ||
| === Nafallo_ is now known as Nafallo | ||
| bialix | jam: good day | 15:27 |
| jam | hi bialix | 15:27 |
| bialix | there is small problem with bzr.exe and some plugins | 15:28 |
| bialix | some plugins require standard python modules that absent in lib/library.zip | 15:28 |
| bialix | do you think it reasonable to add these python modules explicitly? | 15:29 |
| bialix | add to setup.py | 15:29 |
| bialix | or just left this problem to plugins | 15:30 |
| bialix | jam: I'm asking your opinion because 1.16 is out but problem only get worse. Now bzr explorer require additional lib. And I think we should package this plugin into bzr.exe installer. | 15:40 |
| bialix | s/we/you/ | 15:41 |
| jam | if we package bzr-explorer it will bring in the extra libs | 15:41 |
| jam | if we don't then they need todo an installer like bzr-xmloutput does | 15:41 |
| jam | which installs the deps | 15:41 |
| bialix | another solution is to explicitly add required libs to the list of includes in setup.py | 15:42 |
| bialix | and make the life easier for xmloutput too | 15:43 |
| bialix | I can provide the patch for this, but will be nice to have this patch into bzr.exe 1.16 | 15:44 |
| Spabby | please help me, I am stupid, how can I replace a local branch and working copy with the one from the server? I have loads of shitty changes on my local copy and I want to go to the good version on the central branch | 15:47 |
| bialix | jam: ok, it seems you're busy. but I'd like to point your attention on my recent answer in ML about selftest for bzr-svn @windows. | 15:52 |
| jam | bialix: sorry about that. Anyway, to be "nice" we'd have to bundle every possible library so that every possible plugin could work | 15:53 |
| jam | we also don't want to bundle all of GTK if we aren't going to bundle bzr-gtk | 15:53 |
| jam | (PyGTK) | 15:53 |
| jam | so we *can* bundle things | 15:53 |
| jam | but I think it is better to make it easier for plugins to write installers that include dependencies | 15:53 |
| bialix | jam: currently we know which modules are missing. they are few | 15:53 |
| bialix | don't need to bundle the whole universe | 15:54 |
| * bialix disagrees with jam point | 15:54 | |
| jam | bialix: we are missing some modules for *certain* plugins | 15:54 |
| jam | but there are *lots* of potential plugins that potentially need a lot of dependencies | 15:54 |
| bialix | I understand your point, ok, thanks | 15:54 |
| jam | If the list is obvious and small, that is no big deal | 15:55 |
| bialix | ha ha | 15:55 |
| bialix | awilkins just asked about xmloutput | 15:55 |
| jam | but it makes more sense to help the plugins do the work themselves | 15:55 |
| bialix | I know how to work this | 15:56 |
| bialix | I'm asking because it seems there is needed few of modules | 15:56 |
| bialix | today: SimpleXMLRPCServer (for xmloutput) and HTMLparser (for explorer) | 15:57 |
| bialix | this list could grow over the time | 15:57 |
| bialix | but today it's reasonable small | 15:57 |
| bialix | sometimes I think hg approach of bundling all plugins and enable them by user is better suited for this kind of issue | 15:58 |
| jam | igc1: what are you still doing up | 16:00 |
| === afk is now known as mthaddon | ||
| igc1 | jam: several hours at the hospital today and again tomorrow so ... | 16:10 |
| jam | igc1: sorry to hear that. I'm happy to see your activity, sad to see it so late in the day :) | 16:11 |
| jam | then again, it is nice to see you at the same time I'm on | 16:11 |
| jam | all you AU guys have been getting up extra late recently | 16:11 |
| jam | And I'm on a pretty strict "stop at 5" routine | 16:11 |
| igc1 | jam: :-) also, trying to roll out Explorer 0.3 tonight to coincide will the 1.16 release | 16:11 |
| igc1 | jam: but it can wait till tomorrow afternoon | 16:12 |
| igc1 | hopefully bialix will have a chance to test out the latest changes before then | 16:13 |
| bialix | igc1: I think I should write installer for bze explorer | 16:13 |
| igc1 | hi bialix - just talking about you :-) | 16:13 |
| bialix | because explorer require HTNLParser lib that missing in bzr.exe | 16:13 |
| bialix | hi Ian | 16:13 |
| bialix | glad to hear you, sad you're busy with hospital | 16:13 |
| igc1 | bialix: you can wrap that import in a try/except - not required for production code yet | 16:14 |
| bialix | well https://bugs.launchpad.net/bzr-explorer/+bug/389028 | 16:14 |
| ubottu | Launchpad bug 389028 in bzr-explorer "[bzr.exe problem] can't start explorer: bzr: ERROR: No module named HTMLParser " [Undecided,New] | 16:14 |
| igc1 | bialix: tests and appointments - no treatment fortunately | 16:15 |
| bialix | I have solution for this | 16:15 |
| bialix | I can do installer for you | 16:15 |
| bialix | I'm good in writing installers | 16:15 |
| igc1 | bialix: true! but just pulling the branch ought to work if we simply wrap that import | 16:17 |
| bialix | igc1: if you plan to release 0.3 then setup.py need to fix | 16:17 |
| bialix | igc1: let me check | 16:17 |
| igc1 | bialix: see http://bazaar-vcs.org/BzrExplorer (and the roadmap link) | 16:17 |
| bialix | igc1: try-except does not work | 16:18 |
| bialix | igc1: http://pastebin.com/m46f6a876 | 16:18 |
| igc1 | bialix: yeah, 0.3 either 10-15 hours from now or Monday is the plan | 16:18 |
| bialix | so we have to provide installer! | 16:19 |
| hexmode | Any easy way to find the current revision number of a directory? | 16:19 |
| bialix | see file-revision plugin | 16:19 |
| bialix | or use qbrowse command from QBzr plugin | 16:19 |
| hexmode | bzr revno | 16:19 |
| hexmode | doh | 16:20 |
| jam | hexmode: or bzr version-info --all, etc | 16:20 |
| jam | bzr revno does the whole branch | 16:20 |
| jam | just depends what you are looking for | 16:20 |
| hexmode | jam: ok, so if I do "bzr revert -r 28", I would expect bzr revno to show 28. Instead it shows the version of HEAD | 16:22 |
| bialix | igc1: I'm eagerly need support for lightweight checkouts+feature branches workflow in bzr explorer | 16:22 |
| hexmode | (which is 29) | 16:22 |
| bialix | hexmode: you need uncommit | 16:22 |
| jam | hexmode: revert doesn't change the current revision | 16:22 |
| jam | just the content of files | 16:22 |
| hexmode | ok, well, this will do for now, I think.... | 16:23 |
| igc1 | bialix: try rev 53 | 16:24 |
| * bialix pulling | 16:25 | |
| bialix | igc1: IMO acronym BE is already used for Bugs Everywhere | 16:25 |
| SamB | I thought it meant Build Environment | 16:26 |
| SamB | ... but I guess that was in the next channel over, #reactos .. | 16:26 |
| igc1 | hmm - maybe I need to start using BEX instead | 16:26 |
| igc1 | or BzrE or whatever | 16:27 |
| bialix | http://en.wikipedia.org/wiki/Bex | 16:27 |
| bialix | BEX is shorter, I guess | 16:27 |
| bialix | or call it something like REALLY COOL BAZAAR FRONT-END!!! | 16:28 |
| bialix | well, maybe without all this caps | 16:28 |
| igc1 | BzrEx comes up empty enough on google so it will probably do | 16:29 |
| igc1 | so bialix, did that work? | 16:29 |
| bialix | igc1: yes, ii is | 16:29 |
| bialix | it is | 16:29 |
| bialix | it works fine now | 16:30 |
| igc1 | time for me to call it a night | 16:30 |
| bialix | goodnight | 16:30 |
| igc1 | bialix: if you want anything else in 0.3, I need patches | 16:30 |
| bialix | I have problem with opening shred repo | 16:30 |
| bialix | I'm debugin the problem right now | 16:31 |
| igc1 | I'll send out an announcement tomorrow, unless there are show-stoppers | 16:31 |
| bialix | igc1: patch for windows installer will count? | 16:31 |
| bialix | I'll fix setup.py today | 16:32 |
| igc1 | bialix: I'd prefer to see it bundled in the normal Windows installer, for 1.17 | 16:32 |
| bialix | as you wish | 16:32 |
| igc1 | assuming enough people like it, of course | 16:32 |
| igc1 | night all | 16:32 |
| bialix | see you later | 16:33 |
| igc1 | bialix: if you're really keen, please add some windows screen snapshots to http://bazaar-vcs.org/BzrExplorer ! | 16:34 |
| bialix | with pleasure! | 16:34 |
| VSpike | I'm still immensely puzzled by a problem of a file marked as "removed" that when I try to do "bzr mv --after" on it, says it's not versioned. | 16:52 |
| VSpike | I just downloaded the latest Windows bzr in case it was Cygwin specific, but the problem is still there | 16:53 |
| VSpike | Any idea what I can do to solve it? | 16:53 |
| bialix | VSpike: looks like the problem with case of characters in filename | 17:03 |
| bialix | use standard ren command in DOS shell to fix the case of the file | 17:03 |
| VSpike | bialix: I think I managed to fix it, after some fiddling. I ended up with two parent directories versioned at one point | 17:04 |
| VSpike | I saved the code file, reverted both of them and then did bzr mv ... and then overwrote the new location with the saved file | 17:05 |
| bialix | ok | 17:06 |
| Davey | Hola! :) | 17:12 |
| Davey | I'm thinking about maybe switching from SVN to bzr, but I'm curious about 2 things; first: how is the migration path? can I keep my current revision history? and second: what about an equivalent to svn:externals, does it exist? | 17:13 |
| dash | bzr-svn will import your SVN repository pretty easily (in fact, I use bzr to make checkins to our SVN repo at work) | 17:14 |
| dash | svn:externals doesn't have support yet -- I believe support for that (what bzr calls "nested trees") is currently underway | 17:15 |
| bialix | Davey: though if you dare enough you can try scmproj plugin as emulation of svn:externals | 17:16 |
| Davey | yeah... no svn:externals is a deal breaker for me; I have 4 separate third-party libs I have to hack on :/ | 17:17 |
| Davey | I don't think git supports any similar mechanism either mind you | 17:17 |
| dash | Davey: separate checkouts have worked just fine for me :) | 17:18 |
| dash | i'm mainly familiar with using svn for development rater than deployment though | 17:18 |
| bialix | git has submodules | 17:18 |
| bialix | scmproj plugin is roughly did the same | 17:18 |
| bialix | the same as git | 17:18 |
| bialix | but a bit better | 17:18 |
| Davey | the thing that turns me off git, is the whole empty directory not versionable BS... that seems like such a basic thing that if they forgot that I wonder what else they forgot ;) | 17:23 |
| bialix | bzr can track empty dirs | 17:25 |
| Davey | this I know :) | 17:25 |
| bialix | take a look at scmproj | 17:25 |
| Davey | we're just outgrowing SVN; our merging needs are growing as our team grows and we're tackling more ambitious simultaneous projects. We have 4 branches (old-stable, new-stable, enterprise edition, and trunk); eventually, trunk will replace /both/ the new-stable and enterprise editions, but we've got two major projects to add to it immediately, and then there's the re-write coming up shortly. blech :) | 17:25 |
| bialix | maybe it's not very elegant, but it works | 17:25 |
| Davey | you can sit bzr over svn, right? | 17:26 |
| Davey | perhaps that's the solution? :) | 17:26 |
| bialix | you can work with svn repo directly | 17:26 |
| bialix | if you asking this | 17:26 |
| dash | yeah, bzr-svn supports most svn operations -- it doesn't support svn:externals yet, of course | 17:26 |
| bialix | some people just using svn as central server to store bzr branches there | 17:27 |
| Davey | bialix: that's kinda where I'm headed, TBH | 17:27 |
| bialix | scmproj can be used for this | 17:27 |
| * bialix have to go | 17:28 | |
| bialix | I'll glad to help with scmproj if needed | 17:28 |
| bialix | I'll be there later | 17:29 |
| flvr8 | hello. how do i debug bzr-email? i have bzr-email installed and set up as the post-commit hook on the server. the branch.conf in the shared branch on the server specifies the smtp_server. i can send email from the server w/ postfix (echo test | mail 'foo@bah'). but, no email when i commit to the branch, and i don't see any logs anywhere saying what's going wrong. ideas? | 17:49 |
| LarstiQ | flvr8: my guess is that it isn't picking up on the config due to your branch name being different than you think | 17:57 |
| LarstiQ | flvr8: see ~/.bzr.log on the server | 17:57 |
| * LarstiQ dines | 17:58 | |
| flvr8 | LarstiQ: thanks, will see if i find something in there | 17:58 |
| statik | hello bzr hackers! | 18:21 |
| statik | i'm using lp:config-manager to manage a bunch of branches that I depend on in a project. config-manager only lets me specify which branches to pull. Is there a way that I can specify in a bzr url which revision or tag should be pulled? | 18:22 |
| ddaa | Hey. Is there a bzr command I can use for shell scripting that lets me determine whether the tree is clean? | 18:30 |
| ddaa | Oh, I found my answer myself: bzr diff | 18:31 |
| ddaa | if bzr diff -q ; then echo "no change"; else echo "changes found"; fi | 18:32 |
| statik | hey ddaa, it's been a long time. how are you? | 18:32 |
| ddaa | hey statik | 18:32 |
| ddaa | Got a consulting job in a bank hacking some python stuff, resigned because I hated the bank part of the job. Now associate of a web startup that does not have money to give me a pay yet. | 18:33 |
| ddaa | Inherited a "working" webapp without any useful automated test suite. Currently hacking on automated deployment scripts. | 18:34 |
| statik | ddaa, sounds scary but like an adventure | 18:34 |
| ddaa | Missing Canonical. | 18:34 |
| Keybuk | help! | 18:34 |
| Keybuk | bzr push gives me: | 18:34 |
| Keybuk | bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%7Escott/upstart/0.3/.bzr/) | 18:35 |
| Keybuk | is not compatible with | 18:35 |
| Keybuk | KnitPackRepository('file:///home/scott/co/upstart-0.3/.bzr/repository/') | 18:35 |
| Keybuk | different rich-root support | 18:35 |
| ddaa | you need to "bzr upgrade" your local repo | 18:35 |
| Keybuk | my local repo is upgraded, it's the remote repo that's the problem | 18:35 |
| beuno | Keybuk, what does "bzr info" say locally? | 18:37 |
| beuno | the online branch seems to not be rich-root | 18:37 |
| Keybuk | Standalone tree (format: 1.14-rich-root) | 18:37 |
| beuno | Keybuk, so, bzr upgrade --1.14-rich-root lp:~scott/upstart/0.3 | 18:37 |
| beuno | it'll take a while | 18:38 |
| ddaa | statik: I like adventures. | 18:38 |
| Keybuk | bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr' | 18:39 |
| Keybuk | beuno: & | 18:39 |
| Keybuk | ^ even | 18:39 |
| ddaa | use a sftp client to nuke that | 18:39 |
| ToyKeeper | Eh, I've found it faster and easier to delete the launchpad repo and push a new one... upgrade takes forever. | 18:39 |
| Keybuk | ddaa: example? | 18:39 |
| beuno | argh | 18:39 |
| Keybuk | quest scott% sftp bazaar.launchpad.net | 18:40 |
| Keybuk | Connecting to bazaar.launchpad.net... | 18:40 |
| Keybuk | sftp> cd /srv/bazaar.launchpad.net | 18:40 |
| Keybuk | Couldn't stat remote file: No such file or directory | 18:40 |
| Keybuk | ddaa ^ | 18:40 |
| beuno | no, I think Peng uses hitchhiker | 18:40 |
| beuno | I know sftp doesn't work beacuse we have a custom ssh server | 18:41 |
| beuno | abentley, ping? | 18:41 |
| ddaa | in my time, it used to work | 18:41 |
| abentley | beuno: pong | 18:41 |
| beuno | abentley, hello | 18:41 |
| beuno | could you help us out? | 18:41 |
| beuno | 14:39 < Keybuk> bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr' | 18:41 |
| beuno | Keybuk wants to upgrade but it seems he's done it before | 18:42 |
| ddaa | Keybuk: lftp sftp://bazaar.launchpad.net/~bzr/bzr/trunk | 18:42 |
| ddaa | you need to specify the full branch url from the start | 18:42 |
| ddaa | the VFSTP does not provide intermediate listings | 18:42 |
| === Kissaki^0ff is now known as Kissaki | ||
| ddaa | and you need to use lftp because it provides a nice rm -rf feature. | 18:43 |
| abentley | Keybuk: Or hitchkiker lp:~scott/upstart/0.3 rmtree backup.bzr | 18:43 |
| dash | any bzr-eclipse people around? trying to figure out how to import an existing branch into an eclipse project | 18:44 |
| ddaa | yeah, same difference :) | 18:44 |
| * beuno spots verterok hiding in the back | 18:44 | |
| ddaa | and you should annoy rockstar and spiv so they automatically nuke those bzr.backup dirs away | 18:44 |
| ddaa | on session close | 18:44 |
| * verterok start running | 18:44 | |
| verterok | hi dash! | 18:45 |
| dash | verterok: ello | 18:45 |
| dash | so I see "branch as a new project" | 18:45 |
| dash | but not how to use an existing branch | 18:45 |
| dash | there's nothing on eclipse's "import" meny | 18:45 |
| dash | menu | 18:45 |
| verterok | dash: you have a local branch you want to import? | 18:47 |
| dash | yes | 18:47 |
| verterok | dash: it's already an eclipse project? | 18:47 |
| dash | there's eclipse project files in the branch, yeah | 18:47 |
| verterok | dash: just file --> import --> existing project into workspace :) | 18:48 |
| verterok | dash: bzr-eclipse will detect the .bzr at the root of the project, and enable bzr support | 18:48 |
| dash | hmm. this is perhaps complicated by the fact that the branch root doesn't contain a .project file, there are multiple projects in the branch | 18:49 |
| verterok | dash: oh, just like bzr-eclipse itself | 18:50 |
| verterok | dash: it's a limitation of eclipse team support, and I didn't found a solution yet (apart from reimplementing a big chunk of eclipse internals :p) | 18:50 |
| verterok | dash: you can import the projects, and then select all the just imported project: right click --> team --> share | 18:51 |
| dash | hm, ok | 18:51 |
| verterok | dash: choose bazaar for each one, and you'r done :) | 18:51 |
| verterok | dash: maybe adding a wizard to simplify this would help | 18:51 |
| Keybuk | ddaa: thanks, that appears to work :) | 18:52 |
| verterok | dash: would you mind to file a bug with the use case and the problem? | 18:52 |
| dash | verterok: well, just mentioning that it's necessary would help :) | 18:53 |
| dash | looks like that sorted it out | 18:53 |
| verterok | dash: great to know! | 18:53 |
| hazmat | trying to utilize loggerhead for web serving up some repos.. found an example config file in the root of the trunk.. but no directions in readme or otherwise on how to get the the serve-branches cli to utilize the config file.. any ideas? | 18:57 |
| verterok | beuno: ^ | 18:58 |
| beuno | hazmat, it serve-branches doesn't use the config file | 18:58 |
| beuno | did you grab trunk or a release? | 18:58 |
| hazmat | trunk | 18:59 |
| hazmat | i wanted to serve up multiple project branches from a single loggerhead instance.. | 18:59 |
| beuno | hazmat, and they're all in different directories? | 19:00 |
| hazmat | their all under a single dir | 19:00 |
| beuno | hazmat, so just run serve-branches on that dir | 19:00 |
| beuno | and it will serve them | 19:01 |
| hazmat | cool, i see that now.. thanks | 19:01 |
| hazmat | config file threw me off | 19:01 |
| beuno | yeah, we're dropping that very soon | 19:01 |
| dash | hm. anybody know what it takes to build the osx installer for bzr? i'd like to make one for my coworkers with bzr-svn etc included | 19:08 |
| jrwren | is there an equiv of svndumpfilter ? | 19:16 |
| dash | there's bzr-fastimport | 19:17 |
| dash | that may not be what you want though :) | 19:17 |
| kfogel | If I have did "bzr init-repo foo" ages ago, and now have foo/bar/, foo/baz/, foo/qux/, etc, can I just do "mv foo new-name" and everything will still Just Work? | 19:47 |
| Peng_ | FYI, I used hitchhiker to "rename backup.bzr .bzr/backup.bzr". | 19:50 |
| Peng_ | I'm sure LP doesn't appreciate me keeping 2 backups, but whatever. | 19:50 |
| kfogel | Peng_: not sure I understand. "LP" = ? | 19:51 |
| kfogel | launchpad? | 19:51 |
| Peng_ | kfogel: It was in reply to a conversation an hour ago. | 19:52 |
| Peng_ | kfogel: You can rename repositories and branches as much as you want, as long as the branches still exist in the repo. | 19:53 |
| kfogel | Peng_: Ah. So even inside foo/ (or inside "new-name", post-rename), I could do "mv bar bar2; mv qux fish", and everything would still work? | 19:54 |
| Peng_ | kfogel: Some branches may have the full path stored as their parent, push, etc. locations, but if you run into that, it's easy to fix with e.g. "bzr pull --remember". | 19:54 |
| Peng_ | kfogel: Yup. | 19:54 |
| kfogel | great, thanks | 19:54 |
| Peng_ | kfogel: Bazaar just searches up the directory tree for a shared repo. It doesn't care about the names themselves. | 19:54 |
| kfogel | good | 19:55 |
| kfogel | I expected that, but wanted to be sure, before I made some names that might end up being permanent. | 19:55 |
| Peng_ | kfogel: You could even do "mv bar baz/bananas" if you wanted to. :) | 19:55 |
| kfogel | Peng_: so it really just searches upward -- doesn't even need the relative distance to repos root to remain stable? That's great, although perhaps also comes at a bit of a time cost, dunno. | 19:58 |
| Peng_ | kfogel: Yup. It probably does have a cost, but it would be minimal. Just a couple more stat()s among the hundreds/thousands Python'll already wind up doing. | 20:03 |
| kfogel | heh, true | 20:04 |
| === bac` is now known as bac | ||
| flvr8 | i am confused. i have a bzr repository on my server at /opt/bzr/Main/trunk (an import from svn). i checked it out onto my workstation, modified the existing file "foo", and checked it back in. the file "foo" on the server (i.e. in /opt/bzr/Main/trunk) does _not_ contain my changes to it, but checking out the branch from a different machine picks up the change, and running bzr log on "foo" on the server shows my commit messages. so my | 20:36 |
| dash | flvr8: pushing to a remote branch doesn't update its working tree | 20:37 |
| dash | you have to do 'bzr up' to get that | 20:37 |
| Peng_ | You can also use the bzr-push-and-update plugin. | 20:38 |
| flvr8 | ah indeed. so where are those changes persisted until i do that? | 20:39 |
| Peng_ | flvr8: .bzr | 20:43 |
| Peng_ | flvr8: .bzr contains all of the history; the working tree is unnecessary. | 20:43 |
| flvr8 | got it | 20:45 |
| jrwren | bzr up -v is showing me a list of files, but then it dies with "bzr: ERROR: [Error 2] The system cannot find the file specified" | 20:56 |
| Peng_ | More recent versions of bzr will usually be more helpful, including the filename in the error message. | 20:58 |
| jrwren | this is 1.15 | 20:59 |
| Peng_ | Sorry, i dunno. What OS? Are you using a weird file system? | 21:03 |
| jrwren | -Derror at least tells me its a exceptions.WindowsError | 21:03 |
| jrwren | any other debug-flag that may help? | 21:03 |
| Peng_ | Sorry, I dunno. | 21:03 |
| Peng_ | Hopefully someone else does! | 21:03 |
| jrwren | i hope so too | 21:04 |
| jrwren | so who can I call to pay for bazaar support? | 21:17 |
| garyvdm | canonical? | 21:18 |
| garyvdm | jrwren: Please will you pastebin the error. | 21:18 |
| === mario__ is now known as pygi | ||
| jrwren | http://pastebin.ca/1465290 | 21:21 |
| * garyvdm looks | 21:21 | |
| garyvdm | jrwren: I've taken a look - I'm way out of my league. | 21:28 |
| garyvdm | jrwren: Can you rembember what you did, and see if you can reproduce this? | 21:29 |
| garyvdm | jrwren: Whether you can or can't, log a bug on https://bugs.launchpad.net/bzr/+filebug | 21:30 |
| garyvdm | jrwren: Most of the bzr devs will be asleep atm. Maybe jam is around? | 21:31 |
| jam | jrwren: When updating a tree | 21:33 |
| jam | we stage the changes in several steps | 21:33 |
| jam | first we write down what we are about to generate | 21:33 |
| jam | then we move the source files to a pending-deletion dir | 21:33 |
| jam | and move the new files into place | 21:33 |
| jam | then we deleted the pending-deletion | 21:33 |
| jam | that way we can 'rollback' at any time | 21:33 |
| jam | the error I'm seeing looks like it is trying to remove a file from your working tree | 21:34 |
| jam | and put it into limbo | 21:34 |
| jam | but it is already gone | 21:34 |
| jam | any idea how that could happen? | 21:34 |
| jam | (It could also be a permission issue, such that we think the file is gone, but really it is just unaccessible by your user, etc.) | 21:34 |
| garyvdm | Hi jam | 21:35 |
| jam | hi garyvdm | 21:35 |
| jrwren | jam: I had the user run find \! -perm -u=rw -ls | 21:38 |
| jam | jrwren: are you running on Win32 ? cygwin? | 21:38 |
| jrwren | and nothing showed, so she has read write | 21:38 |
| jrwren | yes win32, no cygwin | 21:38 |
| jam | (a bit strange to run 'find' with a WindowsError) | 21:38 |
| jrwren | well, cygwin is installed, but we are using bzr from MSI | 21:39 |
| jam | sure | 21:39 |
| jam | so... I think I see the prob | 21:39 |
| jrwren | will the file list of changes show per each file, or at the end | 21:39 |
| jrwren | becuase I confirmed that every file in the list does exist on the file system. | 21:39 |
| jrwren | i mean, every file that is listed as M or -D | 21:40 |
| jam | we have this block http://pastebin.ca/1465315 | 21:40 |
| jam | Which is trying to handle the ENOENT case | 21:40 |
| jam | however, you are getting a WindowsError that is not ENOENT | 21:40 |
| jam | for whatever crazy reason... :( | 21:40 |
| jrwren | from what file is that, is there an easy way for me to log that full_path value on that call? or can I go hack that file? | 21:41 |
| jam | jrwren: you might try doing 'touch myfile' before doing the 'bzr up' | 21:41 |
| jam | jrwren: you are using the installed version, so it is 'compiled' python | 21:41 |
| jrwren | jam: so you think it is the last file in that list? ok. | 21:41 |
| jam | If you are comfortable grabbing the source, I can do it from there | 21:41 |
| jam | jrwren: I honestly don't know when that list is generated versus when the renames, etc are done | 21:42 |
| jam | but it is a good first start :) | 21:42 |
| jrwren | gah, cursed compiled python. I'm comfortable with installing python and the http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-1.16-1.win32-py2.6.exe | 21:43 |
| jam | jrwren: so... it looks like the list of what will be printed is generated *before* it starts touching your working tree | 21:44 |
| jam | so the last item on that list *should indeed* be the item causing problems | 21:44 |
| jam | jrwren: well py2.6 will also be the "compiled" version, IIRC | 21:45 |
| jam | however, you can download the tarball from there | 21:45 |
| jam | and run from source | 21:45 |
| jam | we have some compiled externsions that are useful but optional | 21:45 |
| jam | and shouldn't have an effect here | 21:45 |
| jam | jrwren: and if you want to write a patch that adds a "trace.mutter('failed to rename XXX')" as part of the exception clauses | 21:45 |
| jam | that would be a good start to making this easier to debug | 21:46 |
| jam | or even trace.note()/trace.warning() | 21:46 |
| jrwren | jam: I just tried to touch, but it didn't work. | 21:46 |
| jam | k | 21:46 |
| jrwren | i'm stealing a file copy of the branch so that I can try it myself instead of on her computer. | 21:47 |
| jam | jrwren: sure | 21:47 |
| jam | good idea | 21:47 |
| flvr8 | anybody know how to rescue a broken svn repo? there's something in one of the modules that i'm importing which is causing very bad things to happen: https://bugs.launchpad.net/bzr-svn/+bug/380621 | 21:58 |
| ubottu | Launchpad bug 380621 in bzr-svn "pull from svn repo gives: bzr: ERROR: base checksum mismatch: " [Undecided,Incomplete] | 21:58 |
| flvr8 | (i'm the latter comments in there, but kevin - the original reporter - works on a different project at my company. i wonder if somehow our svn repo got snarled) | 22:00 |
| === mwhudson_ is now known as mwhudson | ||
| jam | flvr8: did someone manually edit the svn repo? | 22:05 |
| jam | like changing the author/committer/message/timestamp on an old rev | 22:05 |
| jam | use svndumpfilter that sort of thing? | 22:05 |
| jam | anyway, I would say "start from scratch" but that can be ugly, I realize | 22:05 |
| flvr8 | hm, no manual edits that i know of, but it is on a managed host, so there's no telling | 22:06 |
| flvr8 | i.e. the host may have "fixed" an issue one of the developers were having using similar | 22:07 |
| flvr8 | hm, i ran svnadmin verify on the svn repository and it reports that all is well | 22:24 |
| jam | btw vila, what are you still doing up? | 22:24 |
| vila | jam: writing the cover letter :-D I had a hell of a day (starting with a hell of a last night :) and then crashes all around... | 22:25 |
| * vila fall asleekl;'mm .f .bh,hmasldf b. | 22:26 | |
| jam | vila: sleep well | 22:27 |
| jrwren | huge kudos to the addition of the nonadmin zip file build for windows! I love it! | 22:31 |
| lifeless | moin | 22:39 |
| beuno | hiya lifeless | 22:39 |
| jelmer | hey lifeless, beuno | 22:40 |
| beuno | heya jelmer | 22:40 |
| thumper | lifeless: can I skype you? I have a few questions | 22:43 |
| lifeless | thumper: what about? | 22:52 |
| thumper | how bad inconsistent parents are | 22:52 |
| thumper | I had reconciled my LP repo | 22:52 |
| thumper | and created the 2a repo from it | 22:52 |
| thumper | but later pulling into my packs repo to bring it up to day | 22:52 |
| thumper | date | 22:52 |
| thumper | introduced more inconsistent parents | 22:53 |
| thumper | now I'm unsure of the state of the 2a core repo | 22:53 |
| lifeless | so | 22:53 |
| lifeless | they affect annotate and per-file log | 22:53 |
| lifeless | the data that had be reconciled wouldn't have been altered by the pull | 22:54 |
| lifeless | you can't [yet] check and reconcile only some revisions, but that is planned | 22:54 |
| thumper | why are we still getting inconsistent parents being generated? I don't get it | 22:54 |
| lifeless | if you check with -v it should report them | 22:55 |
| lifeless | if their revnos are recent, you shouldn't be getting them, so its a matter of tracking down why. | 22:55 |
| lifeless | if they were created by PQM, PQM hadn't been upgraded for some time | 22:55 |
| thumper | I had reconciled, I ran a check on the packs repo and found 2918 inconsistent parents | 22:56 |
| thumper | I reconciled just before all hands | 22:56 |
| thumper | so the new revisions would have been since then | 22:56 |
| thumper | how can we propagate the proper parents ? | 22:57 |
| lifeless | they have to be right before pull/merge/push or they don't propogate | 22:57 |
| lifeless | and you have to reconcile to fix | 22:58 |
| thumper | if I use -v will it tell me which revids are inconsistent? | 22:58 |
| thumper | what about reconcile -v? | 22:58 |
| thumper | if there is a flag like that | 22:58 |
| thumper | I'm concerned with the new 2a repo for LP and making it good and clean | 22:59 |
| thumper | however our deadline for getting it up and distributed to users was 2 days ago :) | 22:59 |
| thumper | and any delay hurts us more... | 22:59 |
| thumper | it appears that someone(s) are still generating revisions with inconsistent parents | 23:00 |
| thumper | pqm is on 1.13 I think | 23:00 |
| lifeless | yes, its very traumatic at the moment. I think I've mentioned this :P | 23:00 |
| thumper | ATM | 23:00 |
| lifeless | pqm is doing 1.16 new | 23:00 |
| lifeless | upgaded yesterday as part of the lp upgrade process | 23:00 |
| thumper | ok | 23:01 |
| lifeless | 1.16rc1 specifically | 23:01 |
| lifeless | doing a reconcile is technically a choice | 23:01 |
| lifeless | it won't [anymore] affect fetch. | 23:01 |
| thumper | as of when? | 23:02 |
| lifeless | it now only affects log FILE, annotate & pack. | 23:02 |
| thumper | why pack? | 23:02 |
| ddaa | Hello. What's the recommended way to get the revid of a lightweight checkout? | 23:02 |
| lifeless | around 1.15, but 2a is definitely safe. | 23:02 |
| ddaa | I presume "bzr log --show-ids" is not the righ approach as it gives the revid of the branch, which is different if the checkout is out of date. | 23:02 |
| lifeless | ddaa: of the tree? bzrlib.workingtree.WorkingTree.open(PATH).last_revision() | 23:02 |
| ddaa | lifeless: anything that I can run easily from the shell? | 23:03 |
| lifeless | thumper: because pack sorts by topology | 23:03 |
| lifeless | ddaa: python -c !$ | 23:03 |
| ddaa | writing rollout scripts in in sh | 23:03 |
| ddaa | uh | 23:03 |
| lifeless | ddaa: or perhaps bzr version-info | 23:03 |
| ddaa | oh, I'll look into that | 23:04 |
| lifeless | thumper: it won't make pack /wrong/ but it can affecct compression | 23:05 |
| * thumper nods | 23:07 | |
| ddaa | lifeless: thanks, so the answer is "bzr version-info --custom --template '{revision_id}\n' [PATH]" | 23:10 |
| lifeless | ddaa: :) | 23:11 |
| ddaa | mwhudson: slacker | 23:21 |
| ddaa | (re: identi.ca) | 23:21 |
| mwhudson | :) | 23:21 |
| mwhudson | ddaa: i went to bed at 12 and got up 6:30, tim went to bed at 3 and got up at 8, jono went to bed at 1 and up at 7... | 23:22 |
| === mthaddon is now known as afk | ||
| === afk is now known as mthaddon | ||
| ddaa | mwhudson: and then, you still feel the need to justify yourself? :) | 23:24 |
| garyvdm | lifeless: Any sort of querying of WorkingTree.inventory requires a lock on WorkingTree. Is there a way that I can create a in memory copy of WorkingTree.inventory so that I don't have to hold a lock? | 23:31 |
| === Kissaki is now known as Kissaki^0ff | ||
| garyvdm | I found .copy(). I'm going to give that a try. | 23:35 |
| lifeless | garyvdm: so, as I said before, I'm not sure that inventory is the right tool for what you're doing. However, yes, you can use .copy, but its extremely wasteful. Dirstate trees don't even /need/ an inventory to do most operations. | 23:40 |
| garyvdm | lifeless: Oh - I did not realise that there was a tree.iter_children. - Is that what think I should be using? | 23:44 |
| lifeless | garyvdm: well it seems to me like you want to cache a bunch of data that bzr normally accessess just-in-time | 23:45 |
| garyvdm | For WorkingTrees - Yes, but for RevisionTrees - no. | 23:46 |
| lifeless | garyvdm: tree.walkdirs for instance can be very fast | 23:48 |
| lifeless | garyvdm: anyhow; as long as you don't use .copy on a RevisionTree.inventory it is probably ok | 23:49 |
| lifeless | on a 2a format, .copy has to do scatter-gather IO across all the nodes for the tree. | 23:49 |
| garyvdm | lifeless: Ok. tree.walkdirs may work for me. | 23:50 |
| lifeless | garyvdm: I'm mainly worried about performance for historical revisions | 23:52 |
| lifeless | garyvdm: its quite a bit cheaper on massive trees to be doing on-demand loading | 23:53 |
| jelmer | spiv, lifeless: Shouldn't bug 252945 be fixed by your recent hpss work? | 23:56 |
| ubottu | Launchpad bug 252945 in bzr ""bzr push" uploads 1-2 MB just to send a one-line change revision" [Undecided,New] https://launchpad.net/bugs/252945 | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!