| markh | jam: good evening! Bug 45719 refers to a branch https://code.launchpad.net/~jameinel/bzr/update-r, which is failing to mirror. Do you still have that branch available? Helping 'bzr up' grow a '-r' option sounds like something I could do in idle time... | 00:08 |
|---|---|---|
| ubottu | Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] https://launchpad.net/bugs/45719 | 00:08 |
| markh | it looks like it must be close to done already too | 00:08 |
| markh | htm | 00:09 |
| jam | markh: Yeah, LP just didn't like it when I upgraded my repo, and it had to re-fetch everything | 00:09 |
| jam | It tends to timeout while downloading a full branch from my server | 00:09 |
| jam | markh: you can get it from the source | 00:10 |
| markh | A status of " [Medium,Fix committed]" doesn't look correct | 00:10 |
| markh | oh - cool | 00:10 |
| jam | just make sure you are going into a repo | 00:10 |
| jam | http://bzr.arbash-meinel.com/branches/bzr/0.11-working/update-r | 00:10 |
| markh | excellent - thanks | 00:10 |
| markh | I'm not sure what you mean by "make sure you are going into a repo" | 00:11 |
| markh | I can't just branch it? | 00:11 |
| jam | markh: branch it into a shared repository, so you don't use up all my upload bandwidth | 00:12 |
| jam | you *can* get it without that, but it is *nicer* to me if you do | 00:12 |
| * markh feels clueless :) | 00:13 | |
| markh | I'm not quite sure what you are asking :) | 00:13 |
| jam | markh: I'm guessing at some point you did 'bzr init-repo', just make sure you 'bzr branch' underneath that point | 00:13 |
| jam | then again, maybe you didnt' | 00:13 |
| markh | nope, I didn't | 00:13 |
| markh | I think its time I educated myself a little more on a few of these things... | 00:14 |
| jam | markh: if you do: "bzr init-repo repo; bzr branch bzr.dev repo/bzr.dev" it will copy revisions into the repo/.bzr/repository, future branches underneath 'repo' will share them | 00:14 |
| jam | rather than copying them again | 00:14 |
| LarstiQ | markh: you can create one later and seed it with data from the original branch, what jam just said | 00:14 |
| jam | anyway, family time now, I'll try to get back later to get 1.6rc4 put out tonight | 00:15 |
| markh | oh, right - that makes sense. | 00:15 |
| kiko | hey there | 00:15 |
| kiko | quick question | 00:16 |
| LarstiQ | markh: and the relevant point for jam, if you branch update-r it will only download the revisions that you didn't have before, not hammering his upstream :) | 00:16 |
| LarstiQ | kiko: shoot | 00:16 |
| kiko | is there a way of saying 'give me the code as it looked in january 1st 2004'? | 00:16 |
| markh | my current workflow is, eg, branch bzr.dev into its own folder, then make other branches from that directory. If I followed that workflow, wouldn't I still only download from John's server once? | 00:16 |
| kiko | using bzr checkout ideally | 00:16 |
| Peng_ | kiko: There's a "date:" revspec. | 00:16 |
| kiko | hey LarstiQ | 00:16 |
| kiko | aha. date:. | 00:16 |
| markh | ie, wound;t a shared repo only save copies between my own local dis directoroes? | 00:16 |
| kiko | Peng_, thanks! | 00:16 |
| Peng_ | :) | 00:16 |
| * markh slaps his fingers... | 00:17 | |
| markh | hi LarstiQ! | 00:17 |
| markh | hrm | 00:18 |
| LarstiQ | markh: if you just branch inside a directory the branches will be all standalone and not sharing any revisions | 00:18 |
| markh | or are you saying that I need to have *both* bzr.dev and john's patch in the same shared repo? | 00:18 |
| LarstiQ | markh: you can confirm that by checking for branch/.bzr/repository/ | 00:18 |
| markh | LarstiQ: yeah, but doing that wouldn't hammer upstream any more would it? ie, once I have the upstream copy in my local dir, other branches don't hit upstream at all | 00:19 |
| markh | but - is the point to not pull revisions that are also in bzr.dev? | 00:19 |
| LarstiQ | markh: now, if you are branching something (remote or local), bzr will check which revisions it should get, and if some of those are already present in the target repository, it will not fetch them again. | 00:20 |
| LarstiQ | markh: true. | 00:20 |
| LarstiQ | markh: exactly. | 00:20 |
| LarstiQ | markh: since update-r is largely the same as bzr.dev, you would avoid downloading all those common revisions. | 00:20 |
| markh | ok cool - that makes more sense. I thought the advice was to put that branch in its *own* shared repo :) | 00:20 |
| markh | which doesn't make much sense ;) | 00:20 |
| LarstiQ | markh: ah no, that wouldn't help any :_) | 00:20 |
| LarstiQ | markh: to continue my train of explanation, when your are not branching to a shared repository, there will be no pre-existing target repository, hence no revisions you already have, and you need to get everything again | 00:21 |
| LarstiQ | markh: if you are however branching into a shared repository, there _might_ be revisions in there that you would otherwise have to fetch. | 00:22 |
| markh | LarstiQ: that makes alot of sense - thanks | 00:22 |
| LarstiQ | markh: since we know update-r and bzr.dev are similar, we can make sure we are branching into a repo that includes bzr.dev's revisions | 00:22 |
| LarstiQ | and hence, avoid doing more work than we really need to. | 00:22 |
| LarstiQ | markh: cool | 00:22 |
| LarstiQ | markh: I personally have a ~/src/bzr/ repository where I have all my bzr branches under. | 00:23 |
| markh | now we have stacked branches, would that be the preferred way to make such patches now? | 00:23 |
| markh | LarstiQ: yes, I think I need one of them :) | 00:24 |
| * LarstiQ is clueless about stacked branches, alas | 00:24 | |
| markh | from 10,000 feet, I understood a usecase was all about avoiding fetching stuff that is common. | 00:24 |
| LarstiQ | markh: two effects you should notice after doing that, the size on disk of repo/ with multiple related branches is much smaller than just a directory of related branches | 00:25 |
| LarstiQ | markh: and, branching within it is much much faster, since you need to do zero moving of revisions | 00:25 |
| Peng_ | Stacked branches are sort of like lightweight checkouts, where bzr doesn't download and sae the revisions at all. | 00:25 |
| markh | Peng_: ahh, thanks | 00:25 |
| LarstiQ | markh: oh right. I guess that might work. | 00:26 |
| * LarstiQ 's mind is still molded to think of how bzr used to work | 00:26 | |
| Peng_ | But with stacked branches, it still works like a branch, with local commits and all. | 00:26 |
| LarstiQ | markh: I have some catching up to do. | 00:26 |
| lifeless | LarstiQ: it hasn't really changed | 00:26 |
| markh | LarstiQ: and you make your branches in subdirs under ~/src/bzr? | 00:26 |
| LarstiQ | markh: yup | 00:26 |
| lifeless | LarstiQ: how are you btw, long time no see | 00:26 |
| LarstiQ | markh: ~/src/bzr/{bzr.dev,1.5,1.4,bug1234,etc} | 00:27 |
| markh | and you still branch "normally" - bzr just magically works things out? | 00:27 |
| Peng_ | If you "bzr init-repo", "bzr branch --stacked http://bazaar-vcs.org/bzr/bzr.dev/" and then commit something, the only revision in your local repo will eb the one you committed (or maybe a couple revisions from bzr.dev, I don't remember) | 00:27 |
| Peng_ | markh: Was that question directed at me? | 00:27 |
| LarstiQ | lifeless: long past my bedtime atm :) But otherwise good, had my last exam for a while today, starting september I won't be studying this academic year. | 00:27 |
| LarstiQ | markh: yup | 00:27 |
| markh | Peng_: I think you answered it in the next line anyway :) | 00:27 |
| markh | ok great - thanks guys! | 00:28 |
| Peng_ | markh: Other than passing "--stacked" to "branch" commands, it'll all magically work. | 00:28 |
| markh | I just read the "quick into to bzr.dev" or whatever that doc was called and have stuck with that ever since :) | 00:28 |
| LarstiQ | lifeless: and I just spent 5 weeks in Finland with my girlfriend, so things are looking good now | 00:29 |
| markh | good, but exhausted :) | 00:29 |
| lifeless | nice:) | 00:30 |
| LarstiQ | lifeless: and as you may have noticed, jam has dragged me back to reading mail again. | 00:30 |
| LarstiQ | but now I think I'll try to get some sleep. | 00:31 |
| LarstiQ | markh: you good to go? | 00:31 |
| markh | LarstiQ: yeah, thanks for your hel | 00:31 |
| markh | p- | 00:31 |
| markh | :) | 00:31 |
| LarstiQ | glad to be of help, bug me anytime (I don't promise to know everything though :) | 00:32 |
| markh | thanks! | 00:32 |
| kiko | thmmm | 00:36 |
| kiko | Peng_, date: is kinda weird. if the branch checking out hasn't been modified since the date specified, it fails. | 00:36 |
| kiko | the branch you're checking out | 00:37 |
| kiko | bzr: ERROR: Requested revision: u'date:2007-01-01' does not exist in branch: BzrBranch5('file:///home/kiko/devel/archives/sourcecode/pygpgme/') | 00:37 |
| kiko | that fails because pygpgme hasn't been touched in god knows how long | 00:37 |
| lifeless | you might try before:date:2007-01-01 | 00:37 |
| lifeless | if that fails, i think its arguably a bug | 00:37 |
| kiko | okay, I will try that | 00:39 |
| kiko | but I think it's weird, and nothing in bzr is weird, usually | 00:40 |
| lifeless | its not entirely satisfactory | 00:40 |
| * markh should have known about shared repos long ago :) | 00:41 | |
| jam | kiko: date is one of those black sheep. we sort of have it, but it has a lot of points where the answer is unclear, so we sort of guess | 02:53 |
| jam | beuno: If you get a chance: https://edge.launchpad.net/bzr/1.6/1.6rc4 | 02:54 |
| === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc4! / http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ | ||
| jam | man, I really don't feel like sending *another* email to bazaar-announce .... | 02:58 |
| beuno | jam, how about tomorrow morning? I'm exhausted now, and will probably mess it up :/ | 03:00 |
| jam | beuno: np, you never did write up those better docs :) | 03:01 |
| beuno | jam, no, but I have notes! | 03:01 |
| beuno | I will send the patch for that tomorrow | 03:01 |
| beuno | and, it seems I may have time to try and put a script together during the week | 03:01 |
| beuno | so hopefuly I'll at least get started | 03:02 |
| VSpike | It must be because it's 3.20am here, but how can a file be in the removed, added and conflicts sections of bzr st? | 03:22 |
| Peng_ | When should rc4 make the PPA? | 03:22 |
| === kiko is now known as kiko-zzz | ||
| * VSpike thinks kiko probably has the right idea | 03:24 | |
| mwhudson | VSpike: if you have files with different file id trying to occupy the same path, i can imagine that happening | 03:24 |
| VSpike | mwhudson: I'm not aware of having done anything unusual | 03:25 |
| kiko-zzz | VSpike, sleeping beats trying to understand pretty much any software artifact. good night! :) | 03:25 |
| VSpike | kiko-zzz: night :) | 03:28 |
| VSpike | meteoroid: how can I resolve the issue? | 03:28 |
| VSpike | mwhudson: ^ sorry | 03:28 |
| mwhudson | VSpike: hard to say without knowing more | 03:29 |
| mwhudson | VSpike: i suspect it may make more sense after some sleep :) | 03:29 |
| VSpike | Yeah, you're probably right | 03:30 |
| VSpike | Ah well - g'night | 03:30 |
| === VSpike is now known as VSpike-zzz | ||
| jam | Peng_: it sounds like beuno will try to make rc4 => .deb early tomorrow | 03:52 |
| mkanat | Hey loggerhead question--is the front page supposed to have "Exception: name 'url' is not defined" at the top? | 03:53 |
| bob2 | it's a feature! | 03:56 |
| Peng_ | mkanat: That was fixed quickly. | 03:57 |
| lifeless | Peng_: its in the 1.6 release tarball | 03:57 |
| Peng_ | lifeless: Ah. | 03:57 |
| Peng_ | Whoops. | 03:57 |
| lifeless | Peng_: I think | 03:57 |
| lifeless | http://www.squid-cache.org/bzrview/ | 03:57 |
| lifeless | beuno: ^ is da fugly | 03:58 |
| Peng_ | mkanat: Where do you see this? What version of LH is it running? | 03:58 |
| mkanat | Peng_: http://bzr.everythingsolved.com/ It's running 1.6. | 03:59 |
| Peng_ | Maybe that's a different issue. | 04:01 |
| Peng_ | mkanat: If you have a few minutes, could you try running the trunk? (bzr branch lp:loggerhead) | 04:01 |
| lifeless | Peng_: looks the same as the squid copy | 04:02 |
| lifeless | both are 1.6 | 04:02 |
| lifeless | squid is using a loggerhead.conf, which I think is a mistake, but I've mailed beuno already as to why | 04:03 |
| Peng_ | 1.6 should have the same 'url' fix as the trunk does. | 04:03 |
| lifeless | mkanat: are you using a loggerhead.conf, or serve-branches? | 04:03 |
| mkanat | conf | 04:03 |
| fullermd | jam: I dunno that much about that bug; the devil told me to mark it crit. Or maybe it was lifeless. One of the two... | 04:05 |
| lifeless | Peng_: do you use a loggerhead.conf? | 04:05 |
| Peng_ | Yeah, 1.6 has that fix, so I guess this is a different issue. | 04:05 |
| Peng_ | lifeless: Nope, I use serve-branches. | 04:05 |
| Peng_ | I'm using hte trunk too | 04:06 |
| lifeless | Peng_: try with a loggerhead.conf file, bet it will cause the problem | 04:06 |
| Peng_ | Sorry, but I've never used loggerhead,conf, and I'm lazy. | 04:07 |
| Peng_ | You try serve-branches. :P | 04:08 |
| lifeless | :P | 04:10 |
| mwhudson | ew, the browse view is sure super hideous | 04:17 |
| lifeless | mwhudson: so loggerhead 1.6.1 soon ? | 04:45 |
| mwhudson | i guess | 04:50 |
| lifeless | the listing page is quite a regression | 04:50 |
| thumper | lifeless: gee, what happened? | 05:18 |
| lifeless | http://www.squid-cache.org/bzrview/ | 05:32 |
| lifeless | thumper: ^ | 05:32 |
| thumper | :) | 05:33 |
| lifeless | thumper: see the horrible output? | 05:33 |
| thumper | yes I did | 05:34 |
| Peng_ | Has somebody filed a bug? Should they? | 05:34 |
| lifeless | thats loggerhead 1.6 using loggerhead.conf | 05:34 |
| lifeless | mwhudson: have you? | 05:34 |
| mwhudson | lifeless: no | 05:35 |
| lifeless | I shall | 05:35 |
| lifeless | bug 259273 | 05:49 |
| ubottu | Launchpad bug 259273 in loggerhead "loggerhead.conf usage borked" [Undecided,New] https://launchpad.net/bugs/259273 | 05:49 |
| gour | hi, attempt to merge branch produced with vs import on lp (from cvs) with the branch produced by running tailor on cvs repo gives: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.". by looking at LP, i've found the latest common revision, but the problem is that revision number differ on both branches. how am i supposed to update my local branch (tailor-generated) with the more-up-to-date branch | 08:16 |
| gour | from LP (vsc-import-generated) ? | 08:16 |
| bob2 | revision numbers don't matter | 08:19 |
| lifeless | gour: well bzr thinks of them as totally separate | 08:19 |
| gour | hmm | 08:19 |
| lifeless | gour: they have different file identity | 08:19 |
| gour | lifeless: how is it so? | 08:19 |
| lifeless | gour: because they were separate imports | 08:20 |
| gour | but those are same stuff, only one is more up to date | 08:20 |
| lifeless | gour: if you run bzr inventory --show-ids | 08:20 |
| lifeless | gour: you will see that they may have the same paths but are different file ids | 08:21 |
| lifeless | gour: you can force it to merge, but it will conflict across the whole tree | 08:21 |
| lifeless | gour: the question is, have you been committing to your local tailor generated branch ? | 08:21 |
| gour | lifeless: ahh, it means that import us useful only as one-time affair? | 08:22 |
| gour | lifeless: no, i just imported earlier | 08:22 |
| lifeless | then just replace it with the launchpad one | 08:22 |
| lifeless | ongoing imports are useful, but separate imports generate separate histories | 08:22 |
| gour | that i know...i wanted to see how to merge them in case i'd have some local changes | 08:22 |
| lifeless | in particular with CVS, where 'history' is arbitrary anyhow :) | 08:23 |
| gour | the branches are at https://code.launchpad.net/gnumed | 08:23 |
| gour | heh, that's why i'm pushing GNUmed to adopt bzr :-) | 08:23 |
| gour | lifeless: how to force merge? supplying --force does not help | 08:25 |
| lifeless | gour: merge -r 0..-1 | 08:25 |
| lifeless | gour: and then cry | 08:25 |
| jamesh | gour: you could potentially use tailor to transfer the commits from one branch to the other | 08:26 |
| gour | :-) | 08:26 |
| lifeless | gour: normally, to deal with a local edit in this situation, you'd generate 'bzr diff -r LAST_FROM_CVS..-1' > some_file | 08:26 |
| jamesh | but it is probably best to pick one CVS -> bzr import as the canonical one | 08:26 |
| lifeless | then bzr patch some_file in the import you're keeping | 08:26 |
| gour | jamesh: yeah. | 08:26 |
| gour | if my local branch would be older revision of LP's gnumed with local changes, then merge won't be a problem, right? | 08:28 |
| gour | the branches would have same ids | 08:28 |
| gour | or different vcs import still produces different ids? | 08:29 |
| jamesh | gour: neither tailor or cscvs (what the Launchpad imports use) produce repeatable imports | 08:29 |
| jamesh | they'll have different revision IDs and different file IDs | 08:30 |
| jamesh | both of which are important to "bzr merge" | 08:30 |
| gour | jamesh: so, all the imports listed at https://code.launchpad.net/~vcs-imports/gnumed/trunk are not suitable for merge then? | 08:30 |
| jamesh | gour: if you branch from that import and do work, you'll be able to merge newer changes from that same location | 08:31 |
| jamesh | and merge between branches that derive from that import | 08:31 |
| jamesh | the same goes if you used a tailor generated branch as the canonical import | 08:31 |
| gour | jamesh: ahh, that's what i wanted to hear | 08:31 |
| jamesh | you'll only see problems when you take branches derived from different imports and try to merge between them | 08:32 |
| gour | i can use LP's import, work on the branch and then update from the newer imports which are regularly done | 08:32 |
| jamesh | yes. | 08:33 |
| gour | LP does new import every day... | 08:33 |
| gour | good | 08:33 |
| jamesh | the Launchpad imports are done incrementally | 08:33 |
| gour | ahh, that's the catch ;) | 08:33 |
| jamesh | it doesn't redo the import every day -- it updates the existing import | 08:33 |
| jamesh | similarly, you can maintain a tailor import incrementally | 08:34 |
| gour | however, i do not propose this as normal workflow...the idea is to contribute something via bzr to LP's import and prepare devs to migrate to bzr :-) | 08:34 |
| gour | right...just not mixed the two :-) | 08:34 |
| jamesh | the Launchpad imports don't really help too much for two-way communication | 08:39 |
| jamesh | you can't move changes back to CVS in a way that will be recognised by the CVS -> bzr importer | 08:39 |
| jamesh | if you're lucky, it'll come up as a null merge | 08:39 |
| jamesh | if you're unlucky it'll be merge conflicts | 08:40 |
| gour | well, i'll contribute to bzr branch on LP and let them patch upstream if they don't want to use bzr, but i won't use CVS | 08:41 |
| jamesh | if you're using short term feature branches, this isn't too bad: you can throw away the branch once it gets merged | 08:41 |
| gour | btw, does it make sense to sign for Ubuntero for someone not using Ubuntu, but using LP | 08:42 |
| jamesh | it is up to you | 08:42 |
| jamesh | the only things that require it at the moment are becoming an Ubuntu member and getting access to Launchpad's personal package archive feature | 08:43 |
| jamesh | if those don't interest you, then you aren't missing out on anything | 08:43 |
| gour | hmm, ppa | 08:43 |
| gour | that might be handy | 08:44 |
| gour | but that's, again, only ubuntu pkgs, not source releases, right? | 08:44 |
| jamesh | right. | 08:45 |
| gour | heh, then i do not need it...which does not prevent me to follow the good codes uven without signing :-) | 08:45 |
| gour | *even | 08:46 |
| robsta | ping bkor | 09:06 |
| === gour is now known as LaskoPivo | ||
| === LaskoPivo is now known as gour | ||
| === VSpike-zzz is now known as VSpike | ||
| VSpike | I'm confused how files can be in the removed, added and conflicts sections of bzr status? | 09:51 |
| VSpike | command output at http://www.pastebin.com/m422b0b96 | 09:51 |
| VSpike | Sorry that should be http://pastebin.com/m422b0b96 | 09:52 |
| leopold | Hi All. I have a problem with a bzr repository returning a "Revision .. not present in .." error, does anyone have the time to help me out with the problem? | 10:06 |
| lifeless | VSpike: what is confusing? | 10:20 |
| VSpike | lifeless: I don't understand what it is telling me. From my point of view, I have done nothing different other than change the contents of the binary files Bin/Geonix.dll and Bin/Geonix.pdb, which normally results in them showing as changed | 10:28 |
| VSpike | I don't understand how to resolve the conflict and commit the changes | 10:28 |
| enquest | when I want to install bzr 'aptitude install bzr' it wants to install x-server and so on... ??? | 10:33 |
| enquest | I only need command line with bzr | 10:33 |
| enquest | any tips? | 10:33 |
| lifeless | VSpike: so, being in conflict means bzr couldn't decide for you how to do a merge for you | 10:34 |
| lifeless | VSpike: if you see the one file both deleted and added, it means someone had added them in parallel elsewhere, so you have the same file /name/ with two different histories, and you need to choose one | 10:34 |
| lifeless | VSpike: use bzr mv and del to arrange the tree how you want, then bzr resolve NAME | 10:34 |
| lifeless | enquest: uhm, its bzrtools I think | 10:35 |
| lifeless | enquest: it uses graphviz or something, and that pulls in X | 10:35 |
| lifeless | enquest: if you are using aptitude, try going in via the gui | 10:35 |
| lifeless | sudo aptitude | 10:36 |
| lifeless | then /, bzr, i | 10:36 |
| lifeless | and then edit the actions list and change stuff | 10:36 |
| VSpike | enquest: I've solved that problem on a debian server - just trying to remember how | 10:37 |
| enquest | this is a securtiy problem using bzr on your server... If you not good at managing servers you don't know these things | 10:37 |
| lifeless | enquest: huh? | 10:38 |
| luks | aptitude installs recommended packages by default? | 10:38 |
| VSpike | luks: it's configurable | 10:39 |
| VSpike | enquest: try "sudo aptitude install bzr --without-recommends" | 10:39 |
| enquest | ok I did not know that with apt-get you don't have that problem | 10:39 |
| enquest | VSpike, thanxs | 10:39 |
| VSpike | enquest: or use the ncurses interface as lifeless suggested | 10:39 |
| VSpike | lifeless: sorry if i'm being obtuse, but I can't see how it got to this state... | 10:44 |
| VSpike | lifeless: I'm working in a single branch, doing modify/commit, modify/commit.. and occasionally modify/commit/push | 10:45 |
| VSpike | lifeless: so there should have been no merges into this branch | 10:45 |
| Peng_ | Some sort of file name case wackiness, maybe? | 10:46 |
| VSpike | Peng_: I wondered that, but they show the same in bzr stat at least | 10:48 |
| Peng_ | Yeah.. it's still possible though | 10:48 |
| VSpike | The irony is, this is a binary generated by the build of a sub-project | 10:49 |
| VSpike | I only check it in so that I can recreate a past situation exactly, because bzr doesn't allow me to connect the two projects yet | 10:49 |
| VSpike | So if I delete it, it will just get regenerated | 10:50 |
| lifeless | VSpike: could you pastebin the output | 10:54 |
| VSpike | lifeless: of? | 10:55 |
| VSpike | I just did "bzr mv Bin | 10:55 |
| VSpike | I just did "bzr mv Bin\Geonix.dll Bin\Geonix.dll.old" and the same the .pdb file | 10:55 |
| VSpike | But not sure I'm any better off | 10:55 |
| VSpike | lifeless: you want bzr stat --show-ids again? | 10:56 |
| lifeless | VSpike: again? | 11:15 |
| lifeless | VSpike: anyhow, I'm heading off sorry | 11:15 |
| VSpike | lifeless: I posted it back aways... | 11:16 |
| lifeless | VSpike: perhaps Peng_ or someone else still awake can comment on a pastebin output for you | 11:16 |
| VSpike | http://pastebin.com/m422b0b96 | 11:16 |
| lifeless | so | 11:17 |
| lifeless | to get conflicts, you _must_ have done a pull, or merge, or update | 11:17 |
| VSpike | now http://pastebin.com/d49a67117 | 11:17 |
| VSpike | lifeless: anyway I can check that in a log? | 11:17 |
| lifeless | as for the delete + add pairs; simplest thing would be to save the copy you want to keep, bzr rm the new file, bzr revert PATH to restore the old fileid, then copy the one you want back in | 11:17 |
| lifeless | bzr --version will list your log file | 11:18 |
| lifeless | bzr commands are listed in the log | 11:18 |
| lifeless | I must go though - good luck | 11:18 |
| VSpike | thanks! | 11:18 |
| awilkins | Arrgh, rc4 happened while I wasn't looking | 11:23 |
| awilkins | :-) Is BB back up? | 11:24 |
| awilkins | Guess not. | 11:25 |
| LarstiQ | moin. | 11:25 |
| ignas | mwhudson: it seems that bzr developers have fixed my bug yesterday, and the fix is going to make it to 1.6rc4 :) | 11:59 |
| mwhudson | ignas: i/we found another bug that might mean a 1.6c5 :( | 12:00 |
| ignas | oh. What's the number? | 12:00 |
| mwhudson | ignas: https://bugs.edge.launchpad.net/bzr/+bug/259275 | 12:01 |
| ubottu | Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [High,Triaged] | 12:01 |
| ignas | mwhudson: hmm, not sure I understand what operations I should be avoiding if I don't want to break things... | 12:04 |
| mwhudson | ignas: this bug is only likely to affect launchpad, realistically | 12:04 |
| ignas | should I not try pushing to my remote knit repository from my stacked repository for example? | 12:04 |
| mwhudson | no | 12:04 |
| LarstiQ | no, don't do that, or no, no problem? | 12:05 |
| mwhudson | as in, you should be fine | 12:05 |
| LarstiQ | pfew :) | 12:05 |
| mwhudson | english sucks | 12:05 |
| kiko_ | hmmm | 12:05 |
| kiko_ | bzr st segvs for me in my /etc! | 12:05 |
| kiko_ | that is very fun | 12:05 |
| mwhudson | kiko_: exciting | 12:05 |
| kiko_ | mwhudson, SPEAKING of segvs.. | 12:06 |
| kiko_ | #0 0xb7e54cbf in memcpy () from /lib/libc.so.6 | 12:07 |
| kiko_ | #1 0x08092895 in PyString_FromStringAndSize () | 12:07 |
| kiko_ | #2 0xb7778d4e in ?? () | 12:07 |
| kiko_ | from /usr/lib/python2.5/site-packages/bzrlib/_dirstate_helpers_c.so | 12:07 |
| kiko_ | mwhudson, I guess this is known..? | 12:07 |
| kiko_ | Bazaar (bzr) 1.5 | 12:07 |
| mwhudson | kiko_: not by me | 12:07 |
| kiko_ | okay, will try and file a bug then | 12:08 |
| mwhudson | i can imagine a corrupt dirstate tripping up the c parser or something | 12:08 |
| beuno | lifeless, ew, template for start-loggerhead seems broken :/ | 13:08 |
| * beuno waves | 13:08 | |
| scgatai_ | hi | 13:10 |
| pickscrape | beuno: the breadcrumbs branch is ready for a further review | 13:12 |
| beuno | pickscrape, cool. I'll take a look at it after my coffee :) | 13:13 |
| pickscrape | beuno: no rush, just letting you know :) | 13:15 |
| pickscrape | Could anyone point me at an explaination of when I need to use the record command when using a loom? | 13:57 |
| Tak | ok, if my bzr-svn checkout failed (ERROR: revision "blah" already present in "revisions"), is there anything I can do to work around it? | 14:38 |
| beuno | jam, building rc4 debs now :) | 15:34 |
| jam | beuno: before you spend too much time, mwhudson wants an rc5 | 15:35 |
| jam | I'd like to at least look at the bug first | 15:35 |
| beuno | jam, ah, heh, ok. I'll start looking intro scripting then | 15:35 |
| jam | mwhudson: ping | 15:53 |
| jam | You have a bug, but do you have a possible fix? | 15:53 |
| jam | Even just an outline of the fix | 15:53 |
| cr3 | how can I determine to which host bzr launchpad-login is trying to connect exactly? the --verbose flag doesn't show anything and the error says: ERROR: Connection error: while sending GET /%7Ecr3/%2Bsshkeys: (111, 'Connection refused') | 15:58 |
| cr3 | seeing the url, I guess https://launchpad.net. I thought at first it might be the openid url, nevermind | 15:59 |
| jam | cr3: default URL | 16:01 |
| jam | BZR_LP_XMLRPC_URL=http://xmlrpc.launchpad.net/bazaar/ | 16:01 |
| jam | you can set that in your environment, I believe, to override it | 16:01 |
| jam | Oops, I'm wrong, it is https://xmlrpc.launchpad.net/bazaar/ | 16:01 |
| jam | the 's' is there | 16:02 |
| cr3 | jam: telnet xmlrpc.launchpad.net 443 works, but I'm still getting the same error message | 16:12 |
| cr3 | jam: I then tried setting the environment variable, just in case, same thing | 16:13 |
| === kiorky_ is now known as kiorky | ||
| awilkins | Is bzr push really really slow over a network share if you have virus checking of network drives on? | 16:27 |
| LarstiQ | possibly, I know I've had antivirus software cause locking problems for bzr before | 16:32 |
| jam | cr3: are you behind a proxy? It is a known problem with python's xmlrpc implementation that it doesn't respect http_proxy | 16:54 |
| jam | awilkins: packs or knits? Knits would probably be extra bad because we would touch lots of files | 16:55 |
| awilkins | jam: Packs | 16:55 |
| jam | though I could also see a repack of a .pack file causing issues if the software had to virus check the whole pack file | 16:55 |
| awilkins | jam: It's rich-root-pack, 210MB total, largest pack 160MB | 16:55 |
| jam | though it is all compressed data | 16:55 |
| jam | awilkins: well, we might read *parts* of some files | 16:55 |
| jam | which may cause the virus checker to read the whole thing? | 16:56 |
| jam | So we might read 100k from your 160MB file | 16:56 |
| awilkins | jam: I wonder if reading multiple regions of that large pack makes it check the whole file each time | 16:56 |
| jam | and then your virus checker decides | 16:56 |
| jam | it needs to read all 160 MB | 16:56 |
| awilkins | I'll run it with filemon active next time | 16:56 |
| jam | also, we may go back multiple times to portions of the file | 16:56 |
| jam | which might trigger similar issues | 16:56 |
| jam | (one read from 10-100, another at a later time 1000-1100 etc | 16:57 |
| awilkins | I'm note sure it's the vchecker | 16:57 |
| awilkins | I believe I tried it with the service stopped once | 16:57 |
| awilkins | Anyhow, it's nearing 1700, and I need to catch my train | 16:58 |
| awilkins | back-in-a-bit | 16:58 |
| jam | kiko_: I just submitted a patch for the dirstate parser which should at least give a proper traceback rather than a segfault. | 17:01 |
| cr3 | jam: I am behind a proxy but I don't have the http_proxy environment variable set and I have an iptables rule explicitly allowing connections to xmlrpc.l.n, bazaar.l.n and l.n | 17:03 |
| jam | cr3: can you try it with "bzr launchpad-login -Derror" ? | 17:04 |
| jam | that should give you a traceback that you can pastebin for me | 17:04 |
| cr3 | jam: http://pastebin.com/d36c2c2ae | 17:06 |
| cr3 | jam: just to make sure, env | grep -i proxy returns nothing | 17:08 |
| cr3 | jam: also, I'm tailing the logs on the proxy and nothing is appearing when running launchpad-login | 17:10 |
| jam | cr3: so, after the xml call, we then do an HTTP fetch, which *does* respect the http_proxy setting | 17:10 |
| jam | And that is the point that is failing | 17:10 |
| jam | The http fetch is going to https://launchpad.net/~user/+sshkeys | 17:11 |
| jam | Try setting http_proxy and see if it works | 17:11 |
| mxpxpod | I made a branch from a branch located on my local file system... I moved the branch I created and now I can't pull from the original branch... it's saying the parent is not accessible given a base and a relative path... is there a way to fix that? | 17:12 |
| cr3 | jam: worked! | 17:13 |
| jam | cr3: so it seems you got the xmlrpc stuff to go through without the proxy, but not https://launchpad.net requests | 17:19 |
| jam | mxpxpod: 'bzr pull --remember /new/location' | 17:19 |
| mxpxpod | jam: ah, thanks... I figured out I can also modify .bzr/branch/branch.conf | 17:20 |
| mxpxpod | jam: but I figured there was a better way to do it | 17:20 |
| alexreg | hi | 17:26 |
| alexreg | i've just upgraded to bzr 1.5 and i'm getting an error when using the --use-existing-dir option now | 17:26 |
| alexreg | bzr: ERROR: extra argument to command push: use-existing-dir | 17:27 |
| alexreg | couldn't find any notes on the changes to this argument | 17:27 |
| alexreg | this is for the push command of course | 17:28 |
| alexreg | any ideas please? | 17:28 |
| Tak | is there a way to "force" bzr to invoke bzr-svn for a checkout over http? | 17:29 |
| Tak | I keep getting "bzr: ERROR: Transport error: Server refuses to fullfil the request" | 17:30 |
| jam | alexreg: try it with '--no-plugins' | 17:30 |
| jam | I would guess that a plugin is decorating "bzr push" and causing problems | 17:30 |
| jam | Tak: "svn+http://" I believe | 17:30 |
| alexreg | jam: now i get "bzr: ERROR: extra argument to command push: no-plugins" | 17:31 |
| jam | alexreg: "are you using --no-plugins" ? | 17:32 |
| Tak | jam: perfect, thanks! | 17:32 |
| jam | not "-- no-plugins" | 17:32 |
| alexreg | i upgraded from v1.2 but it was occurring even then. so i'm not sure in which version it last worked correctly | 17:32 |
| alexreg | jam: yeah | 17:32 |
| jam | because '--no-plugins' is a global arg that is always parsed before commands are handled, so something weird is going on | 17:32 |
| jam | alexreg: can you pastebin the last part of your ~/.bzr.log ? | 17:32 |
| alexreg | sure. one min | 17:33 |
| alexreg | jam: http://pastebin.com/m3f3f5e10 | 17:35 |
| alexreg | the first is with no command line args, the second with use-existing-dir and the third with both use-existing-dir and no-plugins | 17:36 |
| jam | alexreg: well when you did 'use-existing-dir' you didn't supply the '--' it is '--use-existing-dir' | 17:37 |
| jam | similarly for '--no-plugins' | 17:37 |
| jam | For example: [u'push', u'bzr+ssh://...', u'no-plugins', u'--', u'use-existing-dir'] | 17:38 |
| alexreg | sorry. i *did* include the "--" when executing bzr | 17:38 |
| alexreg | just not on IRC | 17:38 |
| jam | That means you wrote "bzr push bzr+ssh://... no-plugins -- use-existing-dir | 17:38 |
| jam | rather than | 17:38 |
| jam | bzr push bzr+ssh:// --no-plugins --use-existing-dir | 17:38 |
| alexreg | yeah that's what i did.... | 17:38 |
| jam | alexreg: notice that you need '--' before the option, and no spaces | 17:38 |
| jam | alexreg: not according to the bzr log file | 17:39 |
| jam | What are you using as a shell? | 17:39 |
| alexreg | hrmm could it be because i'm executing in powershell? | 17:39 |
| alexreg | ^^ | 17:39 |
| jam | alexreg: sounds like | 17:39 |
| jam | Sounds like powershell is doing weird things to your command line | 17:39 |
| jam | I don't know powershell myself | 17:39 |
| alexreg | yeah probably | 17:39 |
| alexreg | ok | 17:40 |
| alexreg | putting the option in quotes seems to fix it | 17:40 |
| alexreg | thanks :) | 17:40 |
| jam | alexreg: bad PoS, :) | 17:43 |
| jam | of course, PoS is a great acronym for it anyway :) | 17:43 |
| LarstiQ | alfonsodg: is that the old and venerable *nix powershell, or the windows one? | 17:45 |
| jam | LarstiQ: Windows | 17:45 |
| jam | and alexreg left | 17:45 |
| jam | I don't think alfonsodg knows :) | 17:45 |
| jam | sorry for the double ping a l f o | 17:45 |
| LarstiQ | bweh | 17:46 |
| Tak | has anybody encountered 'ERROR: revision "blah" already present ...' when checking out from a svn repo? | 18:22 |
| pickscrape | pygi! How goes cheezburger? | 18:41 |
| === mw is now known as mw|lunch | ||
| pygi | pickscrape, sorry, will poke later | 18:51 |
| jbalint | Hi LarstiQ | 18:58 |
| LarstiQ | hey jbalint | 18:58 |
| jbalint | LarstiQ: i came here a few days ago, with a problem with putty link on windows and aliases | 18:59 |
| LarstiQ | jbalint: right, I remember that | 18:59 |
| jbalint | LarstiQ: the problem is i am using non-22 port and the command executed is "plink.exe -ssh ...." and -ssh forces this to use port 22 :| | 18:59 |
| LarstiQ | jbalint: is there no way around that? | 19:00 |
| jbalint | LarstiQ: i havent looked in bzr code to see how it determines the command, but i do not have any solution thus far, except using paramiko with the port given | 19:02 |
| LarstiQ | jbalint: is the -ssh needed on plink? And if so, can plink -ssh uses something else than port 22? | 19:02 |
| LarstiQ | jbalint: if not then we would need to document that plink can only be used with port 22 I think :( | 19:03 |
| jbalint | LarstiQ: it will work if i add -P on the command line, but this is saved in the alias. i'm not sure why -ssh overrides it. maybe i should file a bug with putty | 19:04 |
| jbalint | LarstiQ: ok, i just checked, it seems to work if i put the port in the bzr+ssh url too | 19:04 |
| LarstiQ | jbalint: is there a way we can query plink for what the alias expands to? | 19:05 |
| jbalint | LarstiQ: not that i know of besides exporting it from the registry | 19:07 |
| jbalint | LarstiQ: but part of the benefit is that you shouldnt need to do that because you can use the alias in place of 'host' for the plink/ssh command and they both work the same way | 19:08 |
| jbalint | LarstiQ: do you know why the -ssh flag is needed? | 19:08 |
| LarstiQ | jbalint: I do not, I hoped you would :) | 19:08 |
| jbalint | -ssh -telnet -rlogin -raw | 19:08 |
| jbalint | force use of a particular protocol | 19:08 |
| jbalint | thats what plink.exe help says. | 19:09 |
| LarstiQ | jam: do you know why we supply -ssh to plink? It seems to override non-22 ports in aliases | 19:09 |
| jam | LarstiQ: well, my guess is to keep it from trying to telnet to the other location, at least what from jbalint says | 19:10 |
| jam | jbalint: so if you just 'plink host.com' rather than an alias, does it do something other than ssh? | 19:11 |
| jam | If so, then it sounds like removing -ssh, would mean that people would need to configure an alias for every machine they want to connect to | 19:11 |
| jam | rather than "just working" | 19:11 |
| jam | Personally, I don't like plink much, and just use paramiko | 19:12 |
| jam | plink has a lot of weird bits | 19:12 |
| jam | like not remembering the username in a saved session | 19:12 |
| jam | etc. | 19:12 |
| jbalint | well i just ran plink host.com and it does ssh | 19:12 |
| LarstiQ | does paramiko provide any of the alias/session functionality of plink? | 19:13 |
| LarstiQ | jbalint: and if you do plink host -P 23 ? | 19:13 |
| jbalint | seems to support pageant | 19:13 |
| jbalint | well i get connection refused :) dont have telnet running | 19:14 |
| LarstiQ | jbalint: I'm thinking the -ssh/-telnet is to force a protocol when the autodetection for a port comes up with something else | 19:15 |
| jam | LarstiQ: paramiko supports pageant, but no, doesn't provide aliases (that I know of). But bzr+ssh://user@host:port/ provides most of what you need. | 19:15 |
| jam | jbalint: which is why we pass -ssh :) | 19:15 |
| jam | LarstiQ: for most of my time, I used cygwin's ssh.exe | 19:15 |
| LarstiQ | jam: afaics -ssh only helps if it's port 23 | 19:15 |
| jam | LarstiQ: ah, I missed that part | 19:15 |
| jbalint | i dont know if detection is based on port. with both of those protocols, the server sends some header info upon connect, right? so it could be based on that | 19:16 |
| jam | jbalint: so, if you want to work out more details of how to use plink properly, I think we're happy to take patches, etc. I think plink just doesn't get a lot of support because the other solutions work, and in some cases work better. | 19:16 |
| jam | (Like being able to prompt for a password when pageant doesn't have your key) | 19:16 |
| jbalint | but you're passing -batch, thats why it doesnt prompt | 19:16 |
| jam | jbalint: because if we don't pass -batch it hangs waiting for input because it can't connect to the terminal | 19:17 |
| jam | so we would rather it *fail* and get on with it | 19:17 |
| jam | rather than hang indefinitely | 19:17 |
| jbalint | ol | 19:17 |
| jbalint | *ok | 19:17 |
| jam | interestingly enough cygwin's ssh.exe can connect to the terminal, so I don't really understand *why* plink cannot | 19:17 |
| === kiko_ is now known as kiko | ||
| jbalint | i'll try to get some ideas on plink and ssh. thanks alot for the info so far | 19:18 |
| kiko | jam: cool. unfortunately it looks like I've got a corrupted tree.. somehow. | 19:18 |
| jam | kiko: well, I can say that we truncate + write (I *think* in that order) so if you somehow managed to do one without the other (power fail, kill -9, etc) it would be possible to have an inconsistent dirstate | 19:19 |
| jam | kiko: I posted to the bug a workaround using 'bzr co --lightweight' | 19:19 |
| jam | which is also in the bug that yours is a dup of | 19:19 |
| kiko | jam: oh, my bug is a dupe? I searched quite a bit for it | 19:22 |
| jam | kiko: the problem is that some platforms segfault others give MemoryError | 19:23 |
| jam | kiko: bug #186014 is the same bug | 19:24 |
| ubottu | Launchpad bug 186014 in bzr "MemoryError on diff/commit due to corrupted dirstate" [High,Fix committed] https://launchpad.net/bugs/186014 | 19:24 |
| kiko | ah! | 19:28 |
| kiko | how interesting | 19:28 |
| jam | kiko: yeah, the problem is effectively passing a negative number to malloc | 19:28 |
| jam | I assume some platforms cast it to unsigned | 19:28 |
| jam | and get a malloc failure | 19:28 |
| jam | others just segfault | 19:28 |
| jam | as you saw :) | 19:28 |
| fullermd | Erk. segfault? That sounds bogus. malloc is defined to take size_t, which is unsigned... | 19:37 |
| === mw|lunch is now known as mw | ||
| Toranin | aargh, had to reboot, now I have to start the svn-import over again...and it was almost done, too. Looks like another week until I can play with bzr... | 19:49 |
| jam | fullermd: well, it is PyString_FromStringAndSize, I don't know if it strictly uses malloc under the covers. It might be a PyMalloc which could have more issues, etc. | 19:56 |
| jam | Toranin: I believe it starts from where it left off | 19:56 |
| Toranin | jam: I'll try it, but I don't think it got killed cleanly so we'll see how well it goes | 19:58 |
| === jakobb is now known as grutte_pier | ||
| === mtaylor_ is now known as mtaylor | ||
| mwhudson | jam: i think this might be maybe sort of a fix: http://pastebin.ubuntu.com/38892/ | 20:39 |
| mwhudson | it makes test_sprout_stacking_policy_handling fail, but i'm not sure that's a bad thing | 20:40 |
| jam | mwhudson: does that ignore the value or always create a new one? | 20:40 |
| jam | mwhudson: specifically, what fix are you looking for | 20:40 |
| jam | should 'bzr push lp:' create a new branch format | 20:40 |
| jam | so it can stack | 20:40 |
| mwhudson | no | 20:40 |
| jam | or just ignore the fact that it was auto-requested to stack | 20:40 |
| mwhudson | right | 20:41 |
| mwhudson | _my_ idea, not talked this through with anyone else | 20:41 |
| mwhudson | would be for the default stacking to only apply when the formats allow stacking | 20:41 |
| jam | mwhudson: sure, I'm a bit hesitant about the whole auto-stacking anyway, but if we at least required the user to be using a stackable source, then there is *some* good. And it sure would be shiny | 20:41 |
| mwhudson | otherwise people are going to be Surprised(tm) | 20:41 |
| jam | mwhudson: well, they might be surprised to have auto-stacking anyway... | 20:42 |
| mwhudson | jam: well, if there are no format surprises they hopefully won't really notice | 20:42 |
| jam | mwhudson: well, what about when --1.6 is the default format? | 20:43 |
| mwhudson | other than the fact that initial pushes take less time | 20:43 |
| jam | I suppose as long as it is only stacking within the LP universe | 20:43 |
| jam | there isn't a chance for data loss | 20:43 |
| mwhudson | another possible fix for 1.6 would be to disable the auto-stacking stuff somehow | 20:46 |
| jam | mwhudson: well, auto-stacking was approved for 1.6, I'm not trying to break it | 20:47 |
| jam | I think we probably want a fix that means lp doesn't have to do something like check the bzr client version | 20:47 |
| jam | mwhudson: Though, what if the branch format is 1.6 and _stack_on is set, will it still stack (with your patch)? | 20:48 |
| mwhudson | jam: not sure | 20:48 |
| mwhudson | i guess i should check | 20:48 |
| jam | mwhudson: so I would probably say the best fix is to have the check for the stack_on policy know if the source supports it | 20:49 |
| mwhudson | jam: it seems it does still respect the stacking policy with my fix | 20:52 |
| mwhudson | jam: and it fixes my testcase too, although it still prints | 20:52 |
| mwhudson | Using default stacking branch b1 at bzr+ssh://localhost//home/mwh/canonical/checkouts/trunk/sourcecode/t/ | 20:52 |
| mwhudson | even though it in fact doesn't use it, which is a bit bogus | 20:53 |
| jam | mwhudson: isn't telling them that a good thing? Or it says that and then ignores it | 20:53 |
| mwhudson | it says it, then ignores it | 20:53 |
| jam | ok, that is a bit bogus :) | 20:53 |
| jam | and considering all pushes creating new branches will say that ... | 20:53 |
| jam | Makes me wish I had reviewed the repository policy patch myself | 20:55 |
| jam | It certainly seems to have made following the code logic a bit more complex | 20:55 |
| jam | mwhudson: what about passing in "default_format_supports_stacking" to the "determine_repository_policy" function? | 20:56 |
| jam | or ... "source_format_supports_stacking" | 20:56 |
| mwhudson | jam: i think that would probably be more clear than hacking around trying to work with the data that's there already | 20:57 |
| jam | I'm a bit confused as to where things are happening ATM | 20:58 |
| jam | It seems that both the branch format and the repository format need to support stacking | 20:58 |
| jam | and they both figure that out at different times :( | 20:58 |
| mwhudson | oh that's the other fun thing | 20:58 |
| jam | mwhudson: so it sounds like the specific bug is that the repository figures out it needs to be stacked | 20:59 |
| jam | but the branch does not | 20:59 |
| mwhudson | in my test case, the broken branch has a stacking compatible repo but not branch | 20:59 |
| mwhudson | jam: yes | 20:59 |
| jam | so you end up creating a target where the repo thinks it is stacked | 20:59 |
| jam | and doesn't copy revisions | 20:59 |
| jam | but the branch doesn't | 20:59 |
| jam | so it doesn't include the reference | 20:59 |
| jam | ugh. | 20:59 |
| mwhudson | yeah, you even end up with a 'stacked_on_url' in branch.conf | 20:59 |
| mwhudson | but the branch doesn't look at it, of course | 20:59 |
| jam | I'm very hesitant to add a kludge on top of the existing kludge | 21:00 |
| mwhudson | right | 21:00 |
| jam | especially when all the people who *did* the work are on vacation | 21:01 |
| jam | I'm tempted to disable the whole lot just to get a clean 1.6 out the door | 21:01 |
| mwhudson | +1 from me | 21:02 |
| jam | which would (in a way) show the colossal blunder of delaying 1.6 to get Stacked working | 21:02 |
| mwhudson | i guess i'd like to hear what jml and thumper say | 21:02 |
| jam | the whole reason it was delayed was stacking | 21:02 |
| jam | round and round we go :( | 21:02 |
| mwhudson | i think everyone realizes what a terrible idea that was now :( | 21:02 |
| fullermd | Well, if we disable it, and release 1.7, we can pretend... | 21:03 |
| jam | mwhudson: so why in your example | 21:04 |
| jam | doesn't it find that the branch format needs to be upgraded | 21:04 |
| jam | consider line 1093 of bzrdir.py | 21:04 |
| jam | isn't it deciding the Branch policy based on the repo policy? | 21:04 |
| jam | mwhudson: in other words, pushing to lp would always create 1.6 branches and repos | 21:05 |
| jam | which you don't really want | 21:05 |
| jam | but at least they wouldn't be *broken* | 21:05 |
| mwhudson | yes, that would be almost as bad | 21:05 |
| mwhudson | um, i did look into this but i forget | 21:05 |
| vreixo | hi guys! | 21:09 |
| vreixo | can I ask a little doubt I have? | 21:09 |
| jam | ? | 21:09 |
| vreixo | I was working with two branches, then I merged one into the other | 21:10 |
| mwhudson | anyway, i've only just got up, so i need to breakfast and stuff before i can really think clearly... | 21:10 |
| vreixo | and together with the merge I did a change in a file | 21:10 |
| vreixo | after that I did several commits | 21:10 |
| vreixo | now I want to revert the change done in the merge commit | 21:10 |
| vreixo | but not the merge itself | 21:10 |
| vreixo | is that possible? | 21:11 |
| vreixo | I use bzr 1.5 | 21:11 |
| jam | mwhudson: well 'bzr branch' creates a new format branch under those conditions | 21:13 |
| jam | mwhudson: I think the problem is "bzr branch" versus "bzr push" where "branch" uses .sprout() and "push" uses ".clone()". | 21:13 |
| jam | mwhudson: I think martin fixed up 'sprout()' but didn't fix 'push()' | 21:13 |
| jam | sorry, .clone() | 21:13 |
| mwhudson | jam: hmm, so the bug isn't so bad in bzr.dev it seems, we don't create a branch with mainline ghosts | 21:13 |
| mwhudson | jam: that sounds right (about clone vs sprout) | 21:14 |
| jam | vreixo: well, you can 'bzr revert' just the file | 21:14 |
| mwhudson | jam: but there's still the default branch/stacked repo thing | 21:14 |
| jam | vreixo: but generally tweezing apart what was done by the merge and what was done by *you* is difficult | 21:14 |
| jam | which is why we don't let you merge with uncommitted changes | 21:14 |
| jam | and recommend that you only do enough to get the conflicts resolved before merging | 21:14 |
| vreixo | jam: yeah, that's the problem | 21:14 |
| jam | vreixo: so doing "bzr revert -r XX file" isn't fine-grained enough? | 21:15 |
| vreixo | jam: no it isn't | 21:15 |
| jam | mwhudson: sure, it automatically upgrades when you have a target that says you should stack | 21:15 |
| vreixo | as it reverts the changes in the merged branch | 21:15 |
| jam | which doesn't sound like what we want. | 21:15 |
| mwhudson | jam: right | 21:15 |
| jam | vreixo: so the same file included both | 21:15 |
| jam | mwhudson: and is a problem because we *do* want to auto-upgrade if the user says "--stack" | 21:16 |
| jam | and all the other crazy things that have gone into the policy idea | 21:16 |
| jam | mwhudson: I really feel like some of this wasn't well thought through | 21:16 |
| vreixo | jam: what is strange is that I can see the diff with only the changes I want to revert, but I have no way to revert it | 21:16 |
| vreixo | it would be great to have such feature | 21:16 |
| jam | vreixo: how do you get that diff? | 21:16 |
| jam | I would guess you can do "bzr merge . -r XXXX" with the same parameters as the diff | 21:17 |
| mwhudson | jam: indeed, and i don't think there's any way to not do the suggested stacking at the moment :/ | 21:17 |
| mwhudson | jam: gee, you think? | 21:17 |
| jam | vreixo: well, reverse them | 21:17 |
| jam | vreixo: so if you do "bzr diff -r 10.1.1..11" to get the diff, do "bzr merge . -r 11..10.1.1" to revert it | 21:17 |
| jam | mwhudson: And I'm extra sad because everyone left this week. Why did they all pick the *same* week, and why did we pick it to be the release week.... | 21:18 |
| jam | mwhudson: I might just punt... but I *really* wanted to force 1.6 out the door | 21:18 |
| mwhudson | jam: i would support dropping/disabling looking at the default_stacked_on url | 21:19 |
| vreixo | jam: with bzr diff -r366..364.1.29 | 21:19 |
| mwhudson | jam: and releasing everything else | 21:19 |
| vreixo | jam: oh, let me try! | 21:19 |
| jam | vreixo: so "bzr merge . -r 364.1.29..366" | 21:19 |
| jam | mwhudson: good enough | 21:19 |
| mwhudson | jam: i so very don't want to have to implement client version blacklisting in launchpad | 21:19 |
| jam | mwhudson: yeah, that would be extra crummy | 21:20 |
| vreixo | jam: bad thing! | 21:21 |
| vreixo | after bzr st I get an error: | 21:21 |
| vreixo | jam: bzr: ERROR: exceptions.KeyError: 'pop(): dictionary is empty' | 21:21 |
| * mwhudson afk for a few minutes | 21:23 | |
| jam | vreixo: you're using bzr 1.5, right? | 21:24 |
| vreixo | yes | 21:25 |
| jam | 1.6 won't give you that, and you can "bzr revert" to get back to where you want to be | 21:25 |
| jam | vreixo: actually just "bzr revert --forget-merges" | 21:25 |
| vreixo | jam: it was my problem | 21:25 |
| vreixo | what I want was to do bzr merge . -r 366..364.1.29 | 21:25 |
| vreixo | but I did bzr merge . -r364.1.29..366 | 21:25 |
| vreixo | anyway, the error is ugly,,, | 21:26 |
| jam | vreixo: sure, the error has been fixed in future versions | 21:26 |
| vreixo | good! | 21:26 |
| jam | and 'bzr revert --forget-merges' will get rid of it, though you want "bzr revert' right now to get back to clean state | 21:26 |
| vreixo | bzr revert worked properly | 21:27 |
| vreixo | then I did the merge with the correct revision order and all is ok now | 21:27 |
| vreixo | thanks! | 21:27 |
| vreixo | one more question, can I do that with only one file | 21:27 |
| vreixo | or I need to revert later the files I don't want to revert originally? | 21:28 |
| hendrixski | If I have an ubuntu server I want to publish a bzr branch to, which sftp program should I use? Or is there some package I should install that makes the server a great repo for bzr projects? | 21:29 |
| jam | vreixo: I believe "bzr merge filename -r 364...." should do what yo uwant | 21:29 |
| jam | hendrixski: I would probably just install openssh server | 21:29 |
| jam | hendrixski: and possibly 'bzr' itself | 21:30 |
| jam | if you want to be able to "bzr push bzr+ssh://server/" | 21:30 |
| jam | There are other packages you might consider (trac+bzr, loggerhead, etc) but they all require a bit of setup. | 21:30 |
| vreixo | jam: anyway it is fixed now. Thanks! | 21:30 |
| jam | vreixo: Did the 'bzr merge filename' work for you? | 21:30 |
| vreixo | jam: did not test, I had already reverted the other files... | 21:31 |
| hendrixski | jam: yeah, I'm not looking for setup trouble. just openssh does it eh? and I can push fun new branches to it whenever I want? | 21:31 |
| jam | hendrixski: 'openssh' server and not client (of course), but yeah, it will provide sftp support | 21:32 |
| jam | I would recommend installing bzr as well | 21:32 |
| jam | but that isn't required | 21:32 |
| hendrixski | k, actually, who knows, I might occasionally need to tweek something while on the server itself, bzr might be good there | 21:33 |
| hendrixski | I would be able to access whatever bzr project is uploaded to the server, right? | 21:33 |
| jam | hendrixski: generally | 21:34 |
| jam | There is a lot of possibilities here | 21:34 |
| * hendrixski tries uploading the project | 21:35 | |
| jam | mwhudson: what do you think about: http://pastebin.com/m49e6e411 | 21:35 |
| mwhudson | jam: looks good to me | 21:36 |
| mwhudson | jam: it will make a small pile of tests fail | 21:36 |
| jam | mwhudson: yeah, but I'll take care of those :) | 21:37 |
| mwhudson | jam: my vote doesn't fully count though :) | 21:38 |
| jam | mwhudson: well, when 4/6 core devs are AFK, there are only 2 of us to approve | 21:38 |
| jam | so non-core's get a lot bigger say | 21:38 |
| * LarstiQ plays innocent bystander | 21:38 | |
| jam | I guess there are a few that still have an official BB vote | 21:39 |
| jam | like LarstiQ and jelmer | 21:39 |
| hendrixski | jam: yay! it worked! I needed python-paramiko first, but I got it. Thanks for spotting me... it's the end of a work day | 21:39 |
| jam | And I abuse them as much as I can right now | 21:39 |
| LarstiQ | jam: I have not followed 1.6 development, considering its delay I gather some people were invested in getting stacking out. | 21:40 |
| LarstiQ | it's a shitty situation you/we are in, that's for sure. | 21:41 |
| jam | LarstiQ: well it is mostly just some of the auto-detection stuff that is acting badly | 21:41 |
| jam | so I think if I just remove it, we can still have stacking | 21:42 |
| jam | the user just has to request it | 21:42 |
| jam | mwhudson: there is another possible fix | 21:44 |
| jam | only set the "default_stacked_on" value when the development focus is in a format that supports it | 21:45 |
| jam | mwhudson: what do you think about that? | 21:45 |
| jam | (with the other fix being to have .clone() upgrade the branch the way .sprout() does.) | 21:46 |
| jam | I'm not 100% happy with it, but I do feel some of this is LP's fault, and not bzr's. | 21:47 |
| jam | LP is getting a bit pro-active, when it may not really be best for the users. | 21:47 |
| jam | mwhudson: or it could be a project/user setting | 21:47 |
| === kiko is now known as kiko-afk | ||
| mwhudson | jam: certainly with hindsight we shouldn't have tried to get stacking-by-default working at the same time as just getting stacking working | 21:50 |
| mwhudson | jam: but in general, in the long term, i think it's a really good idea for bzr push <lp:url> to dtrt | 21:51 |
| mwhudson | jam: it's not like you want to be typing bzr push server:/path/repo/branch --use-repo server:/path/repo is it? | 21:51 |
| fullermd | Now, if only it were entirely clear what the rt is ;) | 21:51 |
| jam | mwhudson: well you could have it a project setting, etc | 21:51 |
| mwhudson | jam: yeah, i guess so | 21:51 |
| jam | mwhudson: or as I mentioned, just notice that the dev target is in a valid format | 21:52 |
| jam | thus it is valid for users' to get upgraded if they aren't yet | 21:52 |
| jam | as the *project* is using an upgraded format | 21:52 |
| mwhudson | wel... | 21:52 |
| mwhudson | that still sounds pretty icky to me | 21:52 |
| jam | mwhudson: no more icky than doing it to *all* projects | 21:53 |
| jam | mwhudson: Also, I'm not planning on propagating this to bzr.dev | 21:53 |
| jam | so you're still going to have a bunch of clients dying | 21:53 |
| jam | but I guess you can hold off on rolling out the feature in LP | 21:54 |
| jam | and you won't have to worry about a broken old client | 21:54 |
| jam | old *released* client | 21:54 |
| mwhudson | makes sense | 21:54 |
| mwhudson | i think we can be a bit less forgiving for people using out-of-date versions of bzr.dev | 21:55 |
| mwhudson | jam: btw, not sure if this is generally known, but the stacking policy will only be presented for a very few projects in the initial rollout | 21:59 |
| mwhudson | (launchpad and storm, basically) | 21:59 |
| jam | mwhudson: sounds like a whitelist to me :) | 21:59 |
| jam | Just not one that you expose to the user yet | 22:00 |
| jam | mwhudson: what is the bug # again? | 22:02 |
| jam | bug #259275 | 22:03 |
| ubottu | Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [High,Triaged] https://launchpad.net/bugs/259275 | 22:03 |
| jam | found it | 22:03 |
| lifeless | moin | 22:05 |
| jam | mwhudson, LarstiQ, beuno: Any chance you could look over the patch I just sent to the mailing list? | 22:05 |
| jam | lifeless: morning. I have a patch to review for 1.6 | 22:06 |
| jam | rc5 .. :( | 22:06 |
| lifeless | jam: ok | 22:06 |
| beuno | jam, sure. I'll look at it, however useful that may be | 22:06 |
| jam | the Subject is: Disable automatic stacking via Bzrdircontrol.conf | 22:06 |
| jam | beuno: well, since lifeless is awake now, it can wait | 22:06 |
| jam | lifeless: I'll be back in about 15 min, need to pick up my son | 22:07 |
| jam | basically, something needs to be fixed, and I went the conservative "disable the feature" route | 22:07 |
| * beuno lets leaves it to the experts | 22:07 | |
| lifeless | jam: I'm looking for it | 22:10 |
| lifeless | jam: have you chatted with abentley ? | 22:22 |
| jam | lifeless: he is on vacation along with martin and spiv | 22:34 |
| lifeless | jam: oh wow | 22:34 |
| lifeless | ENOTEAM | 22:34 |
| jam | yeah | 22:34 |
| lifeless | quick | 22:34 |
| jam | not the best time to be working on a big release :) | 22:34 |
| lifeless | lets do stuff | 22:34 |
| jam | :) | 22:34 |
| mlh | party! | 22:34 |
| jam | get btree in core, right? | 22:34 |
| lifeless | gc-as-default, nownownow | 22:34 |
| lifeless | actually, I'm just reviewing your changes | 22:35 |
| lifeless | You are aware I don't want to join the trees right? I just want to do a code drop | 22:35 |
| jam | lifeless: really? | 22:35 |
| jam | Why not join them? | 22:35 |
| lifeless | I plan to keep on changing and tweaking blooms etc | 22:35 |
| lifeless | and the format hook in stuff and so on is just ugly, it should not merge in , it should be refactored in core so its not needed | 22:36 |
| jam | beuno, mwhudson, jml: Anything else for 1.6rc5 I'd really like to not need a rc6 | 22:36 |
| lifeless | 0730 for jml | 22:36 |
| jam | well, nobody has said anything on the ML, but it seems that every day someone drops yet another thing | 22:37 |
| beuno | jam, I've been using it without any problems. Of course, I haven't done any weird contortions with it | 22:37 |
| jam | well, I'll put together 1.6rc5, and just not make it a final announced thing until more people have woken up | 22:38 |
| jam | this bugfix isn't quite as critical as the rc4 one | 22:39 |
| lifeless | jam: if you feel strongly we should do a merge, we can, but I wasn't thinking of this as something we'd incrementally merge from, I was thinking we'd instead be dropping in a new different format if we add blooms later | 22:46 |
| lifeless | (index format that is) | 22:46 |
| jam | lifeless: well, it is really only a couple of test cases, and then one or two files, I guess it doesn't really matter either way. | 22:48 |
| jam | I can always use 'add --file-ids-from' rather than doing a merge | 22:48 |
| lifeless | I can't find your mail | 22:48 |
| lifeless | ah yes, totally disconnected thread name :P | 22:48 |
| lifeless | rockstar: you wanted to chat, I don't think the text got past your fingers though | 23:02 |
| rockstar | lifeless, I was trying to get the cscvs tests to run. | 23:03 |
| lifeless | make check? :) | 23:04 |
| rockstar | lifeless, ah, was using test_all, and one of the tests was hanging. | 23:05 |
| lifeless | got an onboard rng? | 23:06 |
| lifeless | reprhasing - where was it hanging :) | 23:07 |
| rockstar | testInitProtocolBadHost | 23:08 |
| lifeless | rockstar: check your dns etc | 23:17 |
| rockstar | What would I check for? It works. | 23:18 |
| rockstar | Maybe I'm missing something specific? | 23:18 |
| LarstiQ | mwhudson: thumper seems to be awake | 23:18 |
| mwhudson | LarstiQ: eh? | 23:18 |
| lifeless | rockstar: look at what the test does | 23:19 |
| LarstiQ | mwhudson: hmm, I thought you wanted to consult with him or jml. | 23:20 |
| mwhudson | LarstiQ: i wanted them to see the conversation in here | 23:20 |
| LarstiQ | ah. | 23:20 |
| mwhudson | LarstiQ: but thumper told me (somewhere else) that he was reading backlog | 23:20 |
| LarstiQ | mwhudson: I should not try to meddle with other's afairs. | 23:20 |
| LarstiQ | and go to bed, really. | 23:21 |
| mwhudson | LarstiQ: no worries :) | 23:21 |
| thumper | night LarstiQ | 23:21 |
| mwhudson | g'night | 23:21 |
| LarstiQ | night thumper :) | 23:21 |
| LarstiQ | and mwhudson (and the rest) | 23:21 |
| === kiko-afk is now known as kiko | ||
| lifeless | vila: ping | 23:29 |
| lifeless | beuno: indeed it is | 23:29 |
| lifeless | beuno: I was muttering about 1.6.1 :) | 23:29 |
| beuno | lifeless, what is? I've been jumping from screen to local irssi, so I'm missing a lot of context :) | 23:31 |
| lifeless | beuno: 1.6 w/ loggerhead.conf | 23:31 |
| beuno | lifeless, ah, so you're proposing a 1.6.1 release with the start-loggerhead fixes in it? That seems like a good idea | 23:33 |
| lifeless | beuno: I'd like http://squid-cache.org/bzrview/ not to look like vomit :O) | 23:33 |
| lifeless | beuno: and yeah, the admins there, like admins everywhere, tend to prefer running releases | 23:34 |
| beuno | lifeless, agreed. I'll bump it up to the top of my list and fix that tomorrow. | 23:34 |
| lifeless | beuno: if you wanted to add the options for prefix and port to serve-branches, we'd be happy to switch to that too :) | 23:34 |
| beuno | lifeless, yeah, I'll actually do that too. I'll file a bug, and add a milestone so I don't forget stuff | 23:35 |
| lifeless | sweet | 23:35 |
| * beuno goes walk the dog before it explodes | 23:35 | |
| beuno | mwhudson, btw, I'd like to talk about our next release at some point. Is it going to be 1.7? (short cycle) 1.8? I haven't created it yet, and I keep forgetting to ask at time you're actually around | 23:36 |
| mwhudson | beuno: so my (vague) idea about this was that a bit before each bzr release (say around the beta) we decide if it's worth doing a loggerhead release | 23:37 |
| mwhudson | beuno: for 1.7, i'd be a bit surprised if we get enough done to be worth it | 23:38 |
| === TheMuso_ is now known as TheMuso | ||
| lifeless | mwhudson: release often | 23:39 |
| jam | beuno: how did the 'scripting' attempt go today? | 23:39 |
| jam | I don't see a doc patch yet :) | 23:39 |
| pickscrape | Poor beuno :) | 23:40 |
| jam | I just bring it up because I have an rc5 tarball, which may make it to an upload if jml and thumper don't have anything else to say to me | 23:41 |
| thumper | jam: I'd rather see 1.6 get out | 23:43 |
| jam | anyone know when jml might wake up? | 23:44 |
| beuno | mwhudson, ah, ok. So we just fix bugs until we decide on a release? | 23:44 |
| beuno | jam, no scripting today. Didn't get to 3/4 of the things I was planning to :( | 23:44 |
| mwhudson | beuno: yeah, i reckon so | 23:45 |
| beuno | mwhudson, fair enough | 23:45 |
| mwhudson | beuno: though as lifeless says, our threshold for 'worth it' should be pretty low | 23:45 |
| beuno | I'm off to a long and painful dinner then. bbl! | 23:45 |
| beuno | mwhudson, agreed. Let's try and not delay it for more than 2 months or so | 23:46 |
| lifeless | I'd do it monthly with bzr | 23:48 |
| lifeless | just because | 23:48 |
| lifeless | releases -> visibility, improvements etc | 23:48 |
| vila | lifeless: pong | 23:52 |
| jam | vila!!!! | 23:52 |
| vila | :D | 23:52 |
| lifeless | vila: when do you start? | 23:53 |
| vila | in 56 hours ? :-D | 23:53 |
| lifeless | LOL | 23:53 |
| vila | lifeless: august 22th at dawn, until then I'm still full, but what was your ping for ? | 23:56 |
| lifeless | curiousity :) | 23:56 |
| vila | ok :) | 23:56 |
| lifeless | man too much homepage wiki spam | 23:56 |
| vila | I'll go to bed then, see you soon... | 23:56 |
| lifeless | gnight! | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!