spmlooking 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
ubot5Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/72658401:14
spivspm: let me double check01:22
spivspm: yes, 2.3.101:23
spmcoolio, do we have a ppa of that already I can backport from?01:23
spivspm: 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
spmokidoki. I'll update the RT with a request for a PPA we can backport off. ta spiv01:32
spivspm: Thanks!  Glad to have progress :)01:32
spmheh, nothing quite like being down 1-2 folks in a team of 4. :-)01:32
spivYeah, I bet.01:33
pooliemaxb, hi, could you update the ppas some time?01:39
maxbpoolie: hi01:58
maxbyes, I promised to do that this evening and have so far failed, due to Rocket Bunnies :-)01:59
maxbI shall do it before I sleep01:59
pooliethanks mate :)02:04
pooliei sympathize about the bunnies02:04
maxbyikes, there have been 19 revisions in the debian packaging branch since the last PPA release02:07
* maxb is confused02:26
maxb How can I be getting conflicts in files when merging 2.3.1 into ppa/natty ?!02:27
maxbupstream files, that is, not debian/*02:27
PengCherrypicking, maybe?02:48
AfCIs 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
lifelessthat changed?03:16
AfClifeless: 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
AfClifeless: 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
spivWas probably changed for https://bugs.launchpad.net/bzr/+bug/53026503:50
ubot5Ubuntu bug 530265 in Bazaar "Not modifying a suggested commit message commits anyway" [Medium,Fix released]03:50
spivI 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
lifelessspiv: or handle empty messages specially03:56
echo-areaSay 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
pooliehi jam07:04
echo-areapoolie: Thanks07:04
vilahi all !07:40
jamhi po08:23
jamhi poolie08:23
jamand vila, too!08:26
maxbDoes bzr actually use per-file DAGs to assist merging?08:29
maxbI'm getting all sorts of spurious conflicts in criss-cross situations, even though the specific files conflicting didn't criss-cross08:30
maxbe.g. the current merge of loggerhead trunk into daily-ppa08:30
maxband in fact, 4 files which didn't conflict drastically failed to have their changes merged correctly08:35
vilamaxb: not as well as it should, jam knows the best about this specific point08:35
jammaxb: merge --weave does08:36
jam(does what you want)08:36
jammaxb: thats the main problem with re-landing code :)08:36
jambut I'm trying to at least make sure that I do the work of merging into experimental08:36
jamI didn't realize the ppa branch would have that problem, too08:37
maxb--weave ... did not do what I wanted :-(08:37
maxbAt least for the daily-ppa branch I can just revert all the non-debian bits to the pending merge tip and be done with it08:37
jammaxb: can you point me to the branches you are merging? I can give it a look over08:42
jammaxb: I would guess the daily ppa would have tried to build the old trunk tip08:42
jamwhich has been removed from history08:42
jamwhich is going to confuse the hell out of everything08:42
maxbMost recently I was trying to merge lp:loggerhead into lp:~bzr/loggerhead/daily-ppa08:45
jammaxb: 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:loggerhead08:45
jammaxb: so probably the best thing is as you said08:45
maxbBut that had already been done in the past08:46
jammaxb: but not in the trunk branch, so things get really weird in history08:46
maxbevidently :-)08:46
jamdaily-ppa basically has a change for almost every file that supersedes what is in trunk08:46
jamwhat was in trunk08:47
jambut then trunk updates == conflicts08:47
maxbbzr 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
jammaxb: if we had reverted trunks contents using "bzr revert -r OLD; bzr commit", and then rebuilt experimental from there08:47
jamit would work better for you08:47
maxbright, I'd better get myself to work now. I'll re-stare at trees08:48
jamvila, 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 mode09:01
vilaweird, what is hanging ?09:02
jamf = tarfile.extractfile('path'); f.read() the .read() is hanging09:02
jamI'll try to trace into it to give better detail09:04
vilais there a pipe there ?09:04
jamvila: nope, it is reading from disk09:04
pooliehi jam, vila09:05
jamvila: ah, maybe it is "assertEqualDiff being unhappy trying to match 800 lines of gobbledy-gook09:08
jamvila: yeah, stopping the hang shows it in difflib09:08
jamso better and worse :)09:08
vila800 lines ? That's a lot...09:10
jamyeah, swapping out assertEqualDiff made it happier09: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
jamdoesn't seem very big to mee09:10
pooliewow, that's a bit bad it would hang09:10
vilahmm, please don't use rand_chars in tests, it is *guaranteed* to fail one day or another09:10
jampoolie: it might just go O(N^2) and die, or it might have a real bug in the diff code.09:10
jamvila: it is meant to09:10
jamhow do you expect it to fail?09:11
jam(I need a way to force '\r' and '\n' in the compressed streams)09:11
jamwhich has all sorts of "tar header", etc.09:11
jamI can hand-craft something today09:11
vilabecause you will encounter a combination that while unlikely will break the test ?09:11
jamor I can throw enough random data at it, that I'm sure it has at least one char09:11
jamvila: this is file content itself09:11
jamif we are not managing to preserve exact fidelity09:12
vilayeah, hand crafting is better, it's stable ;)09:12
jamwe have a problem09:12
jamvila: except there are timestamps, and mtimes that will vary09:12
jamwhich means that the real data may change its compressed form09:12
vilastill deterministic09:12
jamvila: deterministic in the sense that time.time() is always changing?09:12
vilayes, in predictable ways (except on vbox slaves but I digress ;)09:13
vilaso modulo restting the system clock, you can run the same twice and get the same result09:14
vilaintroducing randomness is the opposite of test isolation :)09:14
jamvila: still isolated tests09:14
jameach test does not depend on the other09:14
jamI can run 'osutils.rand_chars()' manually and hard-code it in the file, but that just bloats the test file (IMO)09:15
vilaand give us data to analyze if the test ever fails whereas rand_chars won't09:15
vilaand of course you're supposed to provide a sample that is not 80*800 chars long...09:16
vilaor said otherwise: if the test fails with 80*800 random chars, how would you debug it ?09:19
pooliedo we have any tests using rand_chars?09:19
vilahmm, 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 example09:22
vilawell, almost, there should probably be an assertion that we don't collide09:23
jampoolie: indirectly almost all of them via 'gen_file_id()"09:23
pooliewe should probably make them deterministic09:23
maxb2.3.1 is up in ~bzr/proposed - testers appreciated09:30
pooliethanks maxb09:34
pooliei'll install it09:34
=== hunger_ is now known as hunger
pooliejelmer, can you help me think of some other options?09:46
jamvila: I used hard-coded data. Now the test fails intermittently09:53
jam(explicitly not fixing the bug so that I know I should have a failing test.)09:53
jamit was failing reliably with 64k data09:53
jamit seems the timestamps are having a pretty strong effect on the compressed steram09:53
vilajam: then your data are not good enough ? Or you should isolate the test from the timestamps09:54
jamvila: I can make it 64k data and be done with it09:54
jam(which I had)09:54
jampoolie: other options for? (and shouldn't you be sleeping by now?)09:55
vilajam: huh ? You said bloating the test wasn't good no ?09:56
jamvila: osutils.rand_chars(65536) isn't many characters in the file09: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 bigger09:57
vilajam: how will you debug it if it fails ?09:58
jamvila: if we are corrupting the data stream, it doesn't matter what the content is, IMO09:58
jamvila: start looking for missing binary streams09:58
jamif it is 100 random chars, does that help debugging?09:58
jamsame problem09:58
vilayes the problem is the random part09:58
jamto trigger it, needs enough random data, that you can't eyeball the corruption09:58
jamvila: note that we also want to trigger it for raw tar, .tgz and .tbz2, and .tar.xz09:59
jamand .tar.lzma09:59
vilaif the test is random it's not a reliable reproducing recipe, do we agree on that ?10:00
jamvila: no10:01
vilaas 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 it10:01
jamvila: if the chance of failing is 1 in 2^25610:01
jamI'm fine with that10:01
vilabut you're pulling this number out of thin air right ?10:01
jam65k 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
vilasince you can only prove it to be right by establishing which inputs are valid/invalid10:02
jamvila: given 10k compressed characters, the odds it not having what we want is  10^-1710:03
jamvila: what bounds would you be happy with?10:03
jamvila: note, zlib changes the compressed stream from source from time to time10:03
jamit is allowed to10:03
jamfor the same compression settings10:03
jamas long as the actual decompressed content is the same10:03
jamvila: I can't give you 010:04
jamI can give you epsilon10:04
vilathat's my point10:04
jamvila: it means we can't force the compressed stream, but we can be really darn certain10:04
vilathe options are:10:06
vila 1) no test10:06
vila2) test with a hard-coded reduced length10:06
vila3) test with random data10:06
vila(3) is the worse because, a) it can't be debugged if it fails b) it will fail10:07
jamvila: I disagree on (b)10:07
jamif we are failing because of the content of files10:08
jamthen we have *serious* problems internally10:08
vilado you have a fix for the bug ?10:08
jamvila: 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 exporters10:10
vilajam: can you seed rand_chars and guarantee you will get the same chars  ?10:12
vilajam: can you still haven't answer: "How would you debug it ?"10:12
jamvila: with 800 random characters I had 2 accidental successes in 30 runs10:12
jamvila: looking at the stream isn't a way to debug it, regardless.10:13
jamunless you know a way to debug a gzip stream10:13
vilaIs that a way to say it can't be debugged ?10:13
jamespecially a gzip(tar) stream10:13
jamvila: it can be "oh it isn't getting the data back properly, I must have missed something"10:13
jambut analyzing the data stream probably isn't the way to debug it10:14
vilathen how about forgetting about the compressed stream and ensures we never corrupt it instead ?10:15
jamvila: we are corrupting the compressed stream10:16
jamhow do we forget about it?10:16
jam'bzr export -' is writing the stream to stdout, and we weren't setting the binary flag10:16
vilaby using a mock compressor ?10:16
jam'bzr export foo.tar.gz' was opening the output file without the binary flag10:17
jamvila: the bug was both in the command10:17
jamand in the individual code ptahs10:17
vilaand the issue is that it was corrupted because somewhere 'w' was used instead of 'wb'10:17
jamvila: if it was just the 'export -' we could put '\r\n' in the file content and 'plain_tar_export' it.10:18
jamvila: right10:18
jamplus the fact that GzipFile(mode='w') automatically sets 'wb'10:18
jamso we had 'w' before10:18
jambut we switched to GzipFile(open('w'))10:18
jamand ooops, it broke10:18
vilaif you can't reliably inject a stream that would be corrupted because you don't control how it's transformed, I'm saying: control it10:18
jamvila: GzipFile is going to be python-version dependent, and possibly platform dependent10:19
jamhow do you want to control it, since we want to be testing the specific code path10:19
jamBzipFile happened to be ok, plain_tar_export was bad, GzipFile was bad10:19
jamZipFile I think was ok10:19
jamI'd like to make sure that transforming the code paths in ways that look fine, still are actually fine10:20
vila'make sure' != 1e10-1710:20
jamvila: osutils.rand_chars(65536)10:20
jam10^-17 is sure for me10:20
jamif you prefer, I can make it10:20
vilayeah, some japanese may disagree :-/10:21
jamvila: /me => lunch, bbiab10:22
pooliei've been feeling sad about that10:23
jampoolie: ?10:24
jamI didn't mean to go to lunch and make you sad :)10:24
poolie:) the Japanese disasters10:25
pooliehello inada-n, i hope you're doing ok10:32
inada-nhello, poolie.10:34
inada-nAbout earthquake?10:34
inada-nI'm OK in Tokyo.10:34
inada-nThanks, 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
jmlI have to figure this out every six months17:12
=== beuno is now known as beuno-lunch
jmlhow to get a list of landings I've done on launchpad17:12
vilajml: some filtering from qlog maybe ?17:14
jmlvila: ahh, never mind. I apparently wrote a little plugin called pqmstats that does what I want17:15
vilahehe :)17:15
vilajml: 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 !" :-D17:16
jmlvila: yeah, exactly like that17:18
vilagood, I'm not suffering from Alzheimer then ;D17:19
vilajelmer: I think you miss my msg yesterday about lp:~vila/ubuntu/lucid/bzr/sru-2.1.317:20
jelmervila: I think I might - what was it?17:20
vilajelmer: can you have a look at it (no urgency), there is a dirty trick in debian/watch but I filed bug #736145 about it17:21
ubot5Launchpad bug 736145 in Launchpad itself "no series specific download pages" [Low,Triaged] https://launchpad.net/bugs/73614517:21
vilajelmer: 2.1.4 will be released soon so it's just a warm-up to see if I get it right17:22
jelmervila: what about https://launchpad.net/bzr/2.3 ?17:23
ubot5Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)17:23
jelmervila: it's only got the latest release, but that should be sufficient in our case17:23
vilaEPARSE, what about 2.3 ?17:23
vilaand what is your last remark about ? 2.1 or 2.3 ?17:24
jelmervila: there is https://launchpad.net/bzr/2.1 as well17:25
ubot5Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)17:25
jelmervila: 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 sufficient17:25
vilahaaa, for watch file!17:26
jelmervila: well, that /is/ what you were asking about.. :)17:26
vilajelmer: but these pages doesn't mention the tar.gz17:26
vilajelmer: but these pages don't mention the tar.gz17:26
jelmervila: they do17:26
jelmerjust check https://launchpad.net/bzr/2.1 or https://launchpad.net/bzr/2.317:26
ubot5Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)17:26
ubot5Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)17:26
jelmerthere's a link on the right hand side17:26
vilaooooooh !17:26
vilaright, so for old stable series and as long as we are fast enough to keep track, yeah, far better than my dirty trick17:27
vilajelmer: 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
vilajelmer: or will 2.1.4 require a roundtrip via debian  (squeeze provides 2.1.2) ?17:35
jelmervila: the version should be 2.3.1-0ubuntu117:35
vila2.1.3-0ubuntu1 you mean ?17:36
jelmervila: (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
jelmervila: sorry, yes17:36
vila0 because 2.1.3-1 will come from debian and override it ?17:37
jelmeryes, exactly17:37
jelmervila: it looks good to me otherwise17:38
vilaok, thanks !17:38
jelmervila: 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
vilaoh, not loggerhead17:40
vilathe '+' should below the 'N'ew ?17:41
jelmerit should have one more space than the *17:41
jelmerso it should be below the space in the previous line17:41
vilaha no17:41
vilasry, was looking at wrong file17:41
vilayeah, below the sapce17:42
g0nzal0hello #bzr17:44
vilahello  g0nzal017:45
g0nzal0I'm using bzr 2.2.1 with the svn plugin (version 1.0.4)17:46
g0nzal0I'm trying to branch an svn repository, but said repository has a commit of a file named \17:46
philsfI 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, fwiw17:47
vilaphilsf: uncommit/commit if it's the last commit you did17:47
g0nzal0the svn plugin conveniently checks for this and raises an exception17:47
g0nzal0is 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
maxbg0nzal0: Actually, I think the forbidding of backslashes in pathnames is done in the core of Bazaar17:49
maxbthis 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 Bazaar17:50
g0nzal0maxb, yes it is (tried commenting out the check on the svn plugin and got an exception from bzr)17:51
g0nzal0magcius, the file is removed in the svn repo in a later commit17:51
g0nzal0*removed from17:52
g0nzal0I mean, maxb17:52
maxbI'm not sure that will help you17:52
g0nzal0it doesn't, bzr branch stops when it hits the commit that adds that backslash-named file :(17:53
jelmerg0nzal0: the best way to work around it is to "svnadmin dump" the repository, eliminate the backslash and reload it17:54
g0nzal0jelmer, 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
jelmerg0nzal0: there is a bug report in bzr about this, but it hasn't seen much activity recently17:56
* jelmer will be back later17:56
=== beuno-lunch is now known as beuno
=== psynaptic|break is now known as psynaptic
cr3hi 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
beunocr3, they merged trunk into a branch and pushed that up to trunk18:30
cr3beuno: 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
beunoI guess someone could push --overwrite18:31
beunoif they have trunk18:31
cr3beuno: yeah, "if they have trunk" is the problem, I just pulled from trunk so mine is reverted now :(18:32
beunonot sure how to revert that easily18:33
cr3beuno: 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 fix18:33
cr3beuno: 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
beunocr3, no, no --overwrite18:39
beunoyou can, however, set a flag that won't allow this to happen again18:39
beunoappend_only or something18:39
beunoI forget where to set it18:39
cr3beuno: sounds like a good lead, thanks so much!18:41
philsfvila: it was not the last commit. Can I uncommit/commit and still preserve the original revision number?18:47
cr3beuno: 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 project18:53
beunocr3, that's a good question18:54
beunomaybe lifeless knows18:54
* jelmer waves18:55
beunoheya jelmer18:56
maxbcr3: "commit" it? It applies to a particular copy of a branch, not a project.18:56
maxbUsually you would set it on the branches on a server that people share18:57
maxbBazaar might copy it to new branches 'bzr branch'-ed from that - I'm not sure, you'd have to test.18:57
maxbcr3: 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
cr3maxb: 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 branched18:58
maxbcr3: Is this project public? It would be easier to explain with specific examples. If not, I can explain more generically18:58
cr3maxb: 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 now18:59
maxbcr3: However I would still advise you *NOT* to push --overwrite that18:59
cr3maxb: the project is public and, if you happen to have a moment, I wouldn't mind understanding how to resolve this kind of situation19:00
maxbWe can fix your revnos without forcing everyone else to "pull --overwrite" and potentially have to replay their own local commits19:00
cr3maxb: really? why not?19:00
maxbI don't understand the "why not?" question19:00
cr3maxb: good point. although there are probably not that many people branching the project, I try to do things right when possible19:00
maxbOk - give me the URL for the branch concerned, and I'll have a look19:01
cr3maxb: I meant "why not push --overwrite", but you answered before I hit enter :)19:01
cr3maxb: lp:checkbox19:01
maxbfetching..... meanwhile, have you used "bzr qlog" previously?19:01
maxbI find it an awesome tool for understanding revision graphs19:02
cr3maxb: the problematic revision is 864 and no, haven't used qlog before19:02
maxbyikes, that revision merged an awful lot of trunk changes, didn't it :-)19:02
cr3maxb: totally :)19:02
cr3maxb: about 30 revisions worth :)19:02
cr3well, 30 revisions based on difference of current revision in trunk and what it should be19:03
maxbOK, so here's how we go about restoring the "left hand" or "first parent" ancestry that determines revnos19:03
maxbFirst you branch lp:checkbox at 86319:03
maxboh, sorry19:04
maxbI don't mean 863, 1 sec19:04
maxbhmm. We need to find the revision which was the tip of lp:checkbox which was before that erroneous merge was pushed19:05
maxbAh, OK, so I think that was the current 862 "Merged from testsprint-checkbox-base-sru-changes."19:07
maxbRight, let me start again, and get the numbers right this time19:07
cr3maxb: I'll follow what you say in qlog19:08
mgzvila: 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
maxbSo, 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
cr3maxb: why not 863?19:09
maxbHaving looked at the history, it looks to me like the "bad" merge was an attempt to land the revision which is currently 863 on trunk19:10
maxbMore importantly, 863 is diverged from the long string of revisions which we want to put back on the mainline19:11
cr3maxb: exactly, now I understand where you're getting at19:11
maxbOK, so having done that, for the sake of illustration, you might choose to turn on append_revisions_only = True in the local branch19:11
maxbthen we're going to pull, not merge, r862.2.31 of lp:checkbox19: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
=== psynaptic is now known as psynaptic|break
maxbAfter that, we *merge* the formerly "bad" merge commit - i.e. we 'bzr merge -r 864 lp:checkbox'19:14
cr3maxb: 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 unfortunately19:14
cr3aha, after that pull, I get: Now on revision 893.19:14
cr3which is sounding very sane!19:14
maxbAnd commit that with a message of something like "Land translation work by Mahyuddin Susanto via Michael Terry."19:15
cr3maxb: you didn't forget 863, right?19:15
maxbNo, this is intentional - the one merge is going to pull in 863 & 86419:15
cr3of course, my bad :)19:16
maxbOnce you've done this commit, you are back in the rough "shape" of the tree that you wanted to have kept all along19:16
cr3maxb: this is amasing, really!19:17
maxbThe 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
cr3maxb: Thanks so much for taking the time to explain this to me, I'm keeping this irc log and framing it somewhere :)19:17
maxbSo, "bzr merge -r 865 lp:checkbox" (or for that matter just "bzr merge lp:checkbox")19:17
maxbAnd commit19:17
maxband we're in our final desired state. Only thing remaining is to then push back to lp:checkbox - *without* --overwrite19:18
cr3makes perfect sense19:18
cr3excellent, so my contributors will not need to pull --overwrite themselves. win!19:18
maxbTo prevent it happening again, you can enable append_revisions_only on the Launchpad copy of the branch19:19
cr3maxb: how can I ssh/scp/ftp there again?19:20
cr3I once accessed the server to rm branches but that was a very long time ago19:20
maxbIf your local bzr is new enough, you can just run "bzr config -d lp:checkbox append_revisions_only=True"19:21
maxbwait a moment, I think that may not work19:22
maxbbzr config -d bzr+ssh://bazaar.launchpad.net/+branch/checkbox append_revisions_only=True19:23
maxbowing to a bug in current bazaar, you need to not use the lp: shortcut here19:23
=== psynaptic|break is now known as psynaptic
=== Ursinha-lunch is now known as Ursinha
philsfI 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 spiv23:22
pooliehi all23:26
jelmerpoolie: g'day23:27
pooliehi jelmer23:27
pooliejam, still around?23:28
* spiv waves back23:31
jelmerspiv: 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
spivjelmer: I think it's just by accident, rather than design23:34
spivI'm pretty sure there's a bug or two about how we should store unresolved directory service locations.23:34
jelmerspiv: 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
spivThere is a bit of an issue that directory services might resolve differently, or even be not present at all, for different users.23:35
spivSo I guess if we start storing them we should take care to handle that gracefully23:36
spivI 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
jelmerright, that makes sense23:37
jelmerspiv: so I guess then a related issue is: is "lp:bzr" something that urlutils should handle gracefully?23:38
spivWe're really mixing different types of variable23:38
jelmerOn 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 meaning23:38
spiv"URL" and "location" might be good names for those types, if we had statically typed variables.23:39
spivOr "URL" and "BRL" ;)23:39
spivSo in my ideal world, we'd never all normalize_url on something that isn't a proper URL23:40
jelmeryour ideal world has URLs ? :-P23:40
spivBut we sometimes use them interchangeably, although sometimes not (the CLI isn't consistent about what it accepts)23:41
spivTo 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 agree23:44
spivAnyway, given we mix URLs and not-quite-URLs quite a bit now, we have two options that I can see:23:45
spiv1) make functions like normalize_url that expect URLs also cope with not-quite-URLs23:46
spiv2) try to be stricter about not using not-quite-URLs interchangeably with URLs23:47
spivMaybe there are other options.23:47
pooliei think 'lp:' is a proper url23:47
poolieor 'should be treated the same'23:47
spivOr 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
jelmerspiv: This is the stacked-on argument to cmd_push()23:49
spivAh, right.23:49
spivSo, essentially, yes :)23:50
jelmerspiv: yes, indeed23:50
spivI don't feel strongly about which route we should take, but I do feel strongly that the current situation is a problem :)23:50
jelmerI 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
lifelessthere is a bug on directory lookups in push :parent as well IIRC23:52
lifelessso you'dfix more than one bug :>23:52
lifelesssorry, I mean, while you're there consider doing more ;)23:52
spivI was about to say, I'm not sure that's the same bug (although I'm sure it's related)23:53
jelmeris :parent a directory as well? It seems odd that it breaks in that case, as "bzr push lp:foo" works23:55
lifelessjelmer: it needs to double dereference23:58
lifelessjelmer: when :parent returns lp:foo it breaks23:59
jelmerlifeless: ahh23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!