| spm | looking at bug 726584 and the corresponding RT. we have 2.3b5 on jubany atm. I can find a ppa from max for 2.3.0-1; but it's unclear to me which version matches up to revno? I'm guessing by the dates that we need 2.3.1 or possibly .2? | 01:14 |
|---|---|---|
| ubot5 | Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/726584 | 01:14 |
| spiv | spm: let me double check | 01:22 |
| spm | ta | 01:23 |
| spiv | spm: yes, 2.3.1 | 01:23 |
| spm | coolio, do we have a ppa of that already I can backport from? | 01:23 |
| spiv | spm: none that I can see. | 01:25 |
| spiv | (There's the daily builds from trunk PPA, but I think that's a bit riskier than we want to use) | 01:26 |
| spm | okidoki. I'll update the RT with a request for a PPA we can backport off. ta spiv | 01:32 |
| spiv | spm: Thanks! Glad to have progress :) | 01:32 |
| spm | heh, nothing quite like being down 1-2 folks in a team of 4. :-) | 01:32 |
| spiv | Yeah, I bet. | 01:33 |
| poolie | maxb, hi, could you update the ppas some time? | 01:39 |
| maxb | poolie: hi | 01:58 |
| maxb | yes, I promised to do that this evening and have so far failed, due to Rocket Bunnies :-) | 01:59 |
| maxb | I shall do it before I sleep | 01:59 |
| poolie | thanks mate :) | 02:04 |
| poolie | i sympathize about the bunnies | 02:04 |
| maxb | yikes, there have been 19 revisions in the debian packaging branch since the last PPA release | 02:07 |
| * maxb is confused | 02:26 | |
| maxb | How can I be getting conflicts in files when merging 2.3.1 into ppa/natty ?! | 02:27 |
| maxb | upstream files, that is, not debian/* | 02:27 |
| Peng | Cherrypicking, maybe? | 02:48 |
| AfC | Is there a way to force Bazaar back to the original behaviour of not attempting to use empty commit messages and just straight up cancelling a commit if it gets one? | 03:13 |
| === psynaptic is now known as psynaptic|away | ||
| lifeless | that changed? | 03:16 |
| AfC | lifeless: yeah. It's rather off-putting. Now, every time I go "oops, not ready to commit all that after all", quit editor without saving, and it asks you a stupid "do you really want to commit empty" question, to which I have to answer 'n'. | 03:21 |
| AfC | lifeless: it used to just say "no commit message specified, quitting" which, as far as I can tell, is how it's supposed to work :( | 03:21 |
| spiv | Was probably changed for https://bugs.launchpad.net/bzr/+bug/530265 | 03:50 |
| ubot5 | Ubuntu bug 530265 in Bazaar "Not modifying a suggested commit message commits anyway" [Medium,Fix released] | 03:50 |
| spiv | I don't think there's a setting to disable that prompt, but I guess it'd be possible to write a plugin to intercept ui_factory.get_boolean("Commit message was not edited, use anyway") and return a hard-coded answer. | 03:54 |
| lifeless | spiv: or handle empty messages specially | 03:56 |
| echo-area | Say I want to revert an old change in the trunk, I can do this: (in trunk) bzr merge -r old-rev2..old-rev1 && bzr ci -m "Undo an old change". Say there are many changes committed after this reversion. Later on, I want to bring that undone change back, I can do this: (still in trunk) bzr merge -r old-rev1..old-rev2 && bzr ci -m "Bring that old change back". I tried and this worked. But is this the canonical/recommended way? | 07:02 |
| poolie | yes | 07:04 |
| poolie | hi jam | 07:04 |
| echo-area | poolie: Thanks | 07:04 |
| vila | hi all ! | 07:40 |
| jam | hi po | 08:23 |
| jam | hi poolie | 08:23 |
| jam | and vila, too! | 08:26 |
| vila | _o/ | 08:26 |
| maxb | Does bzr actually use per-file DAGs to assist merging? | 08:29 |
| maxb | I'm getting all sorts of spurious conflicts in criss-cross situations, even though the specific files conflicting didn't criss-cross | 08:30 |
| maxb | e.g. the current merge of loggerhead trunk into daily-ppa | 08:30 |
| maxb | and in fact, 4 files which didn't conflict drastically failed to have their changes merged correctly | 08:35 |
| vila | maxb: not as well as it should, jam knows the best about this specific point | 08:35 |
| jam | maxb: merge --weave does | 08:36 |
| jam | (does what you want) | 08:36 |
| jam | maxb: thats the main problem with re-landing code :) | 08:36 |
| jam | but I'm trying to at least make sure that I do the work of merging into experimental | 08:36 |
| jam | I didn't realize the ppa branch would have that problem, too | 08:37 |
| maxb | --weave ... did not do what I wanted :-( | 08:37 |
| maxb | At least for the daily-ppa branch I can just revert all the non-debian bits to the pending merge tip and be done with it | 08:37 |
| jam | maxb: can you point me to the branches you are merging? I can give it a look over | 08:42 |
| jam | maxb: I would guess the daily ppa would have tried to build the old trunk tip | 08:42 |
| jam | which has been removed from history | 08:42 |
| jam | which is going to confuse the hell out of everything | 08:42 |
| maxb | Most recently I was trying to merge lp:loggerhead into lp:~bzr/loggerhead/daily-ppa | 08:45 |
| jam | maxb: right, and you actually need to revert all of the 'experimental' branch back out of the daily-ppa, since it used to be in lp:loggerhead | 08:45 |
| jam | maxb: so probably the best thing is as you said | 08:45 |
| maxb | But that had already been done in the past | 08:46 |
| jam | maxb: but not in the trunk branch, so things get really weird in history | 08:46 |
| maxb | evidently :-) | 08:46 |
| jam | daily-ppa basically has a change for almost every file that supersedes what is in trunk | 08:46 |
| jam | what was in trunk | 08:47 |
| jam | but then trunk updates == conflicts | 08:47 |
| maxb | ugh | 08:47 |
| maxb | bzr really ought to understand "I merged foo and reverted to its version" as "I'm happy to accept foo's changes in future" | 08:47 |
| jam | maxb: if we had reverted trunks contents using "bzr revert -r OLD; bzr commit", and then rebuilt experimental from there | 08:47 |
| jam | it would work better for you | 08:47 |
| maxb | right, I'd better get myself to work now. I'll re-stare at trees | 08:48 |
| maxb | later | 08:48 |
| jam | vila, mgz: ping about tarfile exports. "tarfile.extractfile()" seems to hang indefinitely if you give it corrupt data. Which does exercise the test, but means it has a really bad failure mode | 09:01 |
| vila | weird, what is hanging ? | 09:02 |
| jam | f = tarfile.extractfile('path'); f.read() the .read() is hanging | 09:02 |
| vila | O_o | 09:03 |
| jam | I'll try to trace into it to give better detail | 09:04 |
| vila | is there a pipe there ? | 09:04 |
| jam | vila: nope, it is reading from disk | 09:04 |
| vila | O_O | 09:04 |
| poolie | hi jam, vila | 09:05 |
| vila | _o/ | 09:06 |
| jam | vila: ah, maybe it is "assertEqualDiff being unhappy trying to match 800 lines of gobbledy-gook | 09:08 |
| jam | vila: yeah, stopping the hang shows it in difflib | 09:08 |
| jam | so better and worse :) | 09:08 |
| vila | 800 lines ? That's a lot... | 09:10 |
| jam | yeah, swapping out assertEqualDiff made it happier | 09:10 |
| jam | _file_content = ('!\r\n\t\n \r' | 09:10 |
| jam | + '\n'.join([osutils.rand_chars(80) for i in range(800)]) | 09:10 |
| jam | + '\n') | 09:10 |
| jam | doesn't seem very big to mee | 09:10 |
| poolie | wow, that's a bit bad it would hang | 09:10 |
| jam | me | 09:10 |
| vila | hmm, please don't use rand_chars in tests, it is *guaranteed* to fail one day or another | 09:10 |
| jam | poolie: it might just go O(N^2) and die, or it might have a real bug in the diff code. | 09:10 |
| jam | vila: it is meant to | 09:10 |
| jam | how do you expect it to fail? | 09:11 |
| jam | (I need a way to force '\r' and '\n' in the compressed streams) | 09:11 |
| jam | which has all sorts of "tar header", etc. | 09:11 |
| jam | I can hand-craft something today | 09:11 |
| vila | because you will encounter a combination that while unlikely will break the test ? | 09:11 |
| jam | or I can throw enough random data at it, that I'm sure it has at least one char | 09:11 |
| jam | vila: this is file content itself | 09:11 |
| jam | if we are not managing to preserve exact fidelity | 09:12 |
| vila | yeah, hand crafting is better, it's stable ;) | 09:12 |
| jam | we have a problem | 09:12 |
| jam | vila: except there are timestamps, and mtimes that will vary | 09:12 |
| jam | which means that the real data may change its compressed form | 09:12 |
| vila | still deterministic | 09:12 |
| jam | vila: deterministic in the sense that time.time() is always changing? | 09:12 |
| vila | yes, in predictable ways (except on vbox slaves but I digress ;) | 09:13 |
| vila | so modulo restting the system clock, you can run the same twice and get the same result | 09:14 |
| vila | introducing randomness is the opposite of test isolation :) | 09:14 |
| jam | vila: still isolated tests | 09:14 |
| jam | each test does not depend on the other | 09:14 |
| jam | I can run 'osutils.rand_chars()' manually and hard-code it in the file, but that just bloats the test file (IMO) | 09:15 |
| vila | and give us data to analyze if the test ever fails whereas rand_chars won't | 09:15 |
| vila | and of course you're supposed to provide a sample that is not 80*800 chars long... | 09:16 |
| vila | or said otherwise: if the test fails with 80*800 random chars, how would you debug it ? | 09:19 |
| poolie | do we have any tests using rand_chars? | 09:19 |
| vila | hmm, not much but grep rand_chars in bzrlib/tests find 15 matches (not all of them are relevant though) | 09:22 |
| vila | ./test_lockdir.py:394: lf1.nonce = osutils.rand_chars(20) seems valid for example | 09:22 |
| poolie | mm | 09:23 |
| vila | well, almost, there should probably be an assertion that we don't collide | 09:23 |
| jam | poolie: indirectly almost all of them via 'gen_file_id()" | 09:23 |
| poolie | we should probably make them deterministic | 09:23 |
| poolie | right | 09:23 |
| maxb | 2.3.1 is up in ~bzr/proposed - testers appreciated | 09:30 |
| poolie | thanks maxb | 09:34 |
| poolie | i'll install it | 09:34 |
| === hunger_ is now known as hunger | ||
| poolie | jelmer, can you help me think of some other options? | 09:46 |
| jam | vila: I used hard-coded data. Now the test fails intermittently | 09:53 |
| jam | (explicitly not fixing the bug so that I know I should have a failing test.) | 09:53 |
| jam | it was failing reliably with 64k data | 09:53 |
| jam | it seems the timestamps are having a pretty strong effect on the compressed steram | 09:53 |
| jam | stream | 09:53 |
| vila | jam: then your data are not good enough ? Or you should isolate the test from the timestamps | 09:54 |
| jam | vila: I can make it 64k data and be done with it | 09:54 |
| jam | (which I had) | 09:54 |
| jam | poolie: other options for? (and shouldn't you be sleeping by now?) | 09:55 |
| vila | jam: huh ? You said bloating the test wasn't good no ? | 09:56 |
| jam | vila: osutils.rand_chars(65536) isn't many characters in the file | 09:57 |
| vila | <vila> or said otherwise: if the test fails with 80*800 random chars, how would you debug it ? | 09:57 |
| jam | [osutils.rand_chars(80) + '\n' for i in xrange(800)] isn't much bigger | 09:57 |
| vila | s/80*800/65536/ | 09:57 |
| vila | jam: how will you debug it if it fails ? | 09:58 |
| jam | vila: if we are corrupting the data stream, it doesn't matter what the content is, IMO | 09:58 |
| jam | vila: start looking for missing binary streams | 09:58 |
| jam | if it is 100 random chars, does that help debugging? | 09:58 |
| jam | same problem | 09:58 |
| vila | yes the problem is the random part | 09:58 |
| jam | to trigger it, needs enough random data, that you can't eyeball the corruption | 09:58 |
| jam | vila: note that we also want to trigger it for raw tar, .tgz and .tbz2, and .tar.xz | 09:59 |
| jam | and .tar.lzma | 09:59 |
| vila | if the test is random it's not a reliable reproducing recipe, do we agree on that ? | 10:00 |
| jam | vila: no | 10:01 |
| vila | as I mentioned earlier, if the bug is too hard to reliably reproduce, I don't care about having a test for it as long as the diagnosis is 100%: we must use 'wb' and be done with it | 10:01 |
| jam | vila: if the chance of failing is 1 in 2^256 | 10:01 |
| jam | I'm fine with that | 10:01 |
| vila | but you're pulling this number out of thin air right ? | 10:01 |
| jam | 65k bytes, compresses down to about 40kb. If you then have 1-in-256 chance per byte to be a '\r' or '\n', then your total chances are (let me grab a calc) | 10:02 |
| vila | since you can only prove it to be right by establishing which inputs are valid/invalid | 10:02 |
| jam | vila: given 10k compressed characters, the odds it not having what we want is 10^-17 | 10:03 |
| jam | vila: what bounds would you be happy with? | 10:03 |
| vila | 0 | 10:03 |
| jam | vila: note, zlib changes the compressed stream from source from time to time | 10:03 |
| jam | it is allowed to | 10:03 |
| jam | for the same compression settings | 10:03 |
| jam | as long as the actual decompressed content is the same | 10:03 |
| jam | vila: I can't give you 0 | 10:04 |
| jam | I can give you epsilon | 10:04 |
| vila | that's my point | 10:04 |
| jam | vila: it means we can't force the compressed stream, but we can be really darn certain | 10:04 |
| vila | the options are: | 10:06 |
| vila | 1) no test | 10:06 |
| vila | 2) test with a hard-coded reduced length | 10:06 |
| vila | 3) test with random data | 10:06 |
| vila | (3) is the worse because, a) it can't be debugged if it fails b) it will fail | 10:07 |
| jam | vila: I disagree on (b) | 10:07 |
| jam | if we are failing because of the content of files | 10:08 |
| jam | then we have *serious* problems internally | 10:08 |
| vila | do you have a fix for the bug ? | 10:08 |
| jam | vila: certainly, but I would like to make sure we are testing all of them. Since mgz was kind enough to notice we had the same bug in other exporters | 10:10 |
| vila | jam: can you seed rand_chars and guarantee you will get the same chars ? | 10:12 |
| vila | jam: can you still haven't answer: "How would you debug it ?" | 10:12 |
| jam | vila: with 800 random characters I had 2 accidental successes in 30 runs | 10:12 |
| jam | vila: looking at the stream isn't a way to debug it, regardless. | 10:13 |
| jam | unless you know a way to debug a gzip stream | 10:13 |
| vila | Is that a way to say it can't be debugged ? | 10:13 |
| jam | especially a gzip(tar) stream | 10:13 |
| jam | vila: it can be "oh it isn't getting the data back properly, I must have missed something" | 10:13 |
| jam | but analyzing the data stream probably isn't the way to debug it | 10:14 |
| vila | then how about forgetting about the compressed stream and ensures we never corrupt it instead ? | 10:15 |
| jam | vila: we are corrupting the compressed stream | 10:16 |
| jam | how do we forget about it? | 10:16 |
| jam | 'bzr export -' is writing the stream to stdout, and we weren't setting the binary flag | 10:16 |
| vila | by using a mock compressor ? | 10:16 |
| jam | 'bzr export foo.tar.gz' was opening the output file without the binary flag | 10:17 |
| jam | vila: the bug was both in the command | 10:17 |
| jam | and in the individual code ptahs | 10:17 |
| jam | paths | 10:17 |
| vila | right | 10:17 |
| vila | and the issue is that it was corrupted because somewhere 'w' was used instead of 'wb' | 10:17 |
| jam | vila: if it was just the 'export -' we could put '\r\n' in the file content and 'plain_tar_export' it. | 10:18 |
| jam | vila: right | 10:18 |
| jam | plus the fact that GzipFile(mode='w') automatically sets 'wb' | 10:18 |
| jam | so we had 'w' before | 10:18 |
| jam | but we switched to GzipFile(open('w')) | 10:18 |
| jam | and ooops, it broke | 10:18 |
| vila | if you can't reliably inject a stream that would be corrupted because you don't control how it's transformed, I'm saying: control it | 10:18 |
| jam | vila: GzipFile is going to be python-version dependent, and possibly platform dependent | 10:19 |
| vila | indeed | 10:19 |
| jam | how do you want to control it, since we want to be testing the specific code path | 10:19 |
| jam | BzipFile happened to be ok, plain_tar_export was bad, GzipFile was bad | 10:19 |
| jam | ZipFile I think was ok | 10:19 |
| jam | I'd like to make sure that transforming the code paths in ways that look fine, still are actually fine | 10:20 |
| vila | 'make sure' != 1e10-17 | 10:20 |
| jam | vila: osutils.rand_chars(65536) | 10:20 |
| jam | 10^-17 is sure for me | 10:20 |
| jam | if you prefer, I can make it | 10:20 |
| jam | 10^-999 | 10:20 |
| vila | yeah, some japanese may disagree :-/ | 10:21 |
| jam | vila: /me => lunch, bbiab | 10:22 |
| poolie | i've been feeling sad about that | 10:23 |
| jam | poolie: ? | 10:24 |
| jam | I didn't mean to go to lunch and make you sad :) | 10:24 |
| poolie | :) the Japanese disasters | 10:25 |
| poolie | hello inada-n, i hope you're doing ok | 10:32 |
| inada-n | hello, poolie. | 10:34 |
| inada-n | About earthquake? | 10:34 |
| poolie | yes | 10:34 |
| inada-n | I'm OK in Tokyo. | 10:34 |
| poolie | good | 10:35 |
| vila | good | 10:35 |
| inada-n | Thanks, a lot. | 10:35 |
| === psynaptic|away is now known as psynaptic | ||
| === Tak|Work is now known as Tak | ||
| === deryck is now known as deryck[lunch] | ||
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.3.1 is officially out, 2.4b1 has been frozen | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| jml | goaeruaeos | 17:12 |
| jml | I have to figure this out every six months | 17:12 |
| === beuno is now known as beuno-lunch | ||
| jml | how to get a list of landings I've done on launchpad | 17:12 |
| vila | jml: some filtering from qlog maybe ? | 17:14 |
| jml | vila: ahh, never mind. I apparently wrote a little plugin called pqmstats that does what I want | 17:15 |
| vila | hehe :) | 17:15 |
| vila | jml: don't tell me, you went: "Let's write a plugin to do X and let's call it pqmstats, oh wait, here is one !" :-D | 17:16 |
| jml | vila: yeah, exactly like that | 17:18 |
| vila | good, I'm not suffering from Alzheimer then ;D | 17:19 |
| jelmer | hehe | 17:19 |
| vila | jelmer: I think you miss my msg yesterday about lp:~vila/ubuntu/lucid/bzr/sru-2.1.3 | 17:20 |
| jelmer | vila: I think I might - what was it? | 17:20 |
| vila | jelmer: can you have a look at it (no urgency), there is a dirty trick in debian/watch but I filed bug #736145 about it | 17:21 |
| ubot5 | Launchpad bug 736145 in Launchpad itself "no series specific download pages" [Low,Triaged] https://launchpad.net/bugs/736145 | 17:21 |
| vila | jelmer: 2.1.4 will be released soon so it's just a warm-up to see if I get it right | 17:22 |
| jelmer | vila: what about https://launchpad.net/bzr/2.3 ? | 17:23 |
| ubot5 | Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2) | 17:23 |
| jelmer | vila: it's only got the latest release, but that should be sufficient in our case | 17:23 |
| vila | EPARSE, what about 2.3 ? | 17:23 |
| vila | and what is your last remark about ? 2.1 or 2.3 ? | 17:24 |
| jelmer | vila: there is https://launchpad.net/bzr/2.1 as well | 17:25 |
| ubot5 | Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2) | 17:25 |
| jelmer | vila: So in the watch file we can just use the series-specific page, which will always contain the latest release in that series. For debian/watch that's sufficient | 17:25 |
| vila | haaa, for watch file! | 17:26 |
| jelmer | vila: well, that /is/ what you were asking about.. :) | 17:26 |
| vila | jelmer: but these pages doesn't mention the tar.gz | 17:26 |
| vila | jelmer: but these pages don't mention the tar.gz | 17:26 |
| jelmer | vila: they do | 17:26 |
| jelmer | just check https://launchpad.net/bzr/2.1 or https://launchpad.net/bzr/2.3 | 17:26 |
| ubot5 | Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2) | 17:26 |
| ubot5 | Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2) | 17:26 |
| jelmer | there's a link on the right hand side | 17:26 |
| vila | ooooooh ! | 17:26 |
| vila | right, so for old stable series and as long as we are fast enough to keep track, yeah, far better than my dirty trick | 17:27 |
| vila | jelmer: otherwise, is this branch a good base for 2.1.4 ? AIUI the first line in changelog should mention lucid instead of UNRELEASED but the rest should be ok ? | 17:33 |
| vila | jelmer: or will 2.1.4 require a roundtrip via debian (squeeze provides 2.1.2) ? | 17:35 |
| jelmer | vila: the version should be 2.3.1-0ubuntu1 | 17:35 |
| vila | 2.1.3-0ubuntu1 you mean ? | 17:36 |
| jelmer | vila: (your version is not intended to be uploaded to Debian but to Ubuntu, in case of debian it would be 2.3.1-1) | 17:36 |
| jelmer | vila: sorry, yes | 17:36 |
| vila | ok | 17:36 |
| vila | 0 because 2.1.3-1 will come from debian and override it ? | 17:37 |
| jelmer | yes, exactly | 17:37 |
| jelmer | vila: it looks good to me otherwise | 17:38 |
| vila | ok, thanks ! | 17:38 |
| jelmer | vila: one minor nitpick - maybe this is loggerhead's formatting - there should be one extra level of indentation for the + signs under "New upstream release" | 17:40 |
| vila | oh, not loggerhead | 17:40 |
| vila | the '+' should below the 'N'ew ? | 17:41 |
| jelmer | it should have one more space than the * | 17:41 |
| jelmer | so it should be below the space in the previous line | 17:41 |
| vila | ha no | 17:41 |
| vila | sry, was looking at wrong file | 17:41 |
| vila | yeah, below the sapce | 17:42 |
| vila | space | 17:42 |
| g0nzal0 | hello #bzr | 17:44 |
| vila | hello g0nzal0 | 17:45 |
| g0nzal0 | I'm using bzr 2.2.1 with the svn plugin (version 1.0.4) | 17:46 |
| g0nzal0 | I'm trying to branch an svn repository, but said repository has a commit of a file named \ | 17:46 |
| philsf | I forgot to add a part of a message to a commit. is there a simple way to edit a log? This is a simple versioned directory, not a remote branch, fwiw | 17:47 |
| vila | philsf: uncommit/commit if it's the last commit you did | 17:47 |
| g0nzal0 | the svn plugin conveniently checks for this and raises an exception | 17:47 |
| g0nzal0 | is there a way around that? I can't get a full copy of that svn repo with bzr otherwise :( | 17:48 |
| === psynaptic is now known as psynaptic|break | ||
| maxb | g0nzal0: Actually, I think the forbidding of backslashes in pathnames is done in the core of Bazaar | 17:49 |
| maxb | this means there's no way you can have such a file in a Bazaar branch, that you can work with using an unmodified copy of Bazaar | 17:50 |
| g0nzal0 | maxb, yes it is (tried commenting out the check on the svn plugin and got an exception from bzr) | 17:51 |
| g0nzal0 | magcius, the file is removed in the svn repo in a later commit | 17:51 |
| g0nzal0 | *removed from | 17:52 |
| g0nzal0 | I mean, maxb | 17:52 |
| maxb | I'm not sure that will help you | 17:52 |
| g0nzal0 | it doesn't, bzr branch stops when it hits the commit that adds that backslash-named file :( | 17:53 |
| jelmer | g0nzal0: the best way to work around it is to "svnadmin dump" the repository, eliminate the backslash and reload it | 17:54 |
| g0nzal0 | jelmer, ah, I don't think I have permissions to do that, but I can talk to the sysadmin and try that, thanks! | 17:55 |
| === fjlacoste is now known as flacoste | ||
| jelmer | g0nzal0: there is a bug report in bzr about this, but it hasn't seen much activity recently | 17:56 |
| * jelmer will be back later | 17:56 | |
| === beuno-lunch is now known as beuno | ||
| === psynaptic|break is now known as psynaptic | ||
| cr3 | hi folks, someone seems to have merged changes in from a branch and merged into trunk. now, the revno in the trunk is 30 numbers smaller than before, what might've happened? | 18:28 |
| beuno | cr3, they merged trunk into a branch and pushed that up to trunk | 18:30 |
| cr3 | beuno: that resulted in lots of commits being conflated into one, might there be a way to revert that or do something reasonable about it? | 18:31 |
| beuno | I guess someone could push --overwrite | 18:31 |
| beuno | if they have trunk | 18:31 |
| cr3 | beuno: yeah, "if they have trunk" is the problem, I just pulled from trunk so mine is reverted now :( | 18:32 |
| beuno | hm | 18:32 |
| beuno | not sure how to revert that easily | 18:33 |
| cr3 | beuno: I'm about to take the last snapshot I had, reproduce the commits that were done previously and then try to push that. I expect that to be a lot of work, so looking for the quick fix | 18:33 |
| cr3 | beuno: would the person that merged trunk into the other branch and pushed had to use --overwrite as well? ie, would bzr have provided somekind of warning to prevent this and required explicit action on the part of the user to proceed? | 18:34 |
| beuno | cr3, no, no --overwrite | 18:39 |
| beuno | you can, however, set a flag that won't allow this to happen again | 18:39 |
| beuno | append_only or something | 18:39 |
| beuno | I forget where to set it | 18:39 |
| cr3 | beuno: sounds like a good lead, thanks so much! | 18:41 |
| philsf | vila: it was not the last commit. Can I uncommit/commit and still preserve the original revision number? | 18:47 |
| cr3 | beuno: I found that I can add this line to .bzr/branch/branch.conf: append_revisions_only = True. however, not sure how I can commit that so it applies to everyone branching the project | 18:53 |
| beuno | cr3, that's a good question | 18:54 |
| beuno | maybe lifeless knows | 18:54 |
| * jelmer waves | 18:55 | |
| beuno | heya jelmer | 18:56 |
| maxb | cr3: "commit" it? It applies to a particular copy of a branch, not a project. | 18:56 |
| maxb | Usually you would set it on the branches on a server that people share | 18:57 |
| maxb | Bazaar might copy it to new branches 'bzr branch'-ed from that - I'm not sure, you'd have to test. | 18:57 |
| maxb | cr3: Before you try to regenerate any commits manually: You really do not need to. No data has been lost. Bazaar has just been instructed to understand it differently? | 18:58 |
| cr3 | maxb: I just tried locally: 1. created file .bzr/branch/branch.conf with append_revisions_only = True; 2. branched project to other directory; 3. looked at .bzr/branch/branch.conf in other directory: branch.conf does not get branched | 18:58 |
| maxb | cr3: Is this project public? It would be easier to explain with specific examples. If not, I can explain more generically | 18:58 |
| cr3 | maxb: I managed to regenerate the data already and the diff (not bzr diff, just /usr/bin/diff) of my new branch and the one on the server seem the same now | 18:59 |
| maxb | cr3: However I would still advise you *NOT* to push --overwrite that | 18:59 |
| cr3 | maxb: the project is public and, if you happen to have a moment, I wouldn't mind understanding how to resolve this kind of situation | 19:00 |
| maxb | We can fix your revnos without forcing everyone else to "pull --overwrite" and potentially have to replay their own local commits | 19:00 |
| cr3 | maxb: really? why not? | 19:00 |
| maxb | I don't understand the "why not?" question | 19:00 |
| cr3 | maxb: good point. although there are probably not that many people branching the project, I try to do things right when possible | 19:00 |
| maxb | Ok - give me the URL for the branch concerned, and I'll have a look | 19:01 |
| cr3 | maxb: I meant "why not push --overwrite", but you answered before I hit enter :) | 19:01 |
| cr3 | maxb: lp:checkbox | 19:01 |
| maxb | fetching..... meanwhile, have you used "bzr qlog" previously? | 19:01 |
| maxb | I find it an awesome tool for understanding revision graphs | 19:02 |
| cr3 | maxb: the problematic revision is 864 and no, haven't used qlog before | 19:02 |
| maxb | yikes, that revision merged an awful lot of trunk changes, didn't it :-) | 19:02 |
| cr3 | maxb: totally :) | 19:02 |
| cr3 | maxb: about 30 revisions worth :) | 19:02 |
| cr3 | well, 30 revisions based on difference of current revision in trunk and what it should be | 19:03 |
| maxb | OK, so here's how we go about restoring the "left hand" or "first parent" ancestry that determines revnos | 19:03 |
| maxb | First you branch lp:checkbox at 863 | 19:03 |
| maxb | oh, sorry | 19:04 |
| maxb | I don't mean 863, 1 sec | 19:04 |
| maxb | hmm. We need to find the revision which was the tip of lp:checkbox which was before that erroneous merge was pushed | 19:05 |
| maxb | Ah, OK, so I think that was the current 862 "Merged from testsprint-checkbox-base-sru-changes." | 19:07 |
| maxb | Right, let me start again, and get the numbers right this time | 19:07 |
| cr3 | maxb: I'll follow what you say in qlog | 19:08 |
| mgz | vila: that was my impression with rand_chars as well, but jam is right. provided that the (teeny) chance of the randomness working against us results in a spurious pass rather than a spurious failure, it's the best way to write that kind of test. | 19:08 |
| maxb | So, we branch from lp:checkbox 862, because that is the last revision that is part of the old mainline, which is still on the mainline. | 19:08 |
| cr3 | maxb: why not 863? | 19:09 |
| maxb | Having looked at the history, it looks to me like the "bad" merge was an attempt to land the revision which is currently 863 on trunk | 19:10 |
| maxb | More importantly, 863 is diverged from the long string of revisions which we want to put back on the mainline | 19:11 |
| cr3 | maxb: exactly, now I understand where you're getting at | 19:11 |
| maxb | OK, so having done that, for the sake of illustration, you might choose to turn on append_revisions_only = True in the local branch | 19:11 |
| maxb | then we're going to pull, not merge, r862.2.31 of lp:checkbox | 19:12 |
| maxb | (and yes, we could just have branched that directly - this was either my mistake or a fortuitous illustration of exploring the history) | 19:13 |
| maxb | :-) | 19:13 |
| === psynaptic is now known as psynaptic|break | ||
| maxb | After that, we *merge* the formerly "bad" merge commit - i.e. we 'bzr merge -r 864 lp:checkbox' | 19:14 |
| cr3 | maxb: I'm doing bzr branch -r862 lp:checkbox then bzr pull -r862.2.31 lp:checkbox, right? I'm waiting for the first branch to finish, this is taking a while unfortunately | 19:14 |
| cr3 | aha, after that pull, I get: Now on revision 893. | 19:14 |
| cr3 | which is sounding very sane! | 19:14 |
| maxb | And commit that with a message of something like "Land translation work by Mahyuddin Susanto via Michael Terry." | 19:15 |
| cr3 | maxb: you didn't forget 863, right? | 19:15 |
| maxb | No, this is intentional - the one merge is going to pull in 863 & 864 | 19:15 |
| cr3 | of course, my bad :) | 19:16 |
| maxb | Once you've done this commit, you are back in the rough "shape" of the tree that you wanted to have kept all along | 19:16 |
| cr3 | maxb: this is amasing, really! | 19:17 |
| maxb | The remaining thing is to merge (one by one if you want to preserve their mainline revnos in full) the remaining commits. Fortunately in this case there is only one. | 19:17 |
| cr3 | maxb: Thanks so much for taking the time to explain this to me, I'm keeping this irc log and framing it somewhere :) | 19:17 |
| maxb | So, "bzr merge -r 865 lp:checkbox" (or for that matter just "bzr merge lp:checkbox") | 19:17 |
| maxb | And commit | 19:17 |
| maxb | and we're in our final desired state. Only thing remaining is to then push back to lp:checkbox - *without* --overwrite | 19:18 |
| cr3 | makes perfect sense | 19:18 |
| cr3 | excellent, so my contributors will not need to pull --overwrite themselves. win! | 19:18 |
| maxb | To prevent it happening again, you can enable append_revisions_only on the Launchpad copy of the branch | 19:19 |
| cr3 | maxb: how can I ssh/scp/ftp there again? | 19:20 |
| cr3 | I once accessed the server to rm branches but that was a very long time ago | 19:20 |
| maxb | If your local bzr is new enough, you can just run "bzr config -d lp:checkbox append_revisions_only=True" | 19:21 |
| maxb | um | 19:22 |
| maxb | wait a moment, I think that may not work | 19:22 |
| maxb | bzr config -d bzr+ssh://bazaar.launchpad.net/+branch/checkbox append_revisions_only=True | 19:23 |
| maxb | owing to a bug in current bazaar, you need to not use the lp: shortcut here | 19:23 |
| === psynaptic|break is now known as psynaptic | ||
| === Ursinha-lunch is now known as Ursinha | ||
| philsf | I forgot to add a part of a message to a commit. is there a simple way to edit a log? This is a simple versioned directory, not a remote branch, fwiw. it was not the last commit. Can I uncommit/commit and still preserve the original revision number? | 21:42 |
| === psynaptic is now known as psynaptic|away | ||
| === BasicPRO is now known as BasicOSX | ||
| === psynaptic|away is now known as psynaptic | ||
| === psynaptic is now known as psynaptic|away | ||
| * jelmer waves to spiv | 23:22 | |
| poolie | hi all | 23:26 |
| jelmer | poolie: g'day | 23:27 |
| poolie | hi jelmer | 23:27 |
| poolie | jam, still around? | 23:28 |
| * spiv waves back | 23:31 | |
| jelmer | spiv: Why do we never store directory service URLs but always resolved URLs? Is it since the way a directory service resolves a URL might differ per user? | 23:33 |
| spiv | jelmer: I think it's just by accident, rather than design | 23:34 |
| spiv | I'm pretty sure there's a bug or two about how we should store unresolved directory service locations. | 23:34 |
| jelmer | spiv: I was looking at one of the bugs that the linaro folks were hitting, where we are calling urlutils.normalize_url() on a URL that can contain e.g. "lp:bzr" | 23:35 |
| spiv | There is a bit of an issue that directory services might resolve differently, or even be not present at all, for different users. | 23:35 |
| spiv | So I guess if we start storing them we should take care to handle that gracefully | 23:36 |
| spiv | I wouldn't want my bzr to crash with a traceback just because someone else's branch I access has a parent_location with a custom directory service URL. | 23:36 |
| jelmer | right, that makes sense | 23:37 |
| jelmer | spiv: so I guess then a related issue is: is "lp:bzr" something that urlutils should handle gracefully? | 23:38 |
| spiv | Hmm | 23:38 |
| spiv | We're really mixing different types of variable | 23:38 |
| jelmer | On the one hand it would be a nice solution here, but I'm worried about misinterpreting what could be a proper URL with an entirely different meaning | 23:38 |
| jelmer | yeah | 23:38 |
| spiv | "URL" and "location" might be good names for those types, if we had statically typed variables. | 23:39 |
| spiv | Or "URL" and "BRL" ;) | 23:39 |
| spiv | So in my ideal world, we'd never all normalize_url on something that isn't a proper URL | 23:40 |
| jelmer | your ideal world has URLs ? :-P | 23:40 |
| spiv | But we sometimes use them interchangeably, although sometimes not (the CLI isn't consistent about what it accepts) | 23:41 |
| spiv | s/all/call | 23:41 |
| spiv | To be pedantic, strictly speaking I didn't imply my ideal world would have to have URLs ;) | 23:43 |
| poolie | <spiv> jelmer: I think it's just by accident, rather than design <-- i agree | 23:44 |
| spiv | Anyway, given we mix URLs and not-quite-URLs quite a bit now, we have two options that I can see: | 23:45 |
| spiv | 1) make functions like normalize_url that expect URLs also cope with not-quite-URLs | 23:46 |
| spiv | 2) try to be stricter about not using not-quite-URLs interchangeably with URLs | 23:47 |
| spiv | Maybe there are other options. | 23:47 |
| poolie | i think 'lp:' is a proper url | 23:47 |
| poolie | or 'should be treated the same' | 23:47 |
| spiv | Or another way to look at it perhaps is: why is linaro calling normalize_url? Is it because they really want "normalize_location" and that's the closest we have? | 23:49 |
| jelmer | spiv: This is the stacked-on argument to cmd_push() | 23:49 |
| spiv | Ah, right. | 23:49 |
| spiv | So, essentially, yes :) | 23:50 |
| jelmer | spiv: yes, indeed | 23:50 |
| spiv | I don't feel strongly about which route we should take, but I do feel strongly that the current situation is a problem :) | 23:50 |
| jelmer | :) | 23:50 |
| jelmer | I think in the short term it would probably make sense to do the directory lookup in cmd_push for --stacked-on, as it's consistent with how we treat directory URLs in other places. | 23:51 |
| lifeless | there is a bug on directory lookups in push :parent as well IIRC | 23:52 |
| lifeless | so you'dfix more than one bug :> | 23:52 |
| lifeless | sorry, I mean, while you're there consider doing more ;) | 23:52 |
| spiv | I was about to say, I'm not sure that's the same bug (although I'm sure it's related) | 23:53 |
| jelmer | is :parent a directory as well? It seems odd that it breaks in that case, as "bzr push lp:foo" works | 23:55 |
| lifeless | jelmer: it needs to double dereference | 23:58 |
| lifeless | jelmer: when :parent returns lp:foo it breaks | 23:59 |
| jelmer | lifeless: ahh | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!