=== wallyworld is now known as rambo === rambo is now known as wallyworld [03:01] hi [03:02] Hey poolie. :-) [04:55] * AfC is wondering why the Inserting stream: Estimate keeps growing slowly. Can't you just cache the current history size in the tip record? [05:01] It's just checking to see if you're paying attention ;) [05:30] AfC: it grows as we find more stuff you don't have [05:30] lifeless: Right. I get that. But [05:30] lifeless: would it be possible to a) cache total size (any commit knows this) + [05:31] lifeless: or s/size # of revisions or.../ [05:31] lifeless: + b) express a % of that size that's been reached? [05:31] ie, just express the total target; if we get there zooooooooom fast, great! if we chug slowly, well, fine [05:31] its not obvious to me how to make that work with the arbitrary DAGs that occur [05:32] including partial history scenarios [05:32] but showing a/b of a moving target is ... well, anyway I wouldn't be here offering the thought otherwise [05:32] {shrug} just do revision count? [05:32] anyway [05:32] so revision count [05:32] we send revisions last [05:33] doing revision count results in no change for 95% of the push/pull, then a sudden blat and its done. [05:33] I'm not saying the current impl is ideal [05:34] lifeless: no informatio of "this tip := this many texts" or something like that? [05:34] (if not, pity) [05:34] anyway, if there was something reasonably static that isn't known at *download* time but IS known at (say) *commit* time then perhaps it would be "more" useful... [05:35] as a y in x/y [05:35] so, if you include a vector clock in the rev [05:35] purely informational [05:35] yeah [05:35] we could in principle use it - but the problem is that the db storing texts etc is not one dimensional [05:36] well, fair enough [05:36] pity though [05:36] so there is no local reference to tell us if we have 0% or 100% of each vector until we do graph traversal [05:36] thanks for taking the time to explain [05:36] its possible something can be done - but as I say, its non obvious to me what shape that would take [07:28] hi all [07:44] Hi, all. [07:44] https://bugs.launchpad.net/bzr/+bug/172383 [07:45] Is this bug still in bzr? [07:46] My fellow worker can successfully add decomposed dirname recursively with bzr-2.3b5 on HFS+. [07:48] inada-n: Hey Naoki ! AFAIK, there are still grey areas there, so tell him to report any bug it encounters [07:49] OKey. I'll ask him to use bzr-2.3b5 continually. [07:49] inada-n: thanks === Ramosa_ is now known as Ramosa [09:56] Greetings === Ursinha-afk is now known as Ursinha === zyga is now known as zyga-coffee === zyga-coffee is now known as zyga [13:23] hi [13:23] I've got merging question. [13:24] I have 2 branches not related to each other. let's assume both are local master branches. [13:24] let's name their folder /b1, /b2 [13:25] I want to create a folder /stuff [13:25] and to merge under it both b1 and b2, so I have ls /stuff: b1, b2, [13:25] but so that b1,b2 are the contents of /b1, /b2 [13:25] hopefully all the commits are inside the rev. history of /stuff [13:26] is this possible ? [13:27] sobersabre: yes [13:27] :) [13:28] Quick question, what format are b1 and b2 in? [13:28] In particular whether they are rich-root or poor-root [13:28] in b1 : bzr join b2 (with recent enough bzr formats as maxb points out) [13:29] sobersabre: 'join' will put b2 contents directly in b1 so move stuff around in subdirs if you prefer [13:29] I'm slightly unsure what would happen if both branches originated in poor-root formats [13:29] maxb: further merges won't work very well IIRC [13:29] But, would the join even work? [13:32] I think so [13:32] ...or not but in this case there should be an error message [13:33] bzr: ERROR: File id {TREE_ROOT} already exists in inventory as InventoryDirectory('TREE_ROOT', u'p1', parent_id='tree_root-20110125133320-07vztq0cyp7mymdc-1', revision=None) [13:34] O_o [13:34] format ? [13:34] that was attempting to join two pack-0.92 subdirs into a 2a [13:35] ouch, cross-format ! now you're naughty [14:01] jelmer: Hi. So, the reason for the bzr-git test failures is that bzr core has changed from emitting "Created tag foo." on stdout to emitting it on stderr in 2.3 [14:17] jelmer: And the dulwich test failures appear to be because urlparse actually behaves differently there [14:21] maxb: jelmer is on the move these days, he will be hard to reach [14:21] np, I'll file bugs too, was just opportunistically continuing a conversation from yesterday [14:22] ok, I wanted to make sure you were waiting in vain ;) [14:30] File bug 707438 and bug 707434 ftr [14:30] Launchpad bug 707438 in Dulwich "dulwich.client.get_transport_and_path sensitive to change in Python's urlparse.urlparse behaviour, causes test failures on <= karmic" [Undecided,New] https://launchpad.net/bugs/707438 [14:30] Launchpad bug 707434 in Bazaar Git Plugin "bzr-git tests fail against bzr <= 2.2" [Undecided,New] https://launchpad.net/bugs/707434 === Ursinha is now known as Ursinha-lunch [15:59] morning all [15:59] I'm just giving Empathy a try, so sorry if I miss notifications, etc. [16:05] hey vila, can you send me a tell? I want to make sure I get it [16:05] jam: morning jam ! [16:06] one more without your nick [16:06] I think it pops up a little bubble, rather than playing a noise, and I tend to just ignore it. :( [16:06] by the way, do you have a patch for the wt2 failing test ? I saw a brief mail exchange with jelmer but can't find a mp for it [16:09] vila: no mp, I just posted something to the mailing list, and wanted to get feedback on it [16:09] I can turn it into something, I guess [16:11] wow... I'm installing all of the launchpad dependencies, and suddenly *all* of my theming died [16:12] sounds unrelated from this side of the ocean... [16:12] well, going back into "Appearance" fixed it all back [16:13] vila: I would think it would be unrelated, except launchpad-dependencies installs about 50 packages [16:13] and messes with your /etc/hosts and all sorts of stuff [16:13] (rocketfuel-setup) [16:13] yeah, too much to chew at once :) === beuno is now known as beuno-lunch === Ursinha-lunch is now known as Ursinha [16:56] vila: https://code.launchpad.net/~jameinel/bzr/wt-case-insensitive/+merge/47423 [16:57] waiting for lp to refresh... [16:57] it's failing on OSX too [16:58] vila: refreshed [16:58] Please test it on Mac OSX [16:58] I'm currently logged into Ubuntu, so I can't guarantee that the change fixes it for Windows [16:58] but if it does for OSX, then I'm pretty sure [16:59] vila: do you remember how to configure gwibber for status.canonical.com? [16:59] can you remind me the -s invocation ? [16:59] I rebuilt my install, to give it more space [16:59] vila: "bzr selftest -s bt.per_workingtree case_sensitive" [17:00] fixed :) [17:01] jam: aproved [17:05] vila: I seem to remember I needed to add a special ppa to get status.canonical.com to work, but I don't remember what it was [17:05] oh, yeah, sorry miss that [17:05] I use gwibber-bugs-unstable here [17:06] and install gwibber, gwibber-service and gwibber-service-statusnet [17:07] 2.91.2-0maverick1 for all of them [17:07] vila: ppa:gwibber-bugs/unstable ? [17:07] I don't remember the precise invocation [17:08] the url I have is http://ppa.lp.net/gwibber-bugs/unstable so yeah, this should work [17:17] Hm. I am noticing that for directories, loggerhead displays the revision and timestamp of when they were created as the "last changed" [17:17] I suppose that figuring out the last change in a subtree is possibly non-trivial in bzr? [17:30] maxb: correct [17:33] I wonder if it would actually be more accurate to show nothing in the last-changed columns in loggerhead there [17:33] maxb: we don't store a recursive 'last-modified' by directory [17:33] it would be faster :) [17:34] The thing is, being told that the "src" directory of your active project last changed n revision 2 in 2003 is manifestly a lie [17:34] maxb: that was the last time that the directory object itself was changed [17:34] not a lie [17:34] just probably not what people expect [17:35] maxb: almost all the file systems I know of do the same... [17:35] vila: true enough. 'ls' reports similar info [17:35] * maxb is attempting to sell bzr at work, and is anticipating complaints vs. svn [17:35] poor reason to do it too, but still, kind of explain why we did the same [17:37] What does change a directory other than creating it? [17:39] maxb: adding, removing, renaming a file [17:39] *ah* [17:39] at least on file systems [17:40] hmm [17:40] bzr seems to consider changes to children don't count at all === beuno-lunch is now known as beuno === Ursinha-afk is now known as Ursinha [17:45] yes, like file systems: mkdir -p foo; cd foo ; touch bar ; ls -al; sleep 60 ; touch bar; ls -al; cd .. [17:54] maxb: vila should have said "adding, removing, renaming *the directory*" [17:55] jam: adding a children *to* the directory isn't seen as a change ? Argh [17:55] vila: nope [17:55] * vila bangs head and EOD [18:38] Using Gentoo Linux package emacs-vcs, lightweight checkout bzr trunk, 117M. For the last week or so bzr pull's have been gigantic, sometimes GB. [18:39] #emacs suggested I ask here. Have deleted checkout and am rerunning, will see if building tree runs quicker. [18:42] Fresh checkout worked very well. Any tip I can pass along to other Gentoo users about why the checkout might have gotten to that state? [18:46] jfkw: Are you pulling over a smart or dumb transport? [18:47] i.e. what is the pull source URL [18:49] abentley, Hey [18:49] cody-somerville, hey. [18:50] abentley, What would make bzr-pipeline's sync-pipeline think a new branch needs to be created for a pipe? Its currently failing for me trying to create a new pipe that already exists remotely. [18:51] cody-somerville, if there's no pipe with the correct name in the remote pipeline, it creates it. [18:51] $ bzr sync-pipeline [18:51] Creating new pipe "sg-2.x" [18:51] bzr: ERROR: Branch in the way at bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/sg-2.x/. [18:52] cody-somerville, Right. [18:52] I've already synced sg-2.x before as you can see [18:53] cody-somerville, No, that demonstrates that you've push or synced it, and if you only pushed it, then it won't be part of the remote pipeline. [18:53] abentley, Well, I did sync it. [18:54] abentley, so should I just delete the sg-2.x branch on launchpad? [18:54] cody-somerville, what's another pipe in the remote pipeline? [18:54] bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/misc-oem-patches/ is the pipe before sg-2.x [18:55] maxb: /usr/portage/distfiles/bzr-src/emacs-trunk $ bzr info Lightweight checkout (format: 2a) Location: light checkout root: . checkout of branch: bzr://bzr.savannah.gnu.org/emacs/trunk/ shared repository: bzr://bzr.savannah.gnu.org/emacs/ [18:55] hmm, so it is a smart server [18:55] In that case, this goes beyond my knowledge [18:57] cody-somerville, does "bzr show-pipeline" show the exact same list as "bzr show-pipeline bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/misc-oem-patches/" ? [19:00] abentley, Yes except for the new pipe I'm trying to sync called default-lb-root-command-to-sudo-linux32-for-i386 [19:01] cody-somerville, is that at the beginning of the pipeline? [19:01] abentley, no, after the first [19:02] cody-somerville, I can't see anything wrong with your setup. I guess this is a bug that I didn't know about. [19:03] abentley, Anything I can do to debug? [19:05] cody-somerville, run "bzr missing" to compare your local and remote copies of sg-2.x [19:07] I had to use "bzr missing :push" and I have 2 extra revisions locally [19:09] cody-somerville, could you re-run sync-pipeline with "bzr -Derror"? [19:10] http://pastebin.ubuntu.com/558218/ [19:13] cody-somerville, thanks. I don't think I can do much more without a way to reproduce it. I'm guessing they're big branches? [19:14] nope [19:16] cody-somerville, okay, could you upload exact copies of your pipes to devpad? [19:17] abentley, using sync-pipeline? lol [19:17] cody-somerville, no, file-by-file exact copies. [19:18] abentley, okay if I upload a tarball? [19:18] cody-somerville, sounds good. [19:21] cody-somerville, include the shared repository, if there is one. [19:25] abentley, okay, all uploaded to my home dir on devpad [19:26] cody-somerville, thanks. I've been mirroring the remote pipeline. Give me a sec to verify it. [19:38] abentley, hmm... I'm going through the code in pdb [19:39] abentley, for some reason, remote_manager.list_pipes() is only returning the first pipe in the pipeline [19:40] cody-somerville, and the first pipe is "live-build"? [19:40] abentley, yup [19:40] (Pdb) p remote_pipes [19:40] [(u'live-build', RemoteBranch(bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/live-build/))] [19:41] cody-somerville, indeed, live-build does not link to the next pipe in the pipeline. [19:43] cody-somerville, I am going to update the branch.conf in "live-build". [19:44] I wonder what could have caused that. [19:45] abentley, btw, I really enjoy using pipeline (even though I'm still figuring out the best ways to use it). [19:45] cody-somerville, I would guess a new copy of live-build was pushed at some point. [19:46] cody-somerville, I'm glad. That's certainly a big pipeline you've got goingl. [19:47] cody-somerville, anyhow, I think it's fixed. Please try sync-pipeline. [19:47] abentley, since it seems like the other pipes in the pipeline have all the info about the rest of the pipeline, maybe it would be possible for sync-pipeline to figure out how to repair the remote pipeline in cases like this? [19:48] cody-somerville, yes, it should. Right now, it doesn't even notice the inconsistency, though. I've got a bug for that. [19:49] abentley, Does it look like I'm using pipes right? What I'm doing is creating a new pipe for each patch I create on top of upstream like in the example. [19:50] abentley, I think having the ability to rebase would be useful FYI [19:51] cody-somerville, yes, it looks like you're using it "right", but I don't do packaging, so please let me know if my ideas are impractical. [19:51] abentley, I'm not using this so much for managing the packaging but instead patches directly against upstream that I want to submit upstream [19:52] abentley, I have a single pipe at the end that I use to maintain my changes to the debian packaging provided by upstream and document changes made in my pipes. [19:53] I think I might want to start modify the changelog in each individual pipe and then merging the changelog as I go along so that when I remove a pipe (say upstream accepted it), I can easily merge out the changelog entry along with any straggling delta. [19:53] cody-somerville, do the patches depend on one another? [19:53] abentley, most don't [19:56] cody-somerville, I'm not sure pipeline is the correct tool, then. I would try to maintain independent patches as separate branches. What do you like about pipeline for what you're doing? [19:57] abentley, bzr pump :-) [19:58] abentley, and bzr sync-pipeline [19:58] abentley, and bzr show-pipeline [19:58] abentley, and bzr add-pipe is fast [19:58] abentley, and I can decide where in the pipeline I want my patch to be very easily [19:58] abentley, and can easily see the changes introduced in a range of pipes [19:59] cody-somerville, so for your use case, it would be good to have a tool designed to manage an integration branch. [20:00] and I know that pipes closer to the top are closer to upstream's branch and pipes lower in the pipe are further diverged. [20:01] cody-somerville, where each patch was an independent branch, but they still all got merged into the integration branch in a pump-like operation. [20:01] abentley, I like how I only have one directory with everything in it [20:01] cody-somerville, pipeline could be that tool, but the UI could become a nightmare if done poorly. [20:02] Which is why I haven't done it yet. [20:02] I personally think pipeline should become a part of bzr [20:02] cody-somerville, apparently they're looking at something like that. [20:03] cody-somerville, You can also get fast branching by explicitly using a shared repository and a lightweight checkout. [20:05] cody-somerville, you can get branches-all-in-one-directory with the "bzr-colo" plugin. [20:06] cody-somerville, not to discourage you from using bzr-pipeline, just to let you know that not everything is pipeline-specific. [20:06] ok [20:07] cody-somerville, In fact, I tried to use existing tech wherever I could. [20:17] cody-somerville, anyhow, is sync-pipeline working properly now? [20:29] abentley, yup [20:29] cody-somerville, great. [20:56] I have some tags in my branch that I do not want, I removed them but they come again and again through pull/push. What can I do? [21:07] vanguard: the only way to get rid of a tag is to explicitly delete them from all branches in which they exist [21:09] and not pull/push in the meantime? [21:09] how do I get rid of the tag in lp? [21:10] bzr tag -d lp:foo --delete tagname [21:57] maxb: thanks, I'll try that. I just have the branches on three machines myself, +lp + whoever else ... endeavor to go :D [23:08] woo, fixed dulwich except on lpia [23:30] maxb: what's funky about lpia? [23:30] (just wondering why it would be fixed everywhere but there)