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