[01:14] <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:22] <spiv> spm: let me double check
[01:23] <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:25] <spiv> spm: none that I can see.
[01:26] <spiv> (There's the daily builds from trunk PPA, but I think that's a bit riskier than we want to use)
[01:32] <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:33] <spiv> Yeah, I bet.
[01:39] <poolie> maxb, hi, could you update the ppas some time?
[01:58] <maxb> poolie: hi
[01:59] <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
[02:04] <poolie> thanks mate :)
[02:04] <poolie> i sympathize about the bunnies
[02:07] <maxb> yikes, there have been 19 revisions in the debian packaging branch since the last PPA release
[02:26]  * maxb is confused
[02:27] <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:48] <Peng> Cherrypicking, maybe?
[03:13] <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:16] <lifeless> that changed?
[03:21] <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:50] <spiv> Was probably changed for https://bugs.launchpad.net/bzr/+bug/530265
[03:54] <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:56] <lifeless> spiv: or handle empty messages specially
[07:02] <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:04] <poolie> yes
[07:04] <poolie> hi jam
[07:04] <echo-area> poolie: Thanks
[07:40] <vila> hi all !
[08:23] <jam> hi po
[08:23] <jam> hi poolie
[08:26] <jam> and vila, too!
[08:26] <vila> _o/
[08:29] <maxb> Does bzr actually use per-file DAGs to assist merging?
[08:30] <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:35] <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:36] <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:37] <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:42] <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:45] <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:46] <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:47] <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:48] <maxb> right, I'd better get myself to work now. I'll re-stare at trees
[08:48] <maxb> later
[09:01] <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:02] <vila> weird, what is hanging ?
[09:02] <jam> f = tarfile.extractfile('path'); f.read() the .read() is hanging
[09:03] <vila> O_o
[09:04] <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:05] <poolie> hi jam, vila
[09:06] <vila> _o/
[09:08] <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:10] <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:11] <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:12] <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:13] <vila> yes, in predictable ways (except on vbox slaves but I digress ;)
[09:14] <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:15] <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:16] <vila> and of course you're supposed to provide a sample that is not 80*800 chars long...
[09:19] <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:22] <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:23] <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:30] <maxb> 2.3.1 is up in ~bzr/proposed - testers appreciated
[09:34] <poolie> thanks maxb
[09:34] <poolie> i'll install it
[09:46] <poolie> jelmer, can you help me think of some other options?
[09:53] <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:54] <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:55] <jam> poolie: other options for? (and shouldn't you be sleeping by now?)
[09:56] <vila> jam: huh ? You said bloating the test wasn't good no ?
[09:57] <jam> vila: osutils.rand_chars(65536) isn't many characters in the file
 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:58] <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:59] <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
[10:00] <vila> if the test is random it's not a reliable reproducing recipe, do we agree on that ?
[10:01] <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:02] <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:03] <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:04] <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:06] <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:07] <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:08] <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:10] <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:12] <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:13] <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:14] <jam> but analyzing the data stream probably isn't the way to debug it
[10:15] <vila> then how about forgetting about the compressed stream and ensures we never corrupt it instead ?
[10:16] <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:17] <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:18] <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:19] <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:20] <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:21] <vila> yeah, some japanese may disagree :-/
[10:22] <jam> vila: /me => lunch, bbiab
[10:23] <poolie> i've been feeling sad about that
[10:24] <jam> poolie: ?
[10:24] <jam> I didn't mean to go to lunch and make you sad :)
[10:25] <poolie> :) the Japanese disasters
[10:32] <poolie> hello inada-n, i hope you're doing ok
[10:34] <inada-n> hello, poolie.
[10:34] <inada-n> About earthquake?
[10:34] <poolie> yes
[10:34] <inada-n> I'm OK in Tokyo.
[10:35] <poolie> good
[10:35] <vila> good
[10:35] <inada-n> Thanks, a lot.
[17:12] <jml> goaeruaeos
[17:12] <jml> I have to figure this out every six months
[17:12] <jml> how to get a list of landings I've done on launchpad
[17:14] <vila> jml: some filtering from qlog maybe ?
[17:15] <jml> vila: ahh, never mind. I apparently wrote a little plugin called pqmstats that does what I want
[17:15] <vila> hehe :)
[17:16] <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:18] <jml> vila: yeah, exactly like that
[17:19] <vila> good, I'm not suffering from Alzheimer then ;D
[17:19] <jelmer> hehe
[17:20] <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:21] <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:22] <vila> jelmer: 2.1.4 will be released soon so it's just a warm-up to see if I get it right
[17:23] <jelmer> vila: what about https://launchpad.net/bzr/2.3 ?
[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:24] <vila> and what is your last remark about ? 2.1 or 2.3 ?
[17:25] <jelmer> vila: there is https://launchpad.net/bzr/2.1 as well
[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:26] <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] <jelmer> there's a link on the right hand side
[17:26] <vila> ooooooh !
[17:27] <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:33] <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:35] <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:36] <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:37] <vila> 0 because 2.1.3-1 will come from debian and override it ?
[17:37] <jelmer> yes, exactly
[17:38] <jelmer> vila: it looks good to me otherwise
[17:38] <vila> ok, thanks !
[17:40] <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:41] <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:42] <vila> yeah, below the sapce
[17:42] <vila> space
[17:44] <g0nzal0> hello #bzr
[17:45] <vila> hello  g0nzal0
[17:46] <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:47] <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:48] <g0nzal0> is there a way around that? I can't get a full copy of that svn repo with bzr otherwise :(
[17:49] <maxb> g0nzal0: Actually, I think the forbidding of backslashes in pathnames is done in the core of Bazaar
[17:50] <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:51] <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:52] <g0nzal0> *removed from
[17:52] <g0nzal0> I mean, maxb
[17:52] <maxb> I'm not sure that will help you
[17:53] <g0nzal0> it doesn't, bzr branch stops when it hits the commit that adds that backslash-named file :(
[17:54] <jelmer> g0nzal0: the best way to work around it is to "svnadmin dump" the repository, eliminate the backslash and reload it
[17:55] <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:56] <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
[18:28] <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:30] <beuno> cr3, they merged trunk into a branch and pushed that up to trunk
[18:31] <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:32] <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:33] <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:34] <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:39] <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:41] <cr3> beuno: sounds like a good lead, thanks so much!
[18:47] <philsf> vila: it was not the last commit. Can I uncommit/commit and still preserve the original revision number?
[18:53] <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:54] <beuno> cr3, that's a good question
[18:54] <beuno> maybe lifeless knows
[18:55]  * jelmer waves
[18:56] <beuno> heya jelmer
[18:56] <maxb> cr3: "commit" it? It applies to a particular copy of a branch, not a project.
[18:57] <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:58] <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:59] <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
[19:00] <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:01] <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:02] <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:03] <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:04] <maxb> oh, sorry
[19:04] <maxb> I don't mean 863, 1 sec
[19:05] <maxb> hmm. We need to find the revision which was the tip of lp:checkbox which was before that erroneous merge was pushed
[19:07] <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:08] <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:09] <cr3> maxb: why not 863?
[19:10] <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:11] <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:12] <maxb> then we're going to pull, not merge, r862.2.31 of lp:checkbox
[19:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <maxb> To prevent it happening again, you can enable append_revisions_only on the Launchpad copy of the branch
[19:20] <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:21] <maxb> If your local bzr is new enough, you can just run "bzr config -d lp:checkbox append_revisions_only=True"
[19:22] <maxb> um
[19:22] <maxb> wait a moment, I think that may not work
[19:23] <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
[21:42] <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?
[23:22]  * jelmer waves to spiv
[23:26] <poolie> hi all
[23:27] <jelmer> poolie: g'day
[23:27] <poolie> hi jelmer
[23:28] <poolie> jam, still around?
[23:31]  * spiv waves back
[23:33] <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:34] <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:35] <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:36] <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:37] <jelmer> right, that makes sense
[23:38] <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:39] <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:40] <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:41] <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:43] <spiv> To be pedantic, strictly speaking I didn't imply my ideal world would have to have URLs ;)
 jelmer: I think it's just by accident, rather than design <-- i agree
[23:45] <spiv> Anyway, given we mix URLs and not-quite-URLs quite a bit now, we have two options that I can see:
[23:46] <spiv> 1) make functions like normalize_url that expect URLs also cope with not-quite-URLs
[23:47] <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:49] <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:50] <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:51] <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:52] <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:53] <spiv> I was about to say, I'm not sure that's the same bug (although I'm sure it's related)
[23:55] <jelmer> is :parent a directory as well? It seems odd that it breaks in that case, as "bzr push lp:foo" works
[23:58] <lifeless> jelmer: it needs to double dereference
[23:59] <lifeless> jelmer: when :parent returns lp:foo it breaks
[23:59] <jelmer> lifeless: ahh