| bob2 | uh-huh | 00:00 |
|---|---|---|
| malibu | bob2: I have many files (work related) that I don't want out there.. | 00:00 |
| jpds | malibu: rdiff-backup. | 00:00 |
| bob2 | tahoe in no way implies storing data with random people | 00:00 |
| bob2 | if you choose to do so, they are carefully encrypted | 00:01 |
| wgrant | rdiff-backup is awesome. | 00:01 |
| bob2 | it does sound more like you want unison, though | 00:01 |
| malibu | bob2: Lol.. well I saw "cloud" in the summary and it turned me off@! | 00:02 |
| malibu | Yes, unison does sound interesting | 00:06 |
| lifeless | poolie: http://github.com/droundy/iolaus looks interestingish | 00:10 |
| poolie | interesting | 00:19 |
| mathrick | yep! | 00:22 |
| malibu | the thing that makes me leery about unison (and now I remember being here before) is that it points to some guys user directory to download it | 00:23 |
| malibu | Although the documentation seems to be really good | 00:23 |
| jelmer | mwhudson, pong | 00:32 |
| mwhudson | jelmer: hi | 00:32 |
| jelmer | hello | 00:32 |
| mwhudson | jelmer: i'd very much like a reply to the latest "plan for incremental code imports" mail | 00:32 |
| jelmer | mwhudson, a recent one, from after friday ? | 00:34 |
| mwhudson | jelmer: hm, i don't have anything from you on the subject since tuesday | 00:37 |
| mwhudson | jelmer: can you resent your latest? | 00:37 |
| jelmer | perhaps I missed an email | 00:38 |
| * jelmer looks | 00:38 | |
| mwhudson | jelmer: lots of worrying about topological sorting | 00:38 |
| ed-209 | I'm writing a small app in 2.7.0 that generates a SQLite DB but chokes when I try to add foreign key constraints. What version of SQLite DBs does Mono.Data.SqliteClient generate? | 00:39 |
| Peng | ed-209: Wrong channel? | 00:39 |
| ed-209 | oh ya | 00:39 |
| ed-209 | Reading is Fundamental I guess | 00:39 |
| jelmer | mwhudson, found it | 00:42 |
| mwhudson | jelmer: anything to talk about now? | 00:47 |
| jelmer | mwhudson, I'm replying to your email | 00:48 |
| mwhudson | jelmer: cool | 00:49 |
| jelmer | also, I just switched to dvorak - so a bit slow still :) | 00:49 |
| Peng | Enjoying it so far? | 00:50 |
| mwhudson | :-) | 00:51 |
| jelmer | peng: typing 8 times slower than usual is *really* frustrating | 00:54 |
| jelmer | hopefully it'll get better soon | 00:54 |
| jelmer | sent | 00:55 |
| jelmer | mwhudson, ^ | 00:55 |
| Peng | If I typed 8 times slower than usual, wow, I couldn't use a computer at all. | 00:56 |
| mwhudson | jelmer: thanks | 00:57 |
| jelmer | mwhudson, that's exactly what it feels like | 00:57 |
| mwhudson | jelmer: you can't even talk to the right person in irc! | 00:57 |
| jelmer | s/mwhudson/peng | 00:57 |
| jelmer | mwhudson, :) | 00:57 |
| meoblast001 | hi | 01:01 |
| wgrant | I tried to switch to Dvorak a couple of years ago, but never got really fast, so I switched back. | 01:01 |
| meoblast001 | i'm told git does not store old revisions of binary files, is this true for Bazaar? | 01:02 |
| wgrant | But now whenever I think about typing, I unknowingly switch to Dvorak. | 01:02 |
| Peng | meoblast001: Bazaar does not distinguish between text and binary files. | 01:02 |
| maxb | meoblast001: I don't think that's true of git, let alone bazaar | 01:02 |
| meoblast001 | ah, so i've been lied to | 01:03 |
| Peng | Indeed. I'd be very surprised if Git did that. | 01:03 |
| wgrant | It would make Git pretty useless. | 01:03 |
| jelmer | wgrant, this is my 4th try :) | 01:03 |
| lifeless | spiv: ping | 01:05 |
| igc | hi all | 01:05 |
| lifeless | spiv: are you on today? I'd like to point you at some polish on the merge hook you did | 01:05 |
| mwhudson | jelmer: in import_git_objects, can we just limit the times we go around the last for loop? | 01:06 |
| mwhudson | jelmer: i'm not sure what the "while heads:" loop is doing | 01:06 |
| malibu | How do I retrieve older versions of files with unison? | 01:20 |
| bob2 | you don't | 01:20 |
| bob2 | it's a sync tool | 01:20 |
| malibu | Oh but I want versions.. unison won't work for me | 01:20 |
| malibu | So unison isn't much more then rsync then | 01:21 |
| jelmer | mwhudson, yeah | 01:22 |
| mwhudson | jelmer: cool | 01:22 |
| mwhudson | jelmer: any idea how to test this? | 01:23 |
| malibu | I basically want protection from anything... such as deleting a file by accident | 01:27 |
| malibu | I think I might use unison, but also take an incremental backup of the repo a few times a day | 01:27 |
| * wgrant wishes that bzr would warn when it had a bad email address set. | 01:49 | |
| _Andrew | Hi | 02:59 |
| _Andrew | Anyone else have a problem where you can't commit through a mounted smb partition unless you do it as root? | 03:01 |
| _Andrew | My /etc/fstab line looks like this... | 03:02 |
| _Andrew | /computer/repo /mnt/repo cifs rw,username=user,password=pass,noauto,users,group,exec,dev,suid 0 0 | 03:02 |
| _Andrew | Any ideas? | 03:02 |
| lifeless | well, what error do you get? | 03:02 |
| _Andrew | It says permissions denied code 13 | 03:03 |
| _Andrew | Cannot lock lock dir | 03:03 |
| _Andrew | I'm guessing it's how I setup the mount? | 03:04 |
| lifeless | that suggests that you don't have permission to lock things | 03:04 |
| lifeless | if your working tree is on the mount, this could be an OS lock, or a dirlock, where we rename a directory to take the lock. | 03:04 |
| lifeless | if your working tree is not on the mount, then its only going to be a dirlock; check your users permissions to .bzr/repository/ .bzr/repository/lock and .bzr/branch and .bzr/repository/lock | 03:05 |
| _Andrew | ok | 03:06 |
| _Andrew | thanks | 03:06 |
| _Andrew | Could it be because when I crate a file on the mount it create is with no permissions to write? | 03:08 |
| _Andrew | create** | 03:08 |
| lifeless | that would be a problem | 03:09 |
| lifeless | poolie: I don't know the number that its a dupe of | 03:39 |
| lifeless | poolie: but I'm very sure its a dupe | 03:39 |
| poolie | mm it looked familiar | 03:42 |
| lifeless | it was a smart server code path | 03:42 |
| lifeless | issue | 03:42 |
| * igc lunch | 03:47 | |
| poolie | igc, around? | 04:03 |
| igc | hi poolie: back from lunch now | 04:32 |
| thumper | just to confirm, if a bug was fixed for 2.0.1 it was also in the 2.1.x branch? | 04:50 |
| lifeless | check the bug, it should have separate tasks | 04:54 |
| lifeless | but generally, yes. it would have been fixed in trunk as well. and trunk became 2.1.x recently | 04:54 |
| thumper | lifeless: https://bugs.edge.launchpad.net/launchpad-code/+bug/3918 | 04:57 |
| ubottu | Ubuntu bug 3918 in bzr "bzr can be caused to error with filenames containing newlines" [High,Fix released] | 04:57 |
| thumper | lifeless: only one bzr task | 04:57 |
| lifeless | should be fixed in 2.1.x then | 04:58 |
| thumper | ta | 04:58 |
| lifeless | damn I love noise cancelling headphones | 04:58 |
| spiv | lifeless: not today, thu and fri | 05:33 |
| lifeless | so on tue,wed only? | 05:35 |
| spiv | lifeless: no, off mon,tue,wed, and on thu,fri currently. | 05:36 |
| lifeless | kk | 05:36 |
| AfC | How come `bzr ls` shows .~N~ revert files? It's not a problem, of course. Just a bit weird. | 05:37 |
| lifeless | with no options it acts like 'ls' | 05:37 |
| lifeless | AIUI | 05:37 |
| spiv | lifeless: damn ambiguous language :) | 05:37 |
| lifeless | spiv: I thought it was lovely and clear... and possibly wrong :) | 05:38 |
| spiv | :) | 05:38 |
| AfC | lifeless: er, not really. [when recursing] it leaves out [children of] ignored file paths. So why would it show ~ files? | 05:51 |
| lifeless | AfC: file a bug please ;) | 05:52 |
| AfC | anyway, I just thought it was weird. | 05:53 |
| lifeless | it is - thus me wanting a bug ;) | 05:53 |
| AfC | seeing as how there is a --ignored flag | 05:53 |
| AfC | ok | 05:53 |
| AfC | lifeless: https://bugs.launchpad.net/bzr/+bug/522015 filed for you | 06:03 |
| ubottu | Ubuntu bug 522015 in bzr "bzr ls shouldn't show .~1~ revert files" [Undecided,New] | 06:03 |
| lifeless | thanks | 06:05 |
| poolie | AfC, so the problem is actually that it shows ignored files but does not recurse into them? | 06:17 |
| poolie | spiv, lifeless, https://lists.launchpad.net/launchpad-dev/msg02590.html may be of interest | 06:17 |
| lifeless | poolie: have you seen ground control ? | 06:18 |
| lifeless | (i'm glad hydrazine is coming along) | 06:18 |
| poolie | only briefly | 06:19 |
| poolie | does it cover bug stuff? | 06:19 |
| AfC | poolie: I should think that the problem is that it's showing unversioned files. The recursion interaction may be complicating things | 06:19 |
| poolie | so the bug is 'i wish bzr ls excluded ignored files by default'? | 06:19 |
| poolie | igc, so regarding annotate | 06:20 |
| poolie | it would be good to fix | 06:20 |
| AfC | um isn't it supposed to? | 06:20 |
| AfC | I mean, otherwise, why the --ignored option? | 06:20 |
| lifeless | I'd say that being inconsistent is a bug | 06:20 |
| lifeless | either recurse into and show ignores, or do neither | 06:20 |
| igc | poolie: hi poolie | 06:20 |
| AfC | and meanwhile, if you do `bzr ls -R` it does not list contents of ignored [top level] directories] | 06:20 |
| poolie | igc, so we should probably ask first whether you have anything else yet unfinished | 06:21 |
| poolie | you, or we | 06:21 |
| poolie | afc, ls --ignored means "only ignored" | 06:21 |
| AfC | which is what you'd expect given the whole "ls me what's versioned" expectation | 06:21 |
| poolie | i don't know if that's really the ideal behaviour | 06:21 |
| AfC | poolie: [oh] | 06:21 |
| lifeless | AfC: poolie is being very reflective ;) | 06:22 |
| AfC | lifeless: just so long as he's not being recursive | 06:22 |
| poolie | iow shiny | 06:22 |
| AfC | anyway, I would have thought it wouldn't list any ignored files at all. Seeing as how it seems to ignore some (but not others) I'd say that's the bug | 06:22 |
| spiv | poolie: (re hydrazine) interesting! I was just realising earlier today that I can slowly read email and browse the web while holding the baby by carefully driving my laptop with my toes :) | 06:22 |
| spiv | poolie: a mail client with good key bindings certainly helps when doing that! | 06:23 |
| poolie | or, carefully hold the baby between your knees and type faster :) | 06:23 |
| poolie | so i do think in principle one ought to be able to get through bug triage faster by typing than clicking | 06:23 |
| poolie | it may even be possible on top of this | 06:23 |
| poolie | s/on top of this/starting from the basic approach of hydrazine | 06:24 |
| spiv | (Turns out http://en.wikipedia.org/wiki/Morton%27s_toe is not just a random mutation but a distinct advantage ;) | 06:24 |
| lifeless | spiv: so, you and the statue of liberty huh | 06:26 |
| JesseW__ | What is the difference between a "master branch" and a "parent branch" and are there any other types of branches? | 07:06 |
| === JesseW__ is now known as JesseW | ||
| lifeless | a master branch is the branch a bound branch synchronises with | 07:07 |
| lifeless | a parent branch is the branch that 'pull' and 'merge' will read from by default if you don't supply a url | 07:07 |
| poolie | spiv, can the cleanup work systematically get rid of TooManyConcurrentRequests etc? | 07:11 |
| poolie | or could we turn them into eg a warning? | 07:11 |
| JesseW | lifeless: thanks -- and there are no other kinds? | 07:12 |
| Peng | It's not like they're different _types_ of branches. A branch just has e.g. "parent_location = foo" in its branch.conf. | 07:15 |
| Peng | There are several others -- submit (bzr send's default destination), public (used as the public location by 'bzr send' and Loggerhead), and probably more. | 07:16 |
| Peng | The stacked-on branch, if you're using stacking. | 07:16 |
| JesseW | Peng: great, that was the sort of thing I wanted to know... so, these are effectively branch properties, that specify various relationships with other branches? Is there a full list anywhere? | 07:17 |
| Peng | JesseW: Dunno if there's a full list, aside from digging through the source dode. We definitely listed most of them. :P | 07:26 |
| spiv | poolie: off the top of my head, only if we get pretty strict about replacing try/finally blocks that might issue smart requests in finallys with the more robust cleanup helpers | 07:30 |
| JesseW | Peng: cool, thanks. | 07:30 |
| spiv | poolie: and that's pretty hard to do short of forbidding finally: entirely in test_source | 07:30 |
| spiv | poolie: but, | 07:30 |
| spiv | poolie: I think the only_raises decorator that is already on unlock methods in 2.1 will have fixed the majority of cases | 07:31 |
| spiv | poolie: so 100% seems very hard, but we may already be Good Enough | 07:31 |
| spiv | (also, potentially except clauses could be troublesome too, so even banning finally perhaps wouldn't be sufficient) | 07:32 |
| spiv | poolie: I'll be very interested to see how many reports of TMCR we get involving 2.1 | 07:32 |
| * igc dinner | 08:07 | |
| dholbach | hola | 09:11 |
| dholbach | is bug 522041 known already? | 09:11 |
| ubottu | Launchpad bug 522041 in bzr "ERROR: exceptions.TypeError: merge_text() takes exactly 2 arguments (3 given)" [Undecided,New] https://launchpad.net/bugs/522041 | 09:11 |
| Peng | Yes, and I'm 99% sure it's been fixed. | 09:20 |
| Peng | dholbach: https://launchpad.net/bugs/515597 | 09:20 |
| ubottu | Ubuntu bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released] | 09:20 |
| dholbach | nice, hope the fix gets into Ubuntu quickly! :) | 09:20 |
| Peng | dholbach: Ehh, you could edit your bzr install -- it's a _really_ trivial change. | 09:22 |
| dholbach | Peng: I'm sure I'm not the only one having the problem | 09:23 |
| Peng | dholbach: Yeah, you're not the only one. | 09:25 |
| Peng | If you didn't read them, the bugs say the fix will be in 2.1.0 final. I dunno when that will get into Ubuntu. | 09:26 |
| Peng | It was also said that the bug probably isn't in 2.0, so backporting is not a concern. | 09:26 |
| dholbach | yep, seems to be a problem "only" in ubuntu lucid and debian experimental right now | 09:27 |
| poolie | dholbach, it may be fixed in the nightly ppa | 09:28 |
| poolie | anyhow, good night | 09:28 |
| mathrick | jelmer: ewww, dvorak | 11:37 |
| mathrick | it's snake oil, don't believe it | 11:37 |
| mathrick | malibu: have you looked at that git-based FS thing? | 11:39 |
| marienz | woo dvorak | 11:44 |
| idnar | dvorak ftw | 11:45 |
| idnar | but yeah, learning a new keyboard layout is painful | 11:46 |
| idnar | it gets easier after the first 5 layouts, though ;) | 11:46 |
| * marienz blinks | 11:46 | |
| marienz | that is a lot of layouts | 11:46 |
| fullermd | Well, compared to 101!, it's a pretty small sampling of the choices :p | 11:48 |
| idnar | I don't actually know 5 layouts; but languages get easier after the first 5, so I figure keyboard layouts should be the same ;) | 11:48 |
| gerard_ | lifeless: did you unban the guy that kept rejoining and leaving? | 12:45 |
| === 18VAAD4Y4 is now known as SamB | ||
| === SamB is now known as SamB_XP | ||
| slestak | somehow I have gotten to branches on lp linked. I have a project branch that has my dotfiles repo lited as its parent | 13:26 |
| slestak | i am sure this is soemthign I did, but I do not want to merge these two. | 13:26 |
| slestak | could someone pls help me sep these two? | 13:27 |
| slestak | this is the branch in question, https://code.launchpad.net/~slestak989/+junk/pt | 13:27 |
| slestak | bzr info shows dotfiles as its parent which is not correct | 13:27 |
| maxb | I don't think the parent of a launchpad branch actually has any meaning | 13:28 |
| maxb | If you actually care to look for it, you can find all kinds of people's random local paths in there | 13:28 |
| slestak | but if I try to sync my workstation to this, it will try to pull in vimrc and whatnot | 13:29 |
| maxb | huh? | 13:29 |
| slestak | This was not liek this on Friday, so I thought I would be able to rollback whatever transaction did this | 13:30 |
| slestak | in the pt dir, if I do bzr missing, it says i am missing every revision in dotfiles | 13:30 |
| maxb | The value in the launchpad branch is irrelevant for that | 13:31 |
| maxb | It's the value in your local branch that you're running 'bzr missing' in that matters there | 13:31 |
| slestak | so that is what I need to correct | 13:32 |
| maxb | Just do a 'bzr pull --remember' from whatever branch you actually want | 13:32 |
| slestak | this workign dir is actually the most receent, so I need to push. | 13:33 |
| slestak | i wonder if this will try to push to dotfiles? | 13:33 |
| slestak | the help for pull says it will only work for non-diverged branches. I think these can be considered diverged. | 13:34 |
| slestak | so try the merge to resolve diverge, or try the pull --remember? either can be reverted right? | 13:37 |
| fullermd | Wait... is the actual _problem_ anything other than "this branch's 'parent' doesn't make sense"? | 13:44 |
| fullermd | 'cuz if that's the whole problem, there's not a problem... | 13:44 |
| slestak | fullermd: i am concerned that on my workstation, If I do bzr pull it will pull down src from lp that doesnt belong in this bracnh | 13:44 |
| slestak | i can revert it if it doesnt work out right? just try it and dont commit until verify? | 13:45 |
| fullermd | Well, first off, pull won't pull unless what you're pulling is a superset of what you have (unless you --overwrite of course). So if two branches are unrelated, pull won't do anything. | 13:46 |
| fullermd | Second, if you're worried about the effect of the parent branch of the _branch on lp_, on anything you do locally, don't. | 13:46 |
| slestak | but when I say bzr missing, it lists every revision for dotfiles | 13:47 |
| fullermd | Saved locations like 'parent' (and 'push', etc) don't imply any linkage between the branches. They just provide defaults for certain commands. | 13:47 |
| slestak | add a -v and it shows all of my vim setup. | 13:47 |
| slestak | I think I see what maxb was saying, do a pull --remember to set it to the pt branch on lp i want | 13:48 |
| fullermd | The parent branch of a branch on LP wouldn't matter. | 13:48 |
| fullermd | Parent just sets the default for pull (and sometimes a few other commands) | 13:48 |
| slestak | this is the parent branch on my workstation I an discussing | 13:48 |
| fullermd | Ah. Well, don't pull then 8-} | 13:49 |
| fullermd | (not that it'll do anything unless the branches are related, as above) | 13:50 |
| slestak | too late, lol | 13:50 |
| slestak | sokay. it did what both of you said, pulled nothing. | 13:50 |
| slestak | and --remember did what was expected | 13:51 |
| slestak | sorry for drama, trying to work bzr into my workflow | 13:51 |
| igc | night all | 14:09 |
| rubbs | night | 14:10 |
| asac | hi ... what does "format: unnamed" mean? | 14:17 |
| fullermd | It means there's no name for the combination of formats at the given location. | 14:22 |
| fullermd | Try info -v for the details. | 14:23 |
| asac | fullermd: hmm. how can that happen? | 14:25 |
| fullermd | Oh, any number of ways. | 14:25 |
| asac | for example? | 14:25 |
| asac | if i merge a branch with a different format? | 14:25 |
| asac | can i get the branch straight again ;)? | 14:26 |
| fullermd | Branch format from upstream. Upgrading one parts but not another. Various combinations of formats given to init and init-repo. | 14:26 |
| fullermd | It's not un-straight. It's just unnamed. | 14:26 |
| maxb | asac: The most common way it happens is when bzr 2.x combines the latest working tree format with an older branch/repo format. | 14:28 |
| maxb | This is an unfortunate UI wart, since it obscures the interesting information unless you know to read bzr info -v and interpret it | 14:29 |
| asac | hmm | 14:31 |
| asac | so the problem is that i got a branch submission that i cant merge. it seems to use rich-root, but the guy did it on a recent checkout - i assume it means he ran upgrade before submission? | 14:31 |
| fullermd | Not necessarily. He could have branched it into an existing RR repository. | 14:32 |
| asac | sigh | 14:32 |
| jelmer | asac: Is there a reason you can't upgrade to 2a or another rich root format yourself? | 14:33 |
| asac | since when does 2a exist? | 14:33 |
| jpds | asac: karmic. | 14:34 |
| jelmer | asac: it was introduced in bzr 2.0 | 14:34 |
| asac | right | 14:34 |
| asac | so until hardy is eol i dont want to do that ;) | 14:34 |
| asac | but i guess its already too late :( | 14:34 |
| asac | since our branch somehow morphed into unnamed from pack-0.92 | 14:34 |
| fullermd | 2a isn't the only rich root format. rich-root-pack dates to 1.0 for instance. | 14:34 |
| jelmer | asac: alternatively you could switch to 1.0-rich-root, that's bidirectionally compatible with 2a | 14:34 |
| jelmer | asac: that was introduced before 1.3.1 which is in hardy | 14:35 |
| asac | thx will think about it ... but i just want to stay on pack-0.92 ... why is bzr so bad to me :( | 14:36 |
| asac | is there a way to prevent changes to branch format on commits of a branch? | 14:39 |
| asac | like the "always on top" ... a "never morph branch format" ? | 14:39 |
| fullermd | Being distributed is kinda antithecal to being able to tie down what other people can do on other branches. | 14:40 |
| asac | well i dont mind of what the peers do on their own | 14:40 |
| asac | i just want to ensure that the online branch doesnt change his format | 14:40 |
| jelmer | asac: fwiw you can always communicate branches in other formats freely, the only situation in which this doesn't work is from a rich root format to a non-rich-root format | 14:40 |
| fullermd | Branches don't just change their format; somebody changes 'em. An existing branch won't change unless you upgrade it. | 14:41 |
| asac | right | 14:41 |
| asac | but when i do a bzr merge lp:dirtybranch | 14:41 |
| asac | bzr commit | 14:41 |
| jelmer | asac: That won't upgrade your branch | 14:41 |
| asac | and that changes my local branch format without a warning its not really an explicit decision | 14:41 |
| asac | then how did the online firefox-3.6 branch got upgraded to unnamed? | 14:42 |
| jelmer | asac: what's the url of that branch? | 14:42 |
| asac | anyway ... i guess i need to live with this and hope for the best :( | 14:42 |
| jelmer | asac: Somebody must've run bzr upgrade on it | 14:42 |
| asac | http://launchpad.net/~mozillateam/firefox/firefox-3.6.head | 14:42 |
| asac | i only ran bzr upgrade --pack-0.92 on it | 14:43 |
| asac | i doubt someone else did | 14:43 |
| fullermd | Standalone branch (format: pack-0.92) | 14:43 |
| jelmer | asac: according to bzr info that's still pack-0.92 | 14:43 |
| asac | oh | 14:43 |
| asac | its xulrunner-1.9.2.head | 14:43 |
| asac | i think | 14:44 |
| asac | heh | 14:44 |
| asac | seems its all fine ... hell do i feel bad. sorry | 14:45 |
| asac | let me complain to the guy that confirmed it was unnamend ;) | 14:45 |
| jelmer | asac: it may be that when he cloned that branch locally he ended up in an "unnamed" format | 14:46 |
| asac | probably | 14:46 |
| * asac happy | 14:46 | |
| jelmer | asac: the "unnamed" bit is confusing indeed | 14:46 |
| asac | so the reporter has this for fresh checkout: http://pastebin.com/f13c46178 | 14:50 |
| asac | i have http://pastebin.com/f230277fa | 14:51 |
| asac | in one case its Working tree format 6 | 14:51 |
| asac | (the unnamed one that is) | 14:51 |
| fullermd | That's what you'd expect from a 2+ version of bzr. | 14:51 |
| asac | for me its working tree format 4 | 14:51 |
| asac | fullermd: i have Bazaar (bzr) 2.1.0rc2 | 14:51 |
| asac | he has 2.0.4 | 14:51 |
| asac | seems 2.0 upgrades the working tree format to 6 while 2.1.0 doesnt | 14:52 |
| asac | so guess that was a bug in karmic bzr? | 14:52 |
| asac | thats 2.0.4 | 14:52 |
| fullermd | No, 2.1 does it too. | 14:54 |
| asac | why not for me? | 14:54 |
| asac | 15:51 < asac> i have http://pastebin.com/f230277fa | 14:54 |
| fullermd | Because you're using http; it's preserving it over that. | 14:54 |
| asac | thats bzr info -v | 14:54 |
| asac | omg | 14:54 |
| fullermd | Probably some side effect of the format hiding over the smart server. Dunno. | 14:55 |
| fullermd | Anyway, WT format doesn't matter anywhere except locally. | 14:55 |
| * asac happy that thats the case | 14:55 | |
| asac | you are right | 14:56 |
| asac | over ssh i get the unnamed thing | 14:56 |
| * asac scared | 14:56 | |
| asac | ok thanks | 14:56 |
| === beuno is now known as beuno-lunch | ||
| guilhembi | I'm doing "bzr check -v" on a shared repository (which should take 40 hours), I wonder if -vv would have given interesting info? Or is -v ok? | 15:46 |
| maxb | I thought bzr's -v was just on/off, not level based? | 15:46 |
| guilhembi | ah, maybe... :-) | 15:47 |
| guilhembi | ok, I'll see after 40 hours. | 15:47 |
| fullermd | I'm not sure -v does anything on check anyway... | 16:04 |
| henninge | Are there any plans or is anybody working on providing context managers for Tree locks? | 16:12 |
| jelmer | henninge: I'm not aware of any plans. | 16:12 |
| henninge | I just implemented one locally in a Launchpad branch and thought this should really be in Tree code. | 16:13 |
| henninge | jelmer: I am not too familiar with the class structure in bzr but is Tree the class that implementes the locking? | 16:14 |
| * henninge goes to browse bzr code. | 16:14 | |
| jelmer | henninge: no - a Branch, Repository and Tree are all three lockable but they call out to another class to worry about the actual locks | 16:15 |
| henninge | ok, now I remember reading the tree locks use branch locks. | 16:16 |
| henninge | jelmer: should I file a bug about it to start with? | 16:16 |
| jelmer | henninge, please do | 16:16 |
| henninge | cool | 16:16 |
| henninge | jelmer: https://bugs.edge.launchpad.net/bzr/+bug/522195 | 16:26 |
| ubottu | Ubuntu bug 522195 in bzr "bzrlib should provide context managers for locking" [Undecided,New] | 16:26 |
| === henninge is now known as henninge-afk | ||
| jelmer | henninge-afk, thanks | 16:30 |
| === beuno-lunch is now known as beuno | ||
| Azag | hi | 17:35 |
| Azag | how I can set a branch as default branch? | 17:35 |
| Kinnison | Do you mean on launchpad? | 17:36 |
| Azag | yes | 17:36 |
| Kinnison | IIRC you set it as the development focus | 17:37 |
| Kinnison | visit the project page and click "edit details" | 17:37 |
| Kinnison | scroll to near the bottom | 17:37 |
| Kinnison | see the dev focus dropdown? | 17:37 |
| Kinnison | select something from there | 17:37 |
| Kinnison | That should do it | 17:37 |
| Azag | in that part | 17:38 |
| Azag | show | 17:38 |
| Azag | Development focus: | 17:38 |
| Azag | <my_project-name> trunck | 17:38 |
| Azag | but when I try: bzr co lp:<my-project> it say me that there is not default branch | 17:40 |
| Kinnison | What is your package project called? | 17:43 |
| * Kinnison will look | 17:43 | |
| Azag | Kinnison: shareit-server | 17:44 |
| james_w | Azag: go to https://code.launchpad.net/<my-project> and there should be a link you can click to set the branch for htat | 17:44 |
| Azag | I see | 17:45 |
| Azag | thnx | 17:45 |
| Kinnison | cool | 17:45 |
| Azag | jeje, I was looking in the worng page | 17:45 |
| Azag | thanks Kinnison and james_w | 17:45 |
| Azag | :) | 17:45 |
| Kinnison | tbf, it's not completely obvious to me because all my projects already have focusses :-) | 17:45 |
| === radoe_ is now known as radoe | ||
| Azag | how I can download a bzr branch without a rsa directory | 18:39 |
| Azag | Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to the list of known hosts. | 18:39 |
| Azag | Permission denied (publickey). | 18:39 |
| Azag | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 18:39 |
| Azag | 18:39 | |
| mwhudson | jelmer: test_log_verbose (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) just errored for me, is this bzr's fault? | 18:40 |
| mwhudson | bah | 18:41 |
| jelmer | mwhudson, no idea - what's the error exactyl? | 18:44 |
| mwhudson | jelmer: http://pastebin.ubuntu.com/377039/ | 18:45 |
| jelmer | mwhudson, ah | 18:46 |
| jelmer | mwhudson, that's a bzr bug | 18:46 |
| mwhudson | ok | 18:46 |
| jelmer | mwhudson, I submitted a merge request for it, not sure what the current status is | 18:46 |
| mwhudson | jelmer: shoving this information about how many revisions to import through all the layers is no real fun :/ | 18:50 |
| lifeless | gerard_1: thanks | 19:25 |
| gerard_ | lifeless: I was happy to remember it ;) | 19:27 |
| === froosch_ is now known as froosch | ||
| lifeless | james_w: ping, bzr-builder ppa watching; hows that going? [I'm sure its a case of ETIME | 19:33 |
| lifeless | :)] | 19:33 |
| __monty__ | Could someone have a look at this, the last comment in particular? | 19:35 |
| __monty__ | *https://code.launchpad.net/~toonn/bzr/no-repo-error-message/+merge/17039 This of course. (forgot the link) | 19:36 |
| aleksander_m | hi all. Can anyone tell me why the shared-repository (bzr init-repo PROJECT) is needed when using the distributed development approach? | 20:02 |
| fullermd | It's not strictly needed. It's useful for saving space when you [would otherwise] have multiple copies of the same history. | 20:03 |
| aleksander_m | fullermod: humm.. what do you mean? | 20:05 |
| lifeless | fullermd: might be clearer to say its optional | 20:05 |
| lifeless | aleksander_m: its optional; shared repository lets multiple branches reuse the same storage database ('repository') | 20:06 |
| aleksander_m | aha, understood | 20:06 |
| aleksander_m | another question... when using bzr push to publish commits in the main branch, it happened to me that one of my colleagues didn't do a pull in the mirror branch first, so he pushed his changes but overwrote already pushed changes... is there any way to avoid this? | 20:13 |
| fullermd | It wouldn't discard other existing changes unless he did push --overwrite; that requires intention. | 20:14 |
| fullermd | Or do you mean that the existing changes are now showing up in a merge, rather than on mainline like they previously were? | 20:14 |
| aleksander_m | hum.... you got me | 20:15 |
| aleksander_m | can't remember | 20:15 |
| fullermd | Look at `bzr log -n0`. If the already-pushed changes you're thinking are overwritten show up in some of the indented revs, it's the latter case. | 20:15 |
| fullermd | If the problem is actually the former... smack your colleague around for using --overwrite :) | 20:15 |
| fullermd | Either situation can also be prevented by setting a branch config option to preserve the mainline. I'll remember what it's called in a second... | 20:16 |
| fullermd | append_revisions_only I think? | 20:16 |
| fullermd | Yeah, that's it. | 20:17 |
| aleksander_m | will take a look at it | 20:20 |
| aleksander_m | fullermod: thanks | 20:20 |
| aleksander_m | s\fullermod\fullermd | 20:21 |
| lifeless | james_w: hi | 20:42 |
| james_w | hi lifeless | 20:43 |
| lifeless | james_w: did you see my ping about builder? | 20:44 |
| james_w | I did | 20:45 |
| james_w | it's still on my list | 20:45 |
| lifeless | kk | 20:45 |
| james_w | I have spent time on it | 20:45 |
| james_w | I'm just not happy with some of the interaction that the oauth stuff forces on the user | 20:46 |
| james_w | so I'm thinking of better ways to structure it | 20:46 |
| lifeless | ok. if you want a sounding board let me know | 20:46 |
| james_w | for instance, it only checks whether it has the needed credentials right at the end, after it has gone through the process of building etc. | 20:47 |
| james_w | and I don't think it should open a webbrowser if it doesn't have the credentials then wait forever for response, as that doesn't fit well with some situations it is expected to be used in | 20:48 |
| lifeless | james_w: I can see the concern, however it only happens when someone uses this option :) | 20:50 |
| james_w | that's true, but I don't think they should be punished for using it :-) | 20:51 |
| poolie | hello lifeless | 20:52 |
| lifeless | hi poolie | 20:54 |
| lifeless | james_w: neither do I | 20:54 |
| lifeless | james_w: but I've learnt to be wary about overgeneralising UI problems | 20:54 |
| james_w | yes | 20:55 |
| shakaran | hi, I use Lucid, and I can't install bzr-svn: http://pastebin.com/d3e9b5fe4 | 21:45 |
| mkanat | mwhudson: ping. Any info about the hangs? | 21:51 |
| mwhudson | mkanat: no | 21:51 |
| mwhudson | not yet | 21:51 |
| mkanat | mwhudson: Okay. Why did I think that they weren't happening anymore? | 21:51 |
| mwhudson | well, they are significantly less frequent | 21:52 |
| mwhudson | now | 21:52 |
| mwhudson | so you have to wait a while to get the full picture | 21:52 |
| mkanat | mwhudson: Okay. Francis said it was every 3 days? | 22:00 |
| mwhudson | on average | 22:00 |
| mkanat | mwhudson: Okay. | 22:00 |
| mwhudson | there was a crash last night, but i'm not sure if the admin did the stack trace thingy | 22:00 |
| mwhudson | (which i had to rewrite last week, fun) | 22:00 |
| mkanat | mwhudson: Ahhh. | 22:00 |
| mkanat | mwhudson: Are the hang logs similar to the last one you showed me, where there are several minutes of nothing in the log, before the restart? | 22:03 |
| mwhudson | mkanat: i don't know | 22:04 |
| mkanat | mwhudson: Okay. Do the LOSAs know to get the stack trace the next time the process hangs? | 22:57 |
| mwhudson | mkanat: i hope so | 22:57 |
| mwhudson | mkanat: i'm on the phone and have been for a while, i'm not completely ignoring you :-) | 22:57 |
| mkanat | mwhudson: Ahh, okay. :-) I think I commented on the bug about it several weeks ago, but I haven't gotten a stack trace since then, so I assume that some other form of communication is required? | 22:57 |
| mwhudson | mkanat: welcome to life in a distributed company! | 22:58 |
| mkanat | mwhudson: Well, yeah, I'm familiar with it from all the years of working with Mozilla. :-) I assume that the "follow the official process and then also ping people on IRC" solution is similar? :-) | 22:59 |
| mwhudson | mkanat: yes | 22:59 |
| mkanat | Okay. :-) | 22:59 |
| mkanat | losa ping ? :-) | 23:00 |
| mwhudson | mkanat: ideally we want codebrowse to fall over when i'm working | 23:00 |
| lifeless | mwhudson: well | 23:00 |
| lifeless | mwhudson: I beg to differ ;) | 23:00 |
| mwhudson | lifeless: in a very particular way of course | 23:01 |
| lifeless | Ideally no fall overs at all:) | 23:01 |
| lifeless | we want it to learn to run | 23:01 |
| igc | morning | 23:03 |
| igc | hi lifeless | 23:03 |
| lifeless | hi igc | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!