theboltok, thanks for your help so far jelmer , suspect i might be back with more another day :)00:00
=== mw is now known as mw|out
kiko-afkhey hey00:14
kiko-afkanyone have a moment to look at https://bugs.edge.launchpad.net/bzr/+bug/19521700:14
ubotuLaunchpad bug 195217 in bzr-lpreview "ReadOnly error when running bzr review-submit" [Undecided,Fix committed]00:14
jamnigth all00:15
abentleykiko-afk: What's to look at?  I've already submitted a fix and attached it as a patch.00:22
spivjam: good night00:26
mwhudsonand i've merged and pushed said patch00:29
abentleymwhudson: So we can mark it fix released, then?00:32
mwhudsonabentley: i guess so00:32
spivabentley: bundle buggy is giving 'database is locked' errors for me00:33
abentleyOr are there actual releases of that plugin now?00:33
abentleyspiv: Apologies.  It's having trouble digesting your patch.00:33
spivabentley: ah00:35
abentleyOf course, it *shouldn't* be.00:35
spivabentley: I should have guessed that my patch-bombing had something to do with it :)00:35
mwhudsonabentley: i certainly haven't released it00:40
=== BasicMac is now known as BasicOSX
abentleymwhudson: Well, the bug statuses are problematic this way.  If there's nothing left to do, we have to say it's at the end state, i.e. fix released.01:01
spivabentley: getting connection failed from bb now -- is that a good sign or a bad sign? :)01:15
abentleySign of desperation.01:15
abentleyThe last time it tried to handle your message, it got hung up on a lock error.01:16
abentleyWhich appears to be due to the visitor thread.01:16
abentleyWhich shouldn't run if there are no visitors.01:16
spivAh :)01:17
spivA good sign then (in the short term).01:17
abentleyMaybe.  There's all kinds of things wrong here.01:18
spivIt seems odd that it would take so long to process my message.  It's just a patch (not a merge directive w/ bundle).01:18
abentleyStarting with my virtual server being so slow.01:18
abentleyYes, I agree wholeheartedly.01:18
abentleyAnd there's also the issue that I can't reproduce these lock errors locally.01:19
abentleyWell, it took 5 minutes, but it managed to process one of your messages.01:23
spivabentley: hooray!01:24
abentleyspiv: We now return you to your regularly-scheduled bundle buggy01:51
spivabentley: thanks!01:51
abentleybtw, why did you send those as patches?01:51
spivBecause they're in a great big branch, and I decided just slicing the final patch by file was a good way to break it up.01:53
AfCspiv: what, exactly, did you use to do that? `bzr merge --overwrite .../path/to/other/branch ?01:54
abentleyAh.  I was thinking you'd done it as a loom and were firing off per-branch diffs.01:54
spivabentley: I did, but I've already merged the other bits in the loom :)01:55
spivI wasn't aggressive enough about making threads, perhaps.01:55
spivAfC: Just "bzr diff -r submit: > everything.patch", then by hand broke it into pieces (pretty easy, given that I was just splitting by file rather than trying to edit hunks).01:57
AfCby hand?02:02
* AfC was harbouring the hope that effective cherry picking support had arrived.02:02
spiv"vim everything.patch", and remove everything except e.g. message.py + client.py, save as a new patch, send to the list.02:02
spivAnd repeat until I've sent everything.02:03
spivI was going to try break it down into a series of logical steps from the commit history until I realised that with this code, the individual files are actually pretty independently reviewable.02:03
abentleylifeless: around?02:08
lifelessabentley: hi02:16
abentleySo I went to start adding the checks pack-1.5, so that it wouldn't accept a revision whose inventory SHA1 didn't match the actual inventory sha1.02:17
abentleyAnd it seems that it was already clobbering the inventory sha1.02:17
abentleyThe one in the revision, I mean.02:17
lifelessI didn't think I merged anything to fix them up02:18
lifelessand checking bzr.dev it still looks to be missing any fixup02:18
lifelessabentley: ah yes, thats not the fetch code path :)02:19
lifelessabentley: I think jelmer fixed this a couple of releases ago02:20
abentleyIt's one of them.02:20
abentleyThis should be the codepath used when serializers differ.02:20
abentleyAnd also for old bundles.02:21
lifelessabentley: so this function looks correct to me: supply an inventory and revision, and the inventory is serialised and its sha put into the revison02:21
lifelesssupply just a revision and the revision is assumed to be fully populated02:22
abentleyWell, it looks like it does what you think we should be doing.02:22
lifeless*IF* the plain to rich root fetch used this code path it would02:22
lifelesshowever, if you look at fetch.py02:23
lifelessand Inter1and2Helper02:23
lifelessfetching does a regular join of all the file knits02:24
abentleyThey use GenericRepoFetcher, which uses the Store directly?02:24
lifelessthen adds a empty text for the root directory for all revisions02:25
lifelessthen reserialises the inventories (via iter_rev_trees)02:25
lifelessand finally bulk copies the revisions and signatures02:25
abentleySo the thing I didn't understand until now is that we were already mutating revisions all over the place.02:27
abentleySo you can easily have wrong SHA1s in a rich-root-repo, but you can also have right ones.02:29
abentleyAnd when you create a bundle and send it to a friend, they may wind up with different SHA1s from you, even with the same inventory format.02:29
abentleySo it seems like the referential integrity I was trying to preserve is already hopelessly lost.02:30
mathrickjam: sweet, I got it working, so now I have a status page with error reporting, and mostly reliably failing commits02:30
mathrickjam: http://sei.meidokon.net/ for a success page, http://sei.meidokon.net/status-fail.html for a fail page (except that it was deliberately triggered for non-diverged trees, so the revisions on both sides are the same)02:33
mathrickjam: I'm really happy now, thanks for your help :)02:33
beunoVerterok, :)02:34
Verterokbeuno: Hi02:35
lifelessabentley: I think we're both trying to preserve a form of referential integrity02:36
lifelessabentley: but xml8 should make both of us happy02:37
abentleyxml8 would, but I'm not sure I see the point anymore.02:37
abentleyIf we're already rewriting SHA1s all the time, why shouldn't reconcile do it?02:38
lifelesswell, I don't really like the idea of reconcile doing it02:38
lifelessit just seemed expedient to have the ability to repair a repository02:39
abentleyBut if we did address that issue, you'd feel good about making rich-root-pack the default, right?02:39
abentleyAnd since it's been supported since bzr 1.0, we could do that in the next release, right?02:40
lifelessI think we have a convesion bug02:40
lifelessbut modulo that, yes02:40
spivShould we rename 'reconcile' to 'repair'?02:41
abentleyspiv: How about "refurbish"?02:41
lifelessspiv: possibly; I was thinking sha1 changes would need an option anyhow02:41
spivabentley: renovate!02:41
spiv"bzr renovation-rescue"02:42
abentleySeriously, I'd prefer a term that connoted "maintenance" rather than "data recovery".02:43
abentleylifeless: I wish I'd understood in London that we were already rewriting SHA1s.02:44
abentleySo much time and stomach lining wasted.02:44
lifelessabentley: :(.02:46
lifelessI clearly failed to communicate the knowledge I had effectively02:47
abentleyOr maybe I didn't listen clearly.02:47
abentleyOh well.02:48
abentleylifeless: What's the current state of stacking?03:01
lifelessabentley: the prototype works on sftp only;03:01
lifelessI'm rapidly closing in on the migrated versionedfiles logic03:02
lifelesswhich enables making it work on bzr+ssh03:02
lifelessby breaking the dependency on format-matching03:02
abentleyDo you plan to update the prototype?03:03
lifelessoh yes03:05
lifelessand polish it03:05
lifelessits just an ordering thing03:05
abentleyThe last version I have doesn't pass the test suite, and doesn't merge bzr.dev cleanly.03:05
abentleyI'll send you my test suite fixes at least.03:06
jmlspiv, abentley: how about 'bzr defrag'03:13
lifelessyay, no more use of KnitVersionedFile.join() from within the knit internals03:14
lifelessjml: that is 'pack'03:15
lifelessjml: pack rearranges. reconcile cross-checks indices, graphs etc03:15
mwhudsonhey guys, i can reproduce https://bugs.edge.launchpad.net/bzr/+bug/217701 with bzr.dev at both ends03:53
ubotuLaunchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix committed]03:53
mwhudsoni thought the fix was in bzr.dev by now03:53
mwhudsonoh er, maybe not03:59
* igc lunch04:05
abentleyigc: Your vote on the send documentation wasn't captured by BB because you didn't reply to the right message.04:37
lifelessspiv: ping05:31
lifelessmeh codeslinger is spamming a huge number of bugs with a fairly aggressive tone05:43
thumperOdd_Bloke: I'd like a chat at some stage when you're around05:44
lamalexWhat's the right way to fix files that bzr resolve put "<<<<<< tree" into?05:45
bob2bzr resolve won't do that05:49
bob2you run bzr resolve on the file once you remove those lines05:49
lamalexso is it a hand prune situation?05:50
lifelessyes, you get to choose which side you want to keep05:51
lifelessor if you want to merge the sides05:51
bob2merge or pull produced conflicts (the command will tell you), then you edit the files to resolve it the way you want, either picking a side or combining them05:51
igcthanks abentley05:59
=== mbp_ is now known as poolie
lamalexsorry for asking all of these questions, I've created a bundle, now what can I do with it if my project doesn't have an email associated with it06:34
lamalexcan I assign one?06:34
bob2you can send that to whoever would review and potentially merge your changes - the project author or the developers list or wherever06:35
lamalexA[A[A[Abzr: ERROR: No mail-to address specified.06:35
lamalexsorry for the preceding garbage06:35
lamalexhow do I specify an email for the project?06:36
bob2oh, right - you can use 'bzr bundle -o somefile.bundle' to get it into a file06:36
lamalexah ok06:36
PengYou should use "bzr send -o foo.patch" instead of bundle now, I think. I dunno if there's a benefit... :P06:36
bob2send takes a --mailto option06:36
lamalexI should really rtfm06:37
bob2hrm, me too it seems06:37
lifelesspoolie: mail sent06:38
lamalexso that little hash is my patch?06:39
lamalexmaybe I didn't do bundle right06:39
lifelessbob2: 'bundle' is not meant to be used these days06:40
lamalexwhat do we use today?06:41
lifelessbzr send06:41
lamalexjust send? it takes care of everything?06:41
lamalexincluding making the patch?06:41
lifelessyou can give it various parameters06:41
lamalexSo I just want to submit a patch for 1 file foo06:41
bob2lifeless: ah, right06:42
lifelesslamalex: make the change, commit it, then run bzr send --mail-to=xxx06:42
lifelesslamalex: (or instead of --mail-to, you can use -o- to get it on the console)06:42
lamalexis there a way to say only make a patch for file X?06:43
lamalexdo I just give it that file as an argument?06:43
lifeless'bzr diff -r -X FOO'06:44
lifelesslamalex: but this discards your commit history06:44
lamalexhm, it doesn't like -X06:44
lifelesslamalex: well, the X should be a number for how far back in history to go06:45
lifelessou can use the send logic by doing 'bzr send -r submit: FOO'06:45
lamalexmaybe I'll just do this the old fashioned way with GNU diff...06:45
lifelesslamalex: perhaps you could tell me the whole use case, I feel like I'm playing catchup here06:46
lamalex:) ok06:46
lamalexSo I fixed a bug, I need to make a patch, but it's not the only file that changed in the tree06:46
lifelessdid you commit the bugfix on its own?06:46
lamalexwell the other files that changed are IDE files that we keep in the tree06:47
lifelesse.g. 'bzr commit -m 'fix bug' somefile.c'06:47
lamalexoh snap I had no idea you could commit a single file06:47
lifelesssend can send a single commit06:47
lifelessor if you have just made a single local commit, just a normal send will do the right thing06:48
lifelessyou can use 'bzr uncommit' to pop the most recent commit06:48
lifelessthis does not alter the files in your tree, it only changes a pointer to the history06:48
lamalexI know that one06:48
lamalexso I commited just that file06:48
lamalexnow I want to bzr send --mail-to ...06:49
poolieoh suddenly it's a lot louder06:50
lamalexsorry for waking the baby06:50
lamalex(not calling you a baby, referring to an imaginary infant)06:50
lamalexahh ok, this calls your mail client to send an email. hmm06:52
lamalexSo how does a project do code review on this? It just looks like a hash and nothing else?06:54
lifelesslamalex: by default it should have the diff06:54
lamalexI wonder what I'm doing wrong06:55
lifelesslamalex: what options did you give 'bzr send'?06:55
lamalex--mail-to -o06:55
lamalexwith arguments06:55
lifelesswhat arguments06:55
lamalexwhat does it diff against? the version in the parent branch?06:55
lamalexbzr send --mail-to gnome-do@googlegroups.com -o RenameTo.patch06:56
lifelessit picks the least common ancestor to diff against06:56
lifeless--mail-to and -o are exclusive options I thought06:57
lifelessand by default (unless you have told bzr otherwise) it does that comparison against the parent branch06:58
lamalexbzr didn't give me any erros for using both06:59
lifelessindeed; we may have a bug there06:59
lamalexand it's not giving me any diff07:00
lifelesslamalex: so, lets do a quick diagnostic07:01
lifelesslamalex: what does 'bzr missing' tell you07:01
lifeless(just that, no options)07:01
lamalexmy last commit of just the 1 file07:02
lifelessand it says you have that locally?07:02
lamalexanything look out of place?07:06
lifelesslamalex: ok, thats good. Now lets check the commit07:07
lifelesslamalex: 'bzr diff -r -2'07:07
lifelesslamalex: does that show the expected diffs07:08
lamalexit shows more than it should actually07:08
lifelesslamalex: oh, do 'bzr diff -r -2..-1'07:08
lamalexlooks ok07:11
lifelessnow 'bzr send -o-'07:12
=== mtaylor is now known as mtaylor|zzz
lamalexlike a little airplane?07:13
spiv(holding your arms out and making "vrrrrm!" noises is optional)07:14
poolielifeless: thanks, nice draft07:14
poolieyou could send the whole thing with take 1 and take 207:14
lifelesslamalex: so did it look better?07:14
lifelesslamalex: looks like during learning about send you have overriden its heuristics07:16
lifelesslamalex: try07:16
lifeless'bzr send http://bazaar.launchpad.net/~do-core/do/devel/ -o-'07:16
lamalexno that's an A+07:17
lamalexso now I want to do bzr send .... -o RenameTo.patch07:17
lifelessif you add --remember it will remember that url for you07:17
lifelessif you want to send it to the list, just replace -o- with --mail-to= ...07:17
AfCOh, while you're on the topic of bundles,07:17
AfCI'm updating the HACKING instructions for the project I maintain,07:18
AfCand I'm trying to formulate a better description of the SUBMIT_BRANCH and PUBLIC_BRANCH arguments07:18
AfC... I had been telling people to do07:18
AfC$ bzr bundle ../mainline07:18
poolieyeah that is a bit confusing07:18
poolieneeds better names07:18
AfCwhich was working fine until one day I attempted to merge that bundle in a place that didn't _have_ a ../mainline07:19
poolieafc, i think they should set submit_branch in locations.conf rather than typing it every time07:19
poolieit can be remote07:19
AfCpoolie: so, it seems to remember it07:19
lifelessAfC: their ../mainline should have a 'public_location' set07:19
AfCpoolie: or sorry, rather, something (not necessarily bundle) sets it07:19
lifelessAfC: if it has that then the resulting bundle will reference http://.....07:19
AfClifeless: that's what I figured, Rob, so what I was going to change it to was07:19
denndaHi. I can't seem to get push to work to a remote server via ssh. Isn't 'bzr push bzr+ssh://user@server.tld/some/path correct?07:20
AfCbzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline > /tmp/name-that-tune.patch07:20
lifelessdennda: that looks fine07:20
AfClifeless: ... but I wasn't sure if that was actually correct07:20
lifelessAfC: several things can be improved there07:20
AfC(in terms of me not getting a branch not found error at the other side)07:20
lifelessAfC: if you set the public location of ./mainline, then the user does not need to specify the full url07:21
denndalifeless: I get this:07:21
lamalexthanks a lot lifeless07:21
lamalexsee you guys07:21
dennda(And yes, of course I got bzr installed)07:21
spivdennda: that's correct, but note that "some/path" is relative to the root of the filesystem (not your home dir)07:21
lifelessAfC: if you use send, better data is chosen and sent. -o /tmp/name-that.patch will output to a named file07:21
denndaspiv: yes, I know07:21
AfCdennda: you know that /some/path is from system /, not some hypothetical DocRoot07:21
spivdennda: ah, it seems "bzr" isn't on your path on the remote system07:21
denndaspiv: I need to install bzr remotely?07:22
bob2dennda: to use bzr+ssh - alternatively you can use sftp://, which doesn't require bzr on the server07:22
lifelessAfC: lastly, send will remember the submit branch, and by default uses the parent branch. so generally 'bzr branch; bzr commit; bzr send --mail-to=xxxx' is all that is needed for correct operation07:22
bob2confusingly, sftp urls are relative to your homedir, iirc07:22
spivTo use bzr+ssh, yes.  bzr+ssh works by running bzr on the remote end and sending commands to it.07:22
lifelessbob2: they are not07:23
lifelessbob2: the expired I-D on sftp urls had them homedir relative, but its expired, and the gnome folk, like bzr, thought that that was crack07:23
spivbob2: the difference you are thinking of is that our sftp URLs can have /~/ at the start of the path to make them relative to your homedir.07:23
lifelessAfC: I hope that helps07:23
AfClifeless: investigating...07:23
AfClifeless: (ie, comparing the various permutations)07:24
AfClifeless: I supposed one assumption I should have stipulated is that the public URL isn't available (due to disconnected operation) at time of creating the bundle.07:24
spivdennda: as bob2 says, you can use sftp:// instead of bzr+ssh://, and it works quite well07:24
AfClifeless: else07:24
AfCbzr bundle bzr://research.operationaldynamics.com/bzr/java-gnome/mainline07:24
AfCalone would have done it07:25
lifelessAfC: thats why setting public_url is useful07:25
lifelessAfC: it just tells bzr the url to use when generating a reference to the branch07:25
AfClifeless: which the full form _does_ seem to do....07:25
AfC(even remembers on first use)07:26
lifelessmost bzr commands that take optional urls remember them the first time they are supplied07:26
lifelesspoolie: I think I'll just send take 2.07:26
AfC(one of the nice things about what you guys do)07:26
bob2spiv: ah, oops07:27
AfCAnyway, that brings me back to thinking I should recommend the full form for first use.07:27
lifelessAfC: I would recommend that ../mainline have a public url set. And that users specify ../mainline on first use.07:28
denndaah great, thanks lifeless, AfC, bob2 and spiv :)07:28
denndainstalling bzr remotely would've been an issue... (debian etch with bzr 0.11)07:28
AfClifeless: as in, me going to the server and hacking something into the branch.conf there?07:28
denndabut sftp works07:28
lifelessAfC: no07:29
lifelessbzr help configuration07:29
AfCdennda: installing bzr manually from source is quite trivial, so don't think there is a big barrier to getting current code.07:29
lifelesslook for public_branch07:29
bob2lifeless: I-D?07:29
lifelessbob2: Internet-Draft07:29
spivdennda: (fwiw, having bzr 0.11 is technically new enough to work with bzr+ssh://, but it's not really any better than using sftp://)07:29
AfCAH that's what I was looking for the other day. Couldn't really sniff it out of the topic list.07:30
bob2oh, right, that is cracktastic07:30
denndaAfC: as long as there's sftp:// I'm happy07:30
denndano need to install it remotely07:30
AfClifeless: ... right, but `bzr bundle ../local bzr://public` sets/remembers/whatever public_branch07:31
AfClifeless: maybe we're violently agreeing with each other07:32
lifelessAfC: we're not07:33
lifelessAfC: I was saying that ../local needs *its* public branch set07:34
AfClifeless: right. But I cannot impose that on someone who has already cloned.07:34
lifelessAfC: sure you can, its easy for them to do07:34
AfC_them_? You expect me to tell newbies to hand edit some internal configuration file?07:35
lifelessAfC: that said, the target branch shouldn't matter to you when you apply the bundle07:35
AfClifeless: ... it did {somehow, due to my ignorance, my not doing something right, or my being able to do the wrong thing in the fists place), which is why I raise the topic07:36
lifelessAfC: if you expect them to have a local mainline mirror07:36
lifelessAfC: well, if you can reproduce it, I'll happily assist debugging it for you, or at least explaining it if its not a bug07:36
AfClifeless: I imagine it'll happen each time I do a merge now, as I'm attempting to use checkouts and switch.07:37
AfClifeless: I'll keep an eye out and report back.07:37
AfCAs for the other side of the coin, you are recommending that I _not_ adjust branch.conf on the publicly hosted branch?07:38
lifelessAfC: I don't think that setting it in the branch.conf of your public mainline would be a good idea.07:38
AfCReally. Huh. Puzzling.07:39
AfCI guess I'll go and see if I can figure out why not.07:39
lifelessAfC: either it won't propogate, in which case its pointless, or it will propogate, and all your new branches would claim to be your mainline.07:39
AfCWell, I was aware of the former. The later is a bit of a surprise, but ok.07:40
AfCFair enough.07:40
poolie29 errors to go...07:40
lifelessAfC: if it propogated, then each new branch would think that when its pushed, the regular url other folk should use would be your mainlines url.07:41
AfClifeless: yeah, I get it now07:42
AfClifeless: so is http://rafb.net/p/KxYMcB25.html wrong? [I realize you have better things to do be doing than reading stuff from me, sorry]07:42
poolieafc, that looks useful07:44
pooliei thought we were encouraging people to use send -o instead of bundle?07:44
lifelessAfC: the bundle command is problematic07:45
lifelessAfC: the 'public_url' parameter is the public url of the branch being submitted07:45
poolieand i think that patch would be even better with a sentence or tw oabout what the urls are for07:45
lifelessAfC: and in general you *don't have one*07:45
AfCSo we had a big fight about this 6-8 months ago. I was on the side of "bundle is good" for numerous reasons, but07:45
AfCthe one that remains a big factor for me is that I am really tired of people going to the trouble of sending emails with empty bundles in them07:46
lifelessAfC: irrespective of command used. 'bzr bundle ../mainline' is fine.07:46
lifeless'bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline' is wrong07:46
AfCby forcing them to glance at the file they _really_ review the diff they are proposing, and it avoids the "you didn't actually specify what branch you're comparing to" problem07:46
lifelessbecause the branch being submitted is *not* bzr://research.operationaldynamics.com/bzr/java-gnome/mainline07:46
lifelessif you want to force them to look at it, try 'bzr send ../mainline -o /tmp/name-the-patch.patch'07:47
lifelesspersonally, I use 'bzr diff -r submit:' to preview a submissiom07:47
AfCNot to mention using stdout is good™07:48
* spiv uses "bzr cdiff -r submit: | less -R"07:48
lifelessbzr send -o- does that07:48
AfCWell, until you remove it from bzr, we'll keep using it.07:48
lifelessI'm not really interested in a debate about send vs bundle right now. I have a patch to finish. Helping you debug your docs is something I'm happy to do.07:49
AfCspiv: you're assuming that they have any clue what -r submit: is and why they should use it. That's a pretty advanced topic.07:49
AfClifeless: I'm just explaining why it is that we're using bundle, since you noted it.07:49
lifelessAfC: fair enough07:50
spivAfC: I'm not suggesting that you recommend it, just mentioning what I use in case it's of interest.07:50
spivI'm willing to trust you know more about your community than I do :)07:50
AfCIt doesn't really strike me as the sort of thing to suggest to people when I'm busy trying to encourage them to tolerate my using Bazaar at all in the first place. The whole repository setup malarkey is bad enoug.07:51
poolieafc, so if the core issue is that people should read their diff before sending it07:54
AfCpoolie: indeed07:55
pooliethat sounds like a pretty reasonable thing, and orthogonal to internal concerns about bundle vs send07:55
lifelesspoolie: I've sent the bug-activity mail off07:55
pooliein the way i use send, i see the diff in the editor asking me for a description07:55
pooliehowever i think this won't happen if you're using an external mail client07:55
lifelessAfC: anyhow, my key point is that for someone that hasn't published their branch using the two-parameter form of bundle is *always* wrong07:56
lifelessAfC: and specifying a different branch as teh public branch is also always wrong/07:56
pooliewell, depending on the client it may or may not be able to open or see files attached to your draft07:56
lifelessAfC: it seems to be all your users will fail on both tests with the draft doco you pastebinned07:56
lifelessAfC: which is why I am saying use one-parameter form07:56
AfCpoolie: judging by the fact that I got empty bundles, I'd have to say that's the case07:58
pooliei would think we should not generate empty bundles without warning or forcing07:59
pooliebut, it is exactly that kind of case that i think robert and aaron are saying is problematic in bundle07:59
AfCpoolie: (it was send that was generating the empty merge requests)08:00
AfClifeless: so, transposing what you're saying, I should revert to telling people to do `bzr bundle ../mainline` or whatever and do $something different when I merge to avoid the problem that _I_ have no ../mainline for it to refer to (assuming I can duplicate that scenario and that it is indeed a problem)08:02
lifelessAfC: *and*, have them set the public url for their copy of mainline08:02
AfClifeless: Ok. One last question, then: how is that different than them inheriting public_branch from the internet hosted 'mainline' they branched from in the first place?08:04
AfClifeless: which you indicated would result in all branches thinking they were 'mainline' (a statement I find weighty though, I must admit, a bit strange given all branches are peers more or less)08:05
lifelessAfC: because it doesn't propogate when set in ~/.bazaar/locations.conf08:09
Odd_Blokethumper: Sure.  I'm around now, if you still are.08:10
fullermdWell, I'm pretty sure it doesn't propogate when set in branch.conf either.08:10
Odd_Bloke(Morning all.)08:10
poolieAfC: one useful way to move this forward if you get a chance might be:08:11
pooliewrite the doc that you wish was in the manual08:11
pooliedescribing the hypothetical command08:11
pooliethen we can work out how much of it is docs, how much is defaults, etc08:11
AfCfullermd: really? I thought that branch.conf _did_ propagate.08:12
AfCpoolie: I'll see about heading in that direction, sure.08:12
pooliespiv, lifeless: every assert deleted, yay08:25
pooliequite a few were bogus08:25
lifelessspiv: the versioned_files branch has the absent record type we discussed08:27
lifelessnight all08:27
spivlifeless: hooray08:28
spivpoolie: I must admit the patches I sent this morning add a few, but that should be easy to correct08:28
spivpoolie: (they also remove some, though)08:28
pooliespiv: naughty, smart.py already has too many :)08:51
pooliespiv, as penance you can read my diff :)08:51
poolienight from me too08:51
pooliewell done on sending yours08:51
poolie5000-line diff sent, i'm done08:51
spivpoolie: I wrote the offending asserts before your rfc :P08:53
spivGood night.08:53
poolieit's ok08:54
spivOoh, long weekend.  I almost forgot. :)08:57
igcnight spiv, poolie09:02
* igc dinner09:02
spivigc: g'night09:10
mathrickhow can I revert a pending merge, and only the merge (ie. without reverting the local changes)?10:46
mathrickit says that in the help page, never mind10:46
spivmathrick: :)10:50
awilkinsHow do you test a class instance to see what type it is?11:33
* awilkins has found isinstance11:36
awilkinsDo you just pass the class name to the second argument?11:41
awilkins(not as a string, as an identifier)11:41
mathrickuhh, how do I get a revno out of rev id and a branch?11:46
mathrick(I'd add that API docs are down again)11:46
james_wawilkins: I believe so, yes11:47
james_wmathrick: revid_to_revno_map, or something like that.11:48
mathrickah, I just found branch.revision_id_to_revno11:48
awilkinsjames_w: Hmm ; i'm trying to write "added" support into bzr ls (mostly for fun), and I've so far settled on checking whether a thing is a TreeEntry or an InventoryEntry as a test ; but it's probably not the best test in the world.11:49
awilkinsThe only other test I can think of is checking hasattr(entry, 'has_text') ; otherwise you'd have to extend the "Entry" hierarchy a bit11:55
james_wwhat are you trying to achieve?11:55
awilkinsbzr ls --added     emitting a list of added files11:56
james_wyes, but why are you trying to find if it is a TreeEntry or InventoryEntry?11:57
awilkinsjames_w: Because the entry is an InventoryEntry if it's in the inventory, but a TreeEntry if it's just been added11:57
james_wah, that doesn't sound like the right way to get the information11:58
james_wtree.changes_from(other_tree) is what I would reach for first.11:58
awilkinsjames_w: That would make the implementation of bzr ls a lot more complex, which is why I suspect this hasn't been done already11:59
awilkinsThe all comes out of me patching some hidden commands and submitting a merge for it...12:00
james_wit looks to me as though cmd_ls could use a refactoting12:00
james_wrefactoring, sorry12:00
james_wHaving all the logic in the command class isn't desirable to start with12:00
awilkinsSome kind of tree iterator with filter chaining that yields the data?12:02
james_wbut finding all this information isn't actually that easy with bzrlib currently.12:02
james_wthat could be alright12:02
james_wtree.changes_from should have what you need for ls,12:02
james_whowever there is an argument against having ls --added, as it is a state change thing, rather than a single state, and so is the domain of status.12:03
awilkinsWhich brings me full circle - I patched the hidden "added" and "modified" commands to be more consistent with "unknowns"12:04
awilkinsGah, I suppse patching "status" is actually what abentley recommended...12:06
* awilkins beats self12:06
awilkinsIs there a tertiary operator in python (  false ? truthing : falsething ) ?12:24
datoawilkins: only in python 2.512:25
dato(x = 1 if foo else 2)12:25
awilkinsOk, I'll avoid that then12:25
igcdato: I was ill a few days this week so I never did get to look at that bzr-fast-export issue12:37
igcdato: did you get a chance to look into it any more?12:37
datonop, sort of crazy busy here12:38
igcdato: np - I'll take a look next week12:38
MezIs there any reason I need to specifically "upgrade" a branch to use tags? (and do I lose anythign in doing so?)12:39
igcMez: some early branch formats didn't support tags12:39
igcunless you're using a special format (for bzr-svn say), should should'nt lose anything12:40
Mezigc, I understand that, however, do I lose anything from upgradeing from dirstate to dirstate-tags12:40
igcit should be fine12:40
MezRepository branch (format: dirstate or knit)  = what it's showing for the remote branch12:41
Mezis that correct?12:41
igcMez: do you control the format of the remote branch?12:42
MezI hope so ;)12:42
Mezit's a bound branch, shouldn't it be updated automatically?12:43
igcMez: good. In that case, you should seriously consider upgrading to pack-0.92 instead of dirstate-tags12:43
Mezigc, why?12:43
igcpack-0.92 performs better and is more space efficient12:43
igcit's the current default12:44
igcit supports tags as well12:44
Mezhmm - I'm on 0.9.012:44
Mezhmm - I'm on 0.90.0 *12:44
igcMez: you'd need to upgrade bzr in that case as well :-)12:44
Mezigc - indeed...12:45
* Mez waits for hardy12:45
igcthere's a 1.4rc2 currently out - 1.3.1 is the latest production release12:45
igcMez: 1.3.1 is in hardy to my knowledge12:46
Mez0.90.0 is in gutsy12:46
Mezhow do I make the tags push to the bound branch?12:47
igcMez: not sure sorry. Did you try 'bzr push branch-url'?12:49
james_wMez: I think it will happen on your next commit12:50
=== mrevell is now known as mrevell-lunch
Mezah, push works, but looks like a fail12:50
Mezigc, if a local branch and a remote branch don't have the same format, they'll still work together?13:03
igcMez: I believe so13:04
Mezigc, cool - I expected errors ;)13:04
igcoperations can be quicker though if the formats match because less conversion of data is required13:04
Mezyeah, can undersand that13:05
MezI just expected it to throw an error, or upgrade the local branch or something13:05
Mezgotta get my other devs to re-checkout the branch (or upgrade it)13:05
awilkinsMez: Not all branches are compatible13:20
awilkinsMez: particularly branches that use rich roots13:20
igcnight all13:42
beunosleep well igc   :)13:43
igcthanks beuno - public holiday here tomorrow so I'll see you next week13:43
igcand while I'm off topic - here's to hardy! The bird has now escaped it seems :-)13:44
beunoheh, I've already got the ISOs on my servers13:44
beunoI grabbed them before the server bashing started  :)13:45
=== mw|out is now known as mw
abentleyspiv: Has this merge request http://bundlebuggy.aaronbentley.com/request/%3C20080220122210.GA29155@steerpike.home.puzzling.org%3E been superseded?14:10
spivabentley: no, in fact I meant to land it today14:10
abentleyOh, I thought it might be part of your patchbombing.14:11
spivNo, the patchbombing was just code.14:12
=== mrevell-lunch is now known as mrevell
=== bigdo4 is now known as bigdog
hnoA bit of panic here.. suddenly bzr says "bzr: ERROR: Unknown record type: '\r'" on pretty much any operation to the repository.15:35
Odd_Blokehno: Could you look in ~/.bzr.log for the relevant error message?15:41
hnoOdd_Bloke: Only a long python backtrace..15:42
Odd_Blokehno: Could you pastebin that backtrace somewhere, please?15:44
hnothe repository is at http://www.squid-cache.org/bzr/squid3/trunk15:44
hnothe log is from a "bzr update" of a local checkout using file:///bzr/squid3/trunk as source. But same error is seen if I try to make a fresh checkout remotely over http.15:46
Odd_Blokehno: What version of bzr are you using?15:47
hnoServer is Bazaar (bzr) 1.3. The remote client is 1.3.1rc115:48
Odd_Blokehno: When in the process to you get the error?15:51
hnoOdd_Bloke: On checkout it sets up the .bzr directory and control files (including last-revision) but no sources..15:52
hnoOdd_Bloke: not sure if that answers your question. Not sure how to tell "when".15:54
Odd_BlokeYeah, I'm not really sure what I was looking for in an answer. :p15:55
Odd_BlokeI'm not sure what's going on.15:56
hnoMy local mirror repository seems unaffected..15:58
* Odd_Bloke is trying to reproduce.15:58
hnobut I don't have all branches..15:59
Odd_BlokeI'll leave that running and BBIAB.16:00
hnoIt's seen farily quick if using bzr co --lightweight.16:03
=== pygi is now known as pygi|away
hnoHmm.. some process has also gone very wrong and set last-revision of one of the branches equal to trunk...16:13
hnoArgh.. out of time. Have to go. If you figure something out please mail henrik@henriknordstrom.net. I'll continue looking at this later tonight.16:15
=== mtaylor|zzz is now known as mtaylor
=== kiko-afk is now known as kiko
awilkinsAnyone else order a WiiFit?17:20
pekujanope, I've got mass to conserve17:21
korpiosawilkins: I've got a metal DDR pad :p17:24
korpios(I wish I could play more ... moved into a 2nd floor apartment)17:24
ubotuNew bug: #221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,New] https://launchpad.net/bugs/22141417:35
fbondIs there a way to rename threads?17:50
fbondIn looms...17:50
NfNitLoopoh.  Sorry, over my head. : )17:51
fbondNfNitLoop: no problem17:51
NfNitLoopI was thinking a thread of execution.17:51
NfNitLoopand was a bit confused.  )17:51
abentleyfbond: No, not really.17:51
abentleyYou can create a new thread with the desired name.17:52
abentleyAnd then combine-thread the other one.17:52
fbondSo create-thread, up-thread, merge -r thread:foo, combine-thread?17:59
jamfbond: just don't try to use 'bzr nick XXX' as it will break your loom :)17:59
fbondfbond: Already tried that :)17:59
jam(you can get back if you 'bzr nick OLD_NAME' though)17:59
fbondjam: Didn't seem to totally break things.17:59
jammaybe they fixed that18:00
jamwhen I did it, it would crash on every operation at 'unlock()' time18:00
fbondjam: Yeah, I think some operation I did following that fixed things.18:00
fbondabentley: Or, rather, create-thread bar, merge -r thread:foo, combine-thread should do it?18:01
abentleyfbond: bzr switch OLD_NAME; bzr create-thread NEW_NAME; bzr down-thread; bzr combine-thread18:02
abentleyjam: Not fixed yet, AFAIK18:03
fbondabentley: right, thanks18:03
* NfNitLoop reads up on looms.18:10
NfNitLoopHmm, that's cool.18:10
jamabentley: doing a 'bzr up' seems to have the same "assume the nick is in the thread dictionary" so it sounds like you are right.18:11
jamI'm curious what "bzr nick 'name of another thread'" would do18:11
awilkinsjelmer: I have a couple of merges languising in the bzr-gtk limbo, are you the list admin?18:11
jamI suppose it would be similar to a switch, just without all the merging18:11
abentleyjam: Well, the main thing it would need to do would be to rename the thread entry.18:12
jamabentley: I'm saying that right now 'bzr nick other_thread' will implicitly jump you to that thread and record your state there.18:13
jamIt probably *should* just rename the current thread, and fail if there is a name conflict.18:13
abentleyAgreed to both.18:13
=== cpro1 is now known as cprov
ubotuNew bug: #221461 in bzr "'bzr push --quiet sftp://host.com' is too chatty" [Undecided,New] https://launchpad.net/bugs/22146119:46
ubotuNew bug: #221465 in bzr "'bzr push sftp://host.com' does not use authentication.conf password setting" [Undecided,New] https://launchpad.net/bugs/22146519:55
=== pygi|away is now known as pygi
=== mw is now known as mw|food
jelmerawilkins: yes20:46
jelmerawilkins: one sec, I'll see if I can find the password..20:46
=== mw|food is now known as mw
Necorohmm ... is something like "bzr branch lp:portato lp:~necoro/portato/cache" supposed to work?21:44
Necorohmm ... it works somehow but is reeeeeeally slooow21:45
fullermdI'd expect so.21:48
NecoroI aborted it ... it hang showing nothing ;)21:50
fullermdWell, transferring bunches of data twice is kinda slow   :p21:51
trepcais shared repository meant for different branches of the same project or can it contain branches for different projects too ?21:53
abentleyThe smart server in general is slow on Launchpad today, because it shares a resource with servers affected by Hardy traffic.21:54
abentleyThe good news is that we've got a replacement good to go for our next release.21:55
Necoroabentley: launchpad is generally not the fastest server ;)21:55
fullermdWell, the SS doesn't support server-side branches like that anyway, does it?21:55
fullermdSo you're still stuck with copy-all-down, copy-all-up21:56
abentleyfullermd: No, it doesn't.  I mention ss because he said lp:foo21:56
abentleytrepca: It's fine to use it for different projects, but repositories do get slower the bigger they are.21:57
jamabentley: yeah, lool on #bzrlp was mentioning that bzr+ssh:// bazaar.launchpad is really slow today22:41
jamI know he was wondering why the resources weren't more separate22:41
jamI was also guessing it was a Hardy-release-day thing, but couldn't answer why the smart host shares resources with a download server22:42
* awilkins downloaded Hardy via a torrent, it wasn't his fault23:41
elmojam: it doesn't23:42
elmoLP is on a completely separate link23:42
elmoif it uses the authserver on the otherhand..23:42
jamelmo: well, that would effect the connect time, but I wouldn't expect it to effect every operation once connected23:44
elmojam: well the LP link had no bandwidth problems today due to the release, trust me23:45
jamelmo: it seemed to be more CPU resources than bandwidth23:46
jamunless it was horribly bandwidth constrained23:46
jam(100s for 70KB)23:46
elmoerr, well, yeah - the bzr LP server doesn't share CPU (modulo authserver contention with wiki.u.c) or bandwidth  resources in any way that would make it be affected by today's release23:47
jamI guess we've had "super slow" days in the past23:47
jamI've only seen "we know it is slow and are working on it" posts23:47
jamMaybe the same thing struck again23:47
jam(but stuff like X over 'bzr+ssh' being 250s and 20s over http)23:48
awilkinsjam: I found it much faster to branch a local project over file:// than bzr://23:50
awilkins"local" means "across a LAN"23:51
jamawilkins: for a *new* branch, 'http://' is faster than 'bzr+' at the moment23:52
jambut it isn't 12x faster23:52
=== mw is now known as mw|out
jam(that, and I was testing 'bzr log', which I haven't really compared, but it still shouldn't be *that* different)23:55

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