awilkins[PUPPETS]Gonzo: Are you awake, Guillermo?00:12
=== mw is now known as mw|out
spivabentley: because there's no bzrdir_implementations test for it, I guess.00:31
abentleyspiv: I misspoke, RemoteRepository, not RemoteBzrDir00:32
abentleyIt looked very much like you had decided that it should not be implemented.00:33
abentleyIf I'm mistaken, I'll gladly implement it.00:33
spivabentley: hmm00:34
spivabentley: well, currently the smart protocol doesn't have any verbs to talk about working trees00:35
spivabentley: so it might have been intentional.00:35
abentleyWe need it to properly implement clone_on_transport, so I can do the VFS fallback thing for now.00:36
spivabentley: ideally, I would like for it to be the case that a push over the smart protocol would cause the server to update a working tree on the remote side if there's one there.00:36
lifelessspiv: I think thats a problem because of conflicts00:37
spivlifeless: yeah, it's definitely not a trivial problem00:38
spivlifeless: I also don't think it's a particularly important problem.00:39
spivlifeless: so don't worry, there's not too much risk of me doing anything about it anytime soon :)00:40
abentleyspiv: Not creating working trees remotely is handled in other ways, so there's no need to disable set_make_workingtrees00:41
spivabentley: incidently, there's no direct repository_implementations test for set_make_working_trees.  It probably gets exercised by test_clone_shared_no_tree, depending on if test bails out early or not... if you want to add a simple direct test for set_make_working_trees (and make_working_trees), that would be good.00:43
spivabentley: sounds reasonable to me00:43
abentleyOkay, I'm happy to do that, and it will make my repository acquisition policy patch nicer.00:44
abentleylifeless: I'm wondering whether we should be adding a scenario to the bzrdir implementation tests: bzrdir with non-default repo, tree and branch.00:47
abentleyI had a test for clone_on_transport that was creating a repo in the default format, not the bzrdir format.00:48
abentleyI'm manually forcing that test to run with "knit".00:48
lifelessabentley: so a scenario which runs all the bzrdir tests hoping to catch things that make outputs be default rather than the source format ?00:52
poolielifeless: considering the two recent bugs with tzdata and python-xml00:52
poolieboth could not be reproduced with upgrades, but were likely caused by them00:52
spivabentley: so you're going to remove the special casing for Remote* in that patch, then?00:52
abentleyspiv: Yes.00:53
pooliei wonder if some better database could keep track of every package they ever published00:53
spivabentley: ok, good.  I don't need to complain about your use of "from remote import ..." then ;)00:53
lifelessabentley: I think that has some value00:53
abentleyspiv: Why do I always do that?00:54
lifelesspoolie: yes, there are such things :P00:55
lifelesspoolie: archive, my conflict finder, etc00:55
=== mwhudson__ is now known as mwhudson
lifelessyay mass api changes landed01:08
ubotuNew bug: #214878 in bzr "Crash when trying to push to a remote directory (FTP)" [Undecided,New] https://launchpad.net/bugs/21487801:15
mwhudsonhm, i guess now would be a good time to fix how loggerhead does annotate01:16
mwhudson(it calls annotate_iter currently)01:16
mwhudsonso many things to do01:17
=== hexmode` is now known as hexmode
markhlifeless: did you get a chance to look at the new rev of that doc?01:49
lifelessmarkh: yes, I approved on bb01:51
markhit addresses the concerns you had re the tone?01:53
lamontare bzr 1.3.1 bits (release) packaged anywhere?02:04
=== poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.4 bug day today! - help us report, triage, fix and review...
poolieand gutsy-backports i believe02:19
lifelessI have a task for someone02:23
lifelesstry freeze on bzr02:23
poolieoh, python freeze, to turn it into a binary?02:24
poolielifeless: quick call?02:24
ubotuNew bug: #214894 in bzr "AssertionError when pushing to remote bzr+ssh repository (len(history) != revno)" [Undecided,New] https://launchpad.net/bugs/21489402:51
lifelessfbond: ping02:56
pooliecommenting on bug 209281 patch03:19
ubotuLaunchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,Invalid] https://launchpad.net/bugs/20928103:19
=== BasicMac is now known as BasicOSX
* poolie looking at "plugins in arch-indep directory"03:24
fbondlifeless: hi03:25
lifelessfbond: re looms and rebasing03:26
lifelessfbond: why do you want to break collaboration?03:27
poolieok, already merged03:27
fbondlifeless: well, I wasn't collaborating at the time :)03:27
fbondlifeless: frankly, quilt isn't a collaboration tool, so if I'm using looms as a better quilt, I don't care much about collaboration.03:28
lifelessfbond: right, I realise quilt isn't a collaboration tool... one of things about looms that make it a better quilt is the collaboration aspects :P03:28
* poolie reads command-not-found core03:28
lifelesspoolie: perhaps a #bzr-bug-day channel?03:29
fbondlifeless: Okay, my understanding of the impact of rebasing is probably limited.03:29
lifelessfbond: that said, I'd like to understand why you want to rebase rather than have the changes merged up (we can put equivalent automation in both approaches)03:29
poolieis this too noisy?03:30
lifelesspoolie: its low signal03:30
pooliei'm trying not to overlap with spiv03:30
fbondWhat I want to do with looms is to manage a set of possibly dependent changesets and then pull them off, one at a time, as a single changeset that I can then merge, push, pull, etc.03:30
lifelesspoolie: well, as a journal I don't know that it will scale. I suggest gobby if you want to avoid overlap and scale with people doing this03:31
fbondWhat I don't like about the current behavior is that I end up getting changes mixed into higher threads that are really specific to a lower thread.03:31
lifelessfbond: so merges don't preclude that, in fact they allow you to handle more merge cases.03:31
fbondlifeless: It's certainly possible that I'm overlooking a feature that will do what I want.03:32
lifelessfbond: I don't understand what you mean by mixed in03:33
lifelessfbond: rebasing would have as much code commingling03:33
fbondHmm.  I really want a single commit per thread.03:33
lifelessand quilt has as much too; when you work as a stack.03:33
lifelessfbond: there is at any point in time a cherrypick merge that will drag out a single thread with nothing from other threads.03:34
lifelessfbond: 'bzr merge someloom -r thread:threadbelow..thead:feature'03:34
fbondlifeless: Okay, I think I see how that would work.03:35
pooliemerging make-dist and command-not-found core..03:35
lifelessfbond: if you happen to take threads from bottom to top, then cherrypicking is equivalent to just merging/pulling individual threads03:36
lifelessfbond: the bottom thread is typically the trunk03:36
pooliespiv: can you do the tweaks and submit your _get_line patch?03:36
fbondWhat I'm really after is to have a set of mutable commits, each of which represents a specific feature or fix.  I'd like them to remain mutable until I decide that feature/fix is complete, at which point I want to roll that commit into a "final" commit that I apply to trunk.03:37
jameshif anyone wants to approve and merge the post_change_branch_tip hook patch, it'd be appreciated :)03:37
pooliejamesh, it's near the top of my list03:37
fbondlifeless: It sounds like cherry-picking the "final" commits would do that.03:37
pooliehow much hope this gives you i can't say :)03:37
lifelessfbond: so, there are two basic ways to mutate a commit; you can either commit a change on top of it, or you can remove it from history and commit it fresh03:37
lifelessfbond: the former allows other developers (and yourself in dependent commits) too adjust to your mutations03:38
fbondlifeless: right, in the end I want a single commit with a single log message, though.03:38
fbondSo I guess I cherry pick the commits that make up that single commit and then `bzr revert --forget-merges'?03:38
lifelessfbond: the latter looks to the vcs system as two people doing slightly different things, except when special logic (rebase) is applied to avoid massive conflicts.03:38
fbondlifeless: yeah, I follow you.03:39
fbondlifeless: But I wouldn't be sharing my loom with others.03:39
lifelessfbond: the problem with rebase is that other people have to know exactly when you rebased to reproduce it exactly, but by the very nature of rebase they cannot know this.03:39
fbondlifeless: The loom would be a temporary tool for me to manipulate commits.03:39
lifelessfbond: doing a --forget-merges will in fact do what you want yes.03:39
fbondlifeless: yes, it would, at the cost of having to cherry pick multiple commits instead of rolling off a single commit...03:39
lifelessfbond: well you're not grabbing multiple commits; by forgettings merges you get a single commit03:40
fbondlifeless: I'm tempted in that case to bzr down-thread; bzr uncommit; [make changes]; bzr commit; bzr up-thread03:40
lifelessfbond: if you do that, bzr will still give you a merge :P03:40
fbondlifeless: yes, forgetting merges ends up with the same result, but I have to manually track which commits actually "belong" with that thread, and which are (sort of) incidental commits that result from merging mutations to lower threads.03:41
fbondlifeless: Am I making sense?03:41
lifelessfbond: no, because the recipe I gave you before lets bzr track that for you03:41
fbondlifeless: let me re-read that03:41
fbondlifeless: bzr must be smarter than I was thinking; let me make sure I understand:03:43
lifelessfbond: anyhow, meta discussion - I would like looms to work well for you and will happily make changes *that don't preclude its use a collaboration tool* to do that.03:43
fbondlifeless: The cherry pick would merge those "incidental" commits, but --forget-merges would drop them and I'd be left with a diff that represents my intent.  Right?03:43
fbondlifeless: Okay, I can be happy with that.03:44
fbondlifeless: I have a tendency to want history to represent my intent, rather than representing what I actually did.03:44
lifelessif you'd like to write up some docs for the HOWTO that describe what you want and why03:44
lifelessI'd be delighted to try and make this clear to other folk with the same penchant.03:44
fbondlifeless: Yeah, I think that would be a good idea.  I feel that this work-flow must not be that uncommon.03:45
fbondlifeless: I'll write something up.03:45
fbondlifeless: and thank you, too.03:46
fbondlifeless: I'd like to try this out a bit before writing anything, so it'll probably be a few days.03:46
fbondlifeless: Where should I submit a document, the wiki, or elsewhere?03:47
lifelessthe bug report about this would be good03:50
ubotuLaunchpad bug 214657 in bzr-loom "Should support rebasing threads" [Undecided,New]03:51
fbondlifeless: okay, you got it03:51
poolielifeless: so that description actually corresponds to MissingFeature i think (like 'you should install paramiko')03:51
lifelesspoolie: ECONTEXT03:51
poolieand UnavailableFeature means an unavoidable platform problem?03:51
pooliere the warning about windows diff apps03:53
lifelesswe currently differentiate between skipped, unavailable, known failure03:55
* TFKyle wonders why people would use bzr in cygwin, just for symlink support?03:55
pooliei will try to update the doc to reality03:56
lifelesswell they might be using cygwin anyway03:56
fbondTFKyle: Some people like shell wildcard expansion to work (and other shell features, too).03:57
TFKylefbond: hmm, couldn't they still just use a normal windows Python+bzr on there?03:58
fbondTFKyle: Oh, dunno, don't use any of the above.03:59
abentleyspiv: Other methods, when invoked on formats that don't support them, raise UpgradeRequired.  Would that be suitable for you?04:03
spivabentley: Hmm, the message on UpgradeRequired says "branch" rather than "repository", but apart from that it seems ok.04:05
abentleyOkay, class RepositoryUpgradeRequired(UgradeRequired)04:05
spivI don't understand why that's better than NotImplementedError, though.04:07
abentleyspiv: It's better because the semantics are unambiguous.04:07
spivI'm also not sure that it's tasteful to have set_make_working_tree succeed if the new_value happens to match what the repository is hard-coded to do, and raise otherwise.04:08
abentleyWe use NotImplementedError for things that *must* be implemented, like Tree.get_file.04:08
spivIt seems like that will lead to callers getting surprised later rather than sooner.04:09
abentleyOkay, I can raise it all the time.04:09
spivWell, we also use it for leave_lock_in_place04:09
spiv(for instance)04:10
abentleySo if Tree.get_file raises NotImplementedError, that means "implementor was drunk", but if Repository.set_make_working_trees raises NotImplementedError, that means "implementor made a rational choice not to implement it"?04:11
spivWell, it means "this object doesn't implement that"04:11
spivHow you assign blame from there seems to be out-of-scope ;)04:11
spivI don't mind we decide that we should have distinct exceptions for those cases, but we don't seem to at the moment.04:12
spiv(Otherwise I'd expect us to already have a RepositoryUpgradeRequired defined...)04:12
abentleyTest suites need to distinguish between these cases.04:13
spivAnyway, I don't feel strongly about how this should be done.04:13
spivSo if it does make your testing easier, please do add the exception!04:15
spivI see that Robert on the list shares my impression about the meaning of NotImplementedError04:16
spivSo clearly there's a HACKING guideline waiting to be written, one way or the other :)04:16
lifelessabentley: *optional* methods use NotImplementedError today, and the test suite looks for that.04:20
lifelessabentley: get_file is not an optional method04:20
abentleyIt sounded like you were saying "iff a method is optional, it raises NotImplementedError if not implemented"04:21
lifelessabentley: yes, I misread your line beginning 'So if'04:22
lifelessabentley: your line was correct04:22
lifelessin this particular case I don't think RepositoryUpgradeRequired is appropriate, because we might in future have repositories that don't support this method04:23
lifeless(see the discussion about 'repositories are not semantic')04:23
abentleySo get_file raises it, and therefore we don't have clear semantics for NotImplementedError.04:23
lifelesswe do have clear semantics: that method isn't available on that object04:23
abentleyYou said it meant the method was optional.04:24
abentleyWe don't have clear semantics about whether the method is optional.04:24
lifelessNo, I said on optional methods we use NotImplementedError when it has not been implemented.04:24
lifelessNotImplementedError always means 'not implemented'04:24
abentleyFine.  The semantics we have are not rich enough for me.04:25
lifelesswhat problem is it causing04:25
abentleyI'm getting test failures.04:25
lifelessas in, is it a testing problem or a client code problem04:26
abentleyI have code that exercises set_make_working_trees, and it fails if NotImplementedError is raised.04:26
abentleyI don't want it to be unimplemented except on very old formats.04:27
abentleyBecause clone_on_transport is supposed to create an exact copy, and it can't do that if it can't set that setting.04:28
lifelessabentley: given the current API your code should catch NotImplementedError04:29
lifelessabentley: we do this elsewhere in the test suite when testing optional methods.04:29
lifelessabentley: will that do the job for you ?04:29
abentleyNo.  Then I don't have a test that it's implemented on RemoteRepository.04:29
lifelessinterface tests are not the right place for such a test04:29
lifelessbzrlib/tests/test_remote.py is where such a test should live.04:30
lifelesssuch a test can test that the method doesn't raise and let the interface tests test the precise behaviour04:30
abentleyYou know what, screw this.  Spiv approved my plan.  I'm going to submit it to PQM.  If you think it should be changed, change it.04:30
lifelesswhere did that come from04:31
abentleyThat comes from your word games and from acting like your opinion is the only valid one.  Last I checked, poolie was in charge of this project, not you.04:33
lifelessI didn't know I was playing word games; and I don't see what 'whose in charge' has to do with this - our code gateway is geared around getting enough approval from mature devs, not any one person oking or not oking each patch04:39
lifelessbut you're obviously upset, and I'm feeling got at with the word games ad hominen04:39
abentleylifeless: "who's in charge" has to do with flatly stating that X is wrong and Y is right, despite the fact that other people clearly feel otherwise.04:47
abentleylifeless: "Word games" has to do with our argument about whether NotImplementedError had rich enough semantics for our use case.04:49
abentleySubmitting to PQM has to do with the fact that I have a tweak vote from a mature dev and no vetoes.04:50
lifelessabentley: I have replied to your playing with stacked branches mail as promised. basically I agree with everything you raised.04:51
lifelessabentley: In the prior conversation I was making statements about what is present in the code base, I don't think opinion has anything to do with that. I wasn't trying to argue with you about N.I.E., I was trying to work through it to grok the issue you had.04:52
lifelessand of couse sending to PQM is fine; as you say - you have enough votes and no vetos. I was purely suprised by the sudden vitriol.04:53
abentleyFrom my perspective, your patches are sailing past, while the things I try to do are blocked or delayed, primarily by you.  There has been some tension building.04:58
lifelessI know three I've caused grief of arious sorts on05:00
lifelessthe rich-root format meta-topic05:00
lifeless(mind you, I have patches I haven't sent in because they made you unhappy; I think that that one is quite mutual)05:00
lifelessthe fast-build-tree using Storage05:01
lifelessand Storage05:01
lifelesswe had a long discussion about Storage, and I ended up ok with the goal, but not beinging another concept without cleaning up what we had first, because we have been building a very long tail of uncleaned up things05:02
abentleyAnd MPRepo05:02
lifelessthat one I thought john was working on05:02
abentleyMPRepo was the one I did around Xmas, before trying again with Storage.05:04
lifelessyes, using multiparent diffs05:04
abentleyAlso, the other weekend when you suddenly said reconcile should change SHA1s.  That derailed my plans to implement pack1.4 that weekend.05:07
lifelessabentley: well, I was offering that to avoid 'pull' in general doing magic. I certainly didn't intend it to derail you.05:11
lifelessI've reviewed TransportConfig05:12
lifeless:tweak on it, just could be cleared in the class docstring05:12
abentleyWell, it did, because rewriting SHA1s was was I was trying to avoid.05:12
abentleyAnd there would have been no point to doing pack1.4.05:13
lifelessthe problem is we have stuffed sha1s today. I'd like to say all existing upgraded rich-root/subtrees repositories are just broken, but that seems overly harsh to our users.05:13
lifelessanyhow; this is a good point for my day to end05:15
abentleyBut what are those sha1's good for anyway?  We already have sha1s of all the repository contents, so we can do file integrity checks.05:15
lifelesswe can't detect bit errors or deliberate corruption in the inventory without them.05:16
abentleyWe can't detect deliberate corruption anyway-- they can just rewrite the revision.05:16
lifelessI'm off. I do *not* want to be a blocker for stuff you are doing; OTOH I am not going to avoid commenting when I think there is something we can improve on, or which we need to do differently.05:17
lifelessif you want to talk later about the tension; try and defuse it or find something I can do differently that will be less disruptive for you, I'd be happy to do that when I'm not about to halt() from low blood sugar05:18
abentleylifeless: I am still willing to try.  Lately I have felt like we had lost the ability to work together, which saddens me, because you've been part of my open-source contributions from the very beginning.05:30
mwhudsonhow do i unloomify a branch?05:55
spivmwhudson: you fix https://bugs.edge.launchpad.net/bzr-loom/+bug/203285 :(05:57
ubotuLaunchpad bug 203285 in bzr-loom "unable to "de-loom" a branch" [Medium,Triaged]05:57
mwhudsonspiv: oh great05:58
spivOr more helpfully, you pull the relevant revision into a non-loom branch, and then replace the loom with that branch.05:58
jmlmwhudson: what I do is: move to the top thread, bzr init a new branch, pull in the loom05:59
jmlmwhudson: maybe that's over complex05:59
abentleyYou can also do bzr export-loom to export all threads as branches.05:59
jameshbundlebuggy seems to have died06:04
jmlabentley: I'm trying to think of a use case for a branch to say "refuse to stack on me"06:32
abentleyjamesh: Should be back.06:33
jmlabentley: I can't think of one that's interesting.06:34
abentleyjml: If a branch has been stacked on, then it must not be deleted.06:34
abentleyBut if anyone can stack on anyone else's branch, then deleting a branch might break someone.06:35
jmlabentley: so, I guess if someone has published a branch that they know will be deleted in future...06:35
abentleyYes, or else if they just don't want to worry about whether it's safe to delete their branch.06:36
jmlabentley: maybe it's better to do it the other way around. explicitly say that a branch is ok for stacking06:36
abentleyjml: We may want to take that approach.  But it implies that no existing branches would be stackable.06:37
jmlabentley: but if there's a simple way to say 'this branch is now ok to be used as a base for stacking', then I think that's ok.06:38
abentleyWell, it might not be too bad to add that to existing formats.06:39
jmlabentley: I just can't see myself saying "don't stack on this branch".06:39
abentleyGenerally we would take the approach of creating a new format.06:39
jmlI was being blissfully ignorant of the implementation :)06:40
abentleyjml: lucky you.06:40
jmlit's a user's prerogative :)06:40
abentleyBut if we create a new format, then users with old clients will be affected...06:40
jmloh wait, free software06:40
* jml submits a patch or something.06:41
abentleySo you can see that the knock-on effect is pretty severe.06:41
abentleyI think I could live with adding an "allow-stacking" flag to current formats.06:42
abentleyThough of course it will be required for the actually stacked branches.06:42
jmlabentley: more broadly, if I have a branch that I don't want people to stack on, I'll make that clear-ish in its name (e.g. mumak.net/experimental/some-branch)06:44
jmllifeless: does addCleanup have tests?08:00
* mwhudson works himself into further confusion with looms08:05
spivjml: I don't see any in test_selftest08:08
spivjml: which is where they ought to be08:08
jmlspiv: grep didn't illuminate anything.08:08
spivProbably not, then.08:08
mwhudsonif i type 'bzr down-thread' and then decide i didn't want to do that, what should i do?08:09
jmlbzr switch, I think08:12
jmlI might be horribly wrong though08:12
mwhudsoni think it's too late for this loom08:13
AfCWhat's the current "best" repository format to use with bzr-svn?08:20
AfCReason I'm asking is that I am attempting to update my bzr-svn created GTK checkout, but I realized that when it was created (circa bzr 1.3 and bzr-svn 0.4.7) it was in a knits repo. `bzr update` failed (!),08:21
AfCso I've tried doing the incremental pull trick into a new repo of format --rich-root-packs08:21
AfCIt is taking 32 minutes per 250 revisions, local disk! This is somewhat astonishing, so I figure I must be doing something horribly wrong.08:22
AfC[There is a vcs discussion on a GNOME list this week, and I wanted to be able to report hosting of a few branches]08:22
spivrich-root-pack is the best repository format.08:27
spivConverting between repository formats can be pretty slow, it's not a code path we've done a lot of optimisation on.08:28
spivEspecially if it's between formats with different inventory serialisation, that tends to be very slow.08:29
AfCspiv: thanks.08:34
AfCspiv: do you think it would be faster to import from Subversion directly rather than trying to convert between repository formats?08:34
AfC[re]import; the last one took nine days but this time I have it running on a server in `screen` so it ought to be a bit faster :)08:35
AfCspiv: (not expecting you to "know"; just curious what your gut feel would be)08:35
spivAfC: Hmm, tough call :)08:37
spivAfC: With bzr-svn 0.4.9, I'd expect re-importing from scratch to at least be competitive.  I wouldn't want to take a bet about which will be faster, though :)08:38
spivpoolie: finally sent that _get_line patch to PQm08:40
lifelessabentley: I am willing to try too; perhaps tomorrow, but lets try08:42
lifelessjml: don't think so; blame poolie :P08:42
lifelessmwhudson: down-thread is ~= switch, so you can just switch again; or do up-thread08:42
mwhudsonlifeless: i got conflicts on down-thread and more when i up-thread-ed again08:43
lifelessmwhudson: so to get conflicts on down-thread you must have had outstanding uncommitted changes08:44
lifelessmwhudson: these get preserved (deliberately)08:44
* mwhudson off08:44
mwhudsonlifeless: yes, i wanted to commit them to a lower thread08:44
lifelessif you don't resolve conflicts before switching again, you are in for a world of pain; I think switch and X-thread should refuse to operate while there are unresolved conflicts08:44
lifelessoop, thing has finished, bye again :P08:45
mwhudsonlifeless: ok, but that means there's no "oh crap, i didn't mean to type that" option08:45
* mwhudson is gone too08:45
lifelessmwhudson: propose a better answer then :P08:45
spivYeah, in an ideal world "bzr down-thread; *oops, conflicts, I don't want to do that!*; bzr up-thread" would be a no-op.08:46
spivI don't want to be the poor guy that implements it, though ;)08:46
spiv(Assuming in this case that there's nothing outstanding in the lower thread to merge back up)08:47
spiv(Although I occasionally wonder if a "bzr up-thread --dont-merge" option would be a good idea)08:47
pooliespiv: well done09:04
pooliespiv: thanks for all the reviews and merges!09:04
nexus10hi - anyone know where I might find news of nautilus integration for bzr? or konqueror, if that's available?09:09
spivnexus10: the bzr-gtk plugin has a nautilus-integration component09:09
nexus10spiv: yeah, but I couldn't get it working, and from a recent irc chat log it seems others have the same problem09:10
spivnexus10: see the README file that comes with bzr-gtk for details of how to get it going09:10
nexus10spiv: I've tried, failed -- better try again then :-)09:11
spivnexus10: Hmm, it worked ok for me last time I tried.  I think it needs a fairly new Nautilus and python-nautilus bindings.  I use Hardy, and that seems new enough.09:11
spiv(I'm also using the current development branch of bzr-gtk rather than a release.  I don't know if that makes much difference)09:11
spivnexus10: there's a bzr-gtk mailing list, btw09:14
spivnexus10: if you're stuck, that would be a good place to ask for help09:14
nexus10spiv: thanks, I'm on Gentoo so I'll make sure nautilus is the latest stable, and try on the bzr-gtk ml if probs09:15
nexus10spiv: do you know if there's any integration with konqueror? Found one quote that suggested there is one, but can't find it...09:17
spivnexus10: I don't know, sorry09:17
spivnexus10: there's a "qbzr", I think09:17
spivnexus10: that may be related09:17
nexus10spiv: thanks, np -- yeah, qbzr is quite useful09:18
=== pmezard_ is now known as pmezard
spivI just posted a fix for #21342510:24
spivReviews and testing of that patch are welcome10:25
spivHappy bug day!10:25
* spiv gets some dinner10:25
pooliethanks spiv10:27
pooliebon apetite10:27
pooliegood night10:35
jelmerspiv: thanks for the bug report, should be fixed now10:35
quicksilver(graph of number of people installing debian packages of VCS systems)10:58
quicksilverbzr trailing behind but moving the right way. About to overtake darcs.10:59
jelmernice graphs :-)11:14
jelmerdoes ubuntu have anything like that?11:14
jelmerwow, bzr-svn seems to've lost 30 users by being uninstallable in sid for a week or so11:18
AfCbzr: ERROR: [Errno 12] Can't create tunnel: Cannot allocate memory12:07
AfC(with bzr-svn; but the next incremental pull succeeded)12:07
AfCspiv: BTW pulling with bzr-svn direct outpaces pulling from a Knit repo by 24 minutes to 32 minutes12:09
ubotuNew bug: #215059 in bzr "Cannot push if login is an e-mail address" [Undecided,New] https://launchpad.net/bugs/21505912:36
=== kiko is now known as kiko-afk
ubotuNew bug: #215063 in bzr "v1.3 fails badly when patch being applied twice" [Undecided,New] https://launchpad.net/bugs/21506312:45
=== mrevell is now known as mrevell-lunch
nir_I'm getting this error "bzr: warning: unknown encoding . Continuing with ascii encoding." on Mac OS X 10.5 with bzr 1.313:48
nir_my locale settings are: "LC_CTYPE="UTF-8""13:49
nir_Set by default on 10.513:49
spivAfC: thanks for letting me know which one won the race :)13:52
=== mw|out is now known as mw
AfCspiv: I think "won" might be overstating it a bit. It's only at 4800 of >15,000. {sigh}. And I keep getting13:56
AfCbzr: ERROR: [Errno 12] Can't create tunnel: Cannot allocate memory13:56
AfCHard to know what is to blame there, but that sort of thing is bad form.13:57
nir_Adding export LANG=en_US.UTF-8 to .profile fixed this error :-)14:01
=== mrevell-lunch is now known as mrevell
=== thekorn_ is now known as thekorn
ubotuNew bug: #215127 in bzr-push-and-update "Error running update on remote path containing a space" [Undecided,New] https://launchpad.net/bugs/21512714:51
edreamleoHello all15:36
edreamleoI just wanted to say 'thank you' for an absolutely superb tool.15:37
edreamleobzr has improved Leo's development effort in ways I never dreamed possible.15:37
edreamleoMore details at: http://groups.google.com/group/leo-editor/browse_thread/thread/4a0a72ad45d14fe015:38
spivedreamleo: Thanks!15:39
james_wedreamleo: that's great.15:40
edreamleoThe sound bite: bzr does for archiving what Python did for programming :-)15:43
edreamleoThat is, nothing is dangerous anymore, except possibly not making branches...15:44
=== weigon__ is now known as weigon
aantnbazaar.launchpad.net can't handle files with nonlatin characters16:20
aantne.g. http://bazaar.launchpad.net/~aantny/screenlets/universal-applets/files/aantny%40gmail.com-20080406154451-ihk6pxnwyxhwdurl?file_id=share-20070820102741-g2qhjaw8auklwqnv-3016:20
=== Mez is now known as Floodbot5
=== Floodbot5 is now known as Mez
b0efif you merge a branch and it creates some directory and you get a conflict and you then try to revert, it don't want to remove the directory and you have to manually remove it18:54
b0efwhat gives?18:54
=== kiko-afk is now known as kiko
abentleyb0ef: People have this strange tendency to complain when we delete their files, even if that's what revert technically should do.  So we try to accomodate them.19:06
b0efabentley: right, but why is there no bzr revert --force?19:07
abentleybecause force is very vague?19:07
abentleywe have --no-backups.19:08
b0efright, so that will do what I want?19:08
abentleyDunno.  If it doesn't, I'll be happy to fix it.19:08
b0efabentley: right, I'll get back to you, then;)19:09
ubotuNew bug: #215253 in bzr "bzr qannotate should allow to navigate from a diff to a revision" [Undecided,New] https://launchpad.net/bugs/21525319:10
b0efabentley: nope, doesn't work19:13
b0efabentley: I have to manually delete the directory19:13
b0efabentley: even with --no-backup19:13
abentleyOkay.  Please file a bug, and I'll take care of it.19:14
b0efabentley: aiight, thanks19:14
b0efabentley: seems 54172 pretty much describes it19:18
b0efabentley: still alive?19:27
ubotuNew bug: #215256 in qbzr "bzr qannotate: implement "search" and "search next"" [Undecided,New] https://launchpad.net/bugs/21525619:28
ubotuNew bug: #215258 in qbzr "qbzr: provide extensive help" [Undecided,New] https://launchpad.net/bugs/21525819:28
=== cprov is now known as cprov-out
blazerhello folks!20:01
blazerup until recently, we've been using bazaar succesfully in our game project, now we have a problem though... bzr push against as central "smart server" results in long waiting time with alot of data being received from the server >50MB.. is this normal?20:02
beunoblazer, what version of bzr are you using locally and on the server?20:03
abentleyblazer: Bazaar periodically auto-packs the repository to enhance performance.20:03
blazerwe're using 1.3 on both client and server20:03
abentleyIf your *next* push is fast, it was probably auto-pack.20:04
beunoabentley, couldn't we somehow report to the user that autopack is happening?  There seems to be quite a few users dropping in here because of it20:04
blazerit will transfer the whole repository then?20:04
abentleyblazer: Not necessarily the whole repository, but it could be a significant portion of it.20:05
blazeris there any documentation available on this behaviour? I might as well indulge in *something* interesting while waiting ^^20:06
coryI'm confused what's being transferred in that case.20:06
abentleybeuno: Sure, and it's already been suggested.20:06
abentleyBut no one has actually done it.  Which is a pity.  It would make a very small patch.20:06
beunoabentley, do you know if there is a bug open for it?20:07
=== mw is now known as mw|food
abentleybeuno: No, I don't.20:09
blazerapparently the server stopped sending at about 70MB of data and now the client is sending... I guess this is a good thing? ;)20:09
abentleycory: pack-format repositories create a new pack file on every commit.20:10
abentleyRetrieving those files one-by-one would be teremendously slow.20:10
coryabentley: Well, I've run into the same thing, and found that if I did the pack locally on the server and then went about my normal operations on the client, I didn't notice any long waits.  Is the client unnecessarily getting involved in the re-pack?20:11
abentleySo bazaar combines pack files when there are too many.  It does basically log scaling, so that 1 pack has 1 revision, the next has 10, the next has 100, etc.20:11
abentleycory: In some cases, perhaps.  With shared repositories, etc, the local repository may not have all the revisions in the remote repository.20:13
abentleyBut because of the log scaling, long auto-packs are rare anyhow.20:14
coryabentley: The local repository may not have all the revisions...what's the implication of that here?  Doesn't that mean that the server should always do its own packing independently of the client?20:17
abentleyThe implication is that it is sometimes necessary to download revisions from the server in order to perform the auto-pack.20:18
abentleySFTP servers and FTP server are not smart enough to perform an auto-pack.20:18
coryAppreciate your patients.  I'm just curious and trying to understand.  I've since simplified things, but at one point I had a gigantic shared repo, and it seemed to repack more often than I expected, which often ran me out of RAM on the client.20:18
corypatience, gah20:19
jelmerit does seem to autopack awfully often20:19
jelmeronce for every 10 revisions pushed or something20:19
coryCertainly understandable in the non-smart-server cases, sure.20:19
abentleycory: For the smart server, it would make loads of sense to auto-pack on the server.20:20
coryabentley: Ok, I was assuming that here.  Things make sense again, thanks.20:21
abentleyYou know how it is-- first make it work, then make it right, then make it fast.20:21
abentleyserver-side autopacking definitely a valuable optimization, but we're still getting into the "make it fast" stage.20:22
beunoabentley, I'll take a look at it to see if I understand what needs to be done, and open a bug for it if there isn't one already. Do you have the time/patience to help me with some bits if I get stuck?20:26
abentleybeuno: Sure20:27
beunoabentley, :)20:28
moquistpoolie: I just switched my .bash* and .vim files to be in a subdir, like you suggested. Much better idea. :)20:29
beunoabentley, I've got another thing I'd like to work on. It seems to me many new users tend to forget to do "bzr whoami" before starting to use bzr. I was thinking it might be a good idea to tell the user if they've not set it, the first time they run any bzr command, that they should. Do you think that's something reasonable?20:32
lifelessthe smart server should autopach already20:34
abentleybeuno: I'm mix about it, but I'd probably come down on your side.20:34
abentleylifeless: Oh, cool.20:34
beunoblazer, bug #215323  :)20:34
ubotuLaunchpad bug 215323 in bzr "The use should be notified that auto-packing is taking place" [Low,Confirmed] https://launchpad.net/bugs/21532320:34
beunolifeless, any opinions ^?20:35
lifelessif we fallback to self._real_repository too early that would prevent the smart server doing it though.20:35
lifelessbeuno: autopacking is potentially slow; at least on sftp you get a progress bar when it kicks in20:36
beunolifeless, cool, I'll work on it then. How about the notifying users *once* they don't have a "whoami" set?20:36
lifelessabentley: good morning; I haven't had coffee or food yet fwiw20:37
beunoI tend to forget myself when installing bzr from scratch, and end up committing a revisions gibberish author info20:37
abentleylifeless: morning20:38
lifelessyou know, I htink packs on the smart server will autopack over the wire with the current code20:38
lifelessbeuno: one way would be to require an explicit setting always20:38
beunomaybe just add a "Committing to /foo/bar as Author <email>"20:39
abentleybeuno: There's potentially a lotta output on an initial commit.  It's easy to miss.20:39
beunolifeless, you mean change it so that bzr requires you to set it before committing by default?  I actually don't dislike that...  (if it's what you meant)20:40
ubotuNew bug: #215323 in bzr "The use should be notified that auto-packing is taking place" [Low,Confirmed] https://launchpad.net/bugs/21532320:40
beunoabentley, right, it might help further down the road for people who use different emails for different projects, so you know for sure with what you are committing (I use different info for work then for open source)20:41
lifelessbeuno: yes, I did20:41
lifelessand I'm out of caffeine until shops open in a couple o fhours :(20:41
beunolifeless, cool. I like that even more  (thought it would be too intrusive to propose).  I'll file a bug and work on that one too  :)20:43
beunolifeless, sugar is a pretty good replacement for caffeine20:43
awmcclainI'm getting a traceback when using bzr annotate. :'(20:46
lifelessawmcclain: :(20:56
awmcclainlifeless: :''''''''(20:56
lifelessawmcclain: works for me20:58
lifelessawmcclain: './bzr annotate %' in my editor, current tree20:58
abentleyannotate also works for me.20:58
abentleyIt would help if you pasted the traceback.20:58
lifelessabentley: whats the current bundle format? I'm looking to see if I can make this new datastream integrate bundles too/or reuse bundles20:59
awmcclainSorry I didnt'get to taht sooner. :)20:59
blazernow the server seems to be autopacking again during a merge command.. why are we punished with this slowness on the day of the deadline? ^^21:00
abentleylifeless: Current format is 421:00
lifelesswhats 9 ?21:01
abentley0.9 ~= 321:02
lifelessblazer: if you are doing a great number of merges of new revisions, you'll could potentially be crossing the log borders more than once; that said, bzr autopacks *all* the time and it's not a problem21:02
lifelessabentley: ah, ok.21:02
lifelessblazer: look in ~/.bzr.log21:02
lifelessblazer: that will have some info21:02
blazerlifeless: on the server or client? the server one doesn't seem to contain much info21:04
blazerwhere would the logfile reside on a windows installation?21:05
lifelessbzr --version will tell you21:07
lifelessawmcclain: you have bzr 1.2; its known to work in 1.4.x21:08
lifelessawmcclain: are you able to upgrade to 1.3.1 or bzr.dev?21:08
lifelessabentley: bb is responding very slowly/not at all21:08
awmcclainAhh... I didn't know that we were at 1.4!21:09
blazerhmm.. I have alot of "not updating child fraction" in the logfile.. should I be worried about this? what is a child fraction?21:09
lifelessI'm tempted to say its irrational21:11
lifelessbut really, its just an overly verbose debug line21:11
blazerI see..21:11
blazerI'll have to dig into the sourcecode someday when I have time :)21:12
=== mw|food is now known as mw
jelmerlifeless: shouldn't it be a warning? I find it usually appears when there are progress bars that don;t make sense21:12
lifelessabentley: can I ask you some random things about v4 bundles as a shortcut to chasing code pointers?21:15
lifelessin add_fulltext_record, is parents the fully qualified names?21:16
lifelesse.g. (('file', filed, revision), ...)21:16
abentleySorry, dunno.21:20
lifelessI think its probably just the string revids21:20
lifelessadd_fulltext_record seems to be used for revisions and signatures only21:20
ubotuNew bug: #215350 in bzr-gtk "Viz revision menu "view changes" broken" [Undecided,New] https://launchpad.net/bugs/21535021:21
abentleylifeless: Yes, that would make sense.21:24
abentleyThe MPDiff format does snapshots as regular mpdiffs with 0 parents.21:24
lifelessabentley: so here is what I'm thinking; I don't know if it makes sense to do today or not21:25
lifeless(time is short)21:25
lifelessI'm generating a new stream for versioned files to eliminate join;21:25
lifelessa single record needs to be able to emit multiple items (for weaves); it needs to handle at least four record types - compressed knit delta, compressed knit ft, plain ft, weave.21:26
lifelessit seems a very small step to use fully qualified keys (type, id, revision) and allow mpdiff records too21:27
abentleyit needs to preserve those record types on the wire?21:27
lifelessthe initial code I need to write to elimiate join() doesn't have to specify serialization, only the object interface21:27
lifelessthats a good question; I don't really want to impose large recoding overheads that aren't needed21:28
lifelessits possible that we might make the wire protocol require a subset21:29
lifelessso the plain ft is there to avoid a gzip,ungzip cycle on deannotation/annotation21:30
abentleyWell, mpdiff does generate some overhead, though it's optimized for knit.  multiparent entries are recompressed, for example.21:30
abentleyi.e. knit deltas for revisions with multiple parents have comparison against their other parents done.21:31
lifelessthe weave is there so that if a server is sending from a weave repo it can just dump the weave (or a filtered list if someone cares to write one) into the stream as-is, which is much cheaper than the N extractions + N diffs otherwise needed21:32
lifelessabentley: mpdiff is optimised for size right?21:32
lifelessabentley: so I'm thinking of this as a lower layer than the different tradeoffs made by mpdiff vs knit vs annotated-knit vs weave21:32
lifelessI'll be quite happy to get rid of join; anything beyond that in code reuse or flexibility is a bonus21:33
abentleySo mpdiff support at this layer would be about harmonizing the bundle and repo interfaces?21:35
lifelessbundle repo and versionedfile21:36
abentleyit certainly sounds feasible to me.21:37
lifelessif we could in principle create a v5 bundle serialiser that can use the same stream as I've made (even tho I'm not doing the network implementation today, that will be in the near future)21:37
lifelessok, I'll write up a document describing what I think will work, I'd value you saying 'this appears to do what bundle serialisation needs' (even though I will be checking against the v4 serialiser code)21:38
abentleylifeless: I think converting from v4 would be trivial.  Am I missing something?21:38
lifelessI don't think you're missing anything21:38
abentleyI'm not parsing "if we could in principle create a v5 bundle serialiser...".21:38
lifelessbut I've not done much with bundle internals, and I'd rather have a safety net21:38
lifeless"is the concrete stream I come up with compatible with the needs of bundles"21:39
abentleyIt sounds like yes.  It wouldn't be hard to extend bundle format 4 to support different record types.21:40
abentleyThe one thing is weaves.21:40
abentleyBecause bundles do expect each record to correspond to one version, right now.21:41
lifelessso I'm thinking the programming interface to read a stream will be iterator of iterators21:41
lifelessunified keyspace21:41
abentleyCould you give me the example for a weave record vs a knit record?21:44
abentleyWould you get all the fulltexts out of the weave?  Is that what you mean by iterator of iterators?21:44
lifelessactually; scrub my last two lines21:44
lifelessI am explaining awfully.21:44
lifelessI'll be backin a second as well, nature calleth.21:45
lifelessI'm thinking of the stream as a sequence of records; each record can yield one or more repository entries (e.g. ('revision', revid))21:48
abentleySo would a knit record represent a single repository entry?21:49
lifelessthe reason for this two layered structure is to handle knit and pack repos nearly optimally in the knit->knit and pack->pack case by avoiding double-handling on the client and server21:50
lifelessa stream from a knit repository would be one stream record per knit versioned file, with the contents of that versioned file that are needed included21:51
lifelessa stream from a pack repository would be one stream record, with all the jumbled-up texts inventories etc included21:51
abentleySo the record would logically provide a set of unified-keyspace keys, though the byte representation could be optimized.21:53
lifelessone way of doing this would be to have a key prefix in the record21:53
lifelessnot sure if this is a good idea21:53
lifelessbut it would look like prefix=('text', FILEID), ....21:54
lifelessallowing VersionedFile's current keyspace to just be appended21:54
lifelessto get the unique keys21:54
abentleylifeless: It sounds almost like a normal bundle could be a record.21:54
lifelessabentley: yes, I think that that would work well21:55
lifelessor it could be a series of records - the byte representation doesn't need to change either way21:55
lifelessits just whatever we think best in terms of programmatic access at this point21:56
lifelessthe key question is, does this sound nice?21:56
lifelessis there anything 'ewww' about it, or suggestions to improve?21:56
abentleyWell, I go a bit eew at having multiple keys per record, but I can't think of anything better.21:57
lifeless(sorry to be monopolising your time with this, but you're the only other folk around to tease this out with)21:57
abentleyUnless we make an exception for weaves and recode them.21:57
lifelesswe could at a programmatic level just yield many fulltexts from a weave21:58
lifelessat a physical level though it would really be nice to be able to just drop the blob into the stream21:58
lifelessalso - performance wise, multiple keys per record with a record key prefix helps knit insertions21:59
lifelesshmm, thats a bit false22:00
abentleyThe thing is, current bundles use two pack records for each logical record; one for metadata, one for the bytes.22:00
lifelessit makes it easier in some ways to add many things to a target knit without having a cache of knits22:00
lifelessabentley: I think that that serialisation would work very well for weaves; in the metadata the list of keys to be extracted; in the bytes the raw weave22:01
abentleyHow would you represent this for knits?  AIUI, the index contains data not represented elsewhere.22:01
lifelessthere is a current knit stream, let me dig up its contents22:02
lifelessthe knit data stream has a list of (version_id, options, read_length, parents)22:03
lifelessand then sum(read_length) bytes after all of that22:03
lifelessso it gets to do a single readv() from disk to output the stream22:04
lifelessand likewise on insertion, it can often do a single write()22:04
lifelessthis is the other thing I would like to preserve, because thats pretty good for performance22:04
lifelessmapping one of these current knit streams into a single record lets me do that without loss of generality22:05
abentleyI think it loses the ability to do random access, though.22:06
lifelesswe don't do random access today AFAIK22:06
lifelessnot on streams22:06
guilhembHello, is bzr+ssh:// recommended over sftp:// ? Any reasons?22:06
lifelessdo we on bundles ?22:06
lifelessguilhemb: hi, bzr+ssh runs a bzr process at the other end, so it can do more22:07
chadmillerI thought I remember a bug specific to ssh+bzr protocol in the past six weeks or so.  I may be wrong.22:07
guilhemblifeless: mmm what more, for example?22:07
lifelesssending mail22:07
lifelessavoiding some (significant) network traffic22:07
guilhemblifeless: thank you22:08
abentleylifeless: It's true that we don't at present, but I was thinking once stacking works, we would be able to do bundles as stacked repos and merge directives as stacked branches.22:10
lifelessabentley: yes, we've talked about that before :). Hmm, what would be needed to add random IO to this22:10
abentleyWell, nothing would be needed for the format.22:11
abentleyYou'd just need to use lots of single-entry records.22:11
lifelessI think in principal you'd parse the stream once to build an index and then use the index22:11
lifelessthis wouldn't imply single or multiple-entry records22:12
lifelesswe could buffer the whole bundle if we wanted tho on pathological bundles this would really blow memory wise22:12
abentleyWell, let's say I've got a stream of an entire repository in a single record.  How would I get out one revision?22:12
abentleyWe could also persist an index, to avoid the initial read.22:13
lifelessparse the stream once, lets handwave about how we get code reuse, but say that instead of a get_stream on this, we have a 'get_repository' that indexes and then provides VersionedFiles indices for it22:14
abentleyDepending on size, we might even stick it at the beginning.22:14
lifelessfor each record, we just need back the index entries it contains22:14
lifelessthis could be one, or it could be N22:14
abentleyI mean an index of the stream.22:14
lifelessa VersionedFile index needs to be able to answer 'versions()', 'get_parent_map()'22:15
abentleySo we would know exactly where to seek if we want ('revision', 'foo-bar-asdf')22:15
lifelessbuilding the index would do that22:15
lifelesswe'd have a KnitDataAccess implementation for the whole stream22:16
lifeless(or roughly that)22:16
lifelessthis is what packs do today22:16
abentleyOkay, but still, how do you seek to a single knit delta when it's inside a massive pack record?22:17
lifelessthe index provides the readv() that is needed22:17
lifelessand there is a data access object which does the readv and strips out any serialisation metadata that needs to be removed22:18
lifelessthe data access object is stateless22:18
lifelessit just knows that e.g. stuff in a .pack has a pack record prefix to strip22:19
abentleyIt just seems pretty gross.  The VersionedFileIndex would have to know way too much about the pack serialization format.22:19
lifelessor that stuff in a .knit has no surrounding metadata22:19
lifelessabentley: hmm, can I point you at the current code?22:19
lifelessbzrlib.knit._KnitAccess and bzrlib.knit._PackAccess22:20
lifelessoh, and ._StreamAccess too22:20
lifelessthese provide the abstraction so that the index doesn't know anything about the serialisation format22:20
abentleyThese are exactly what made me spit the dummy and start a new repository format with none of this legacy stuff.22:21
lifelessoh :(22:21
abentleylifeless: I'm not sure we're in sync here.22:28
abentleyWe are still talking about the case where there is one record with a bunch of entries in it?22:28
abentleySo in order to do random access, you have to seek into the position in the container that corresponds with the position in the stream that holds the actual bytes?22:30
lifelesslets consider two cases22:31
lifelessa weave22:31
lifelessand a record with many things from the same 'knit'22:31
lifelessin the former case, we have to seek in the container and read the entire weave bytes22:32
lifelessin the latter case, we only need a small number of bytes22:33
lifelessbut the 'bzrlib.pack' container API won't let us read less than a full record at its physical layer.22:33
lifelessSo we'd want to make sure, for performance, that we fix that22:34
lifelessone way would be to improve that api - to have a way to say 'read bytes X..Y from within the container record starting at byte Z of this container22:34
lifelessanother would be to make sure that we always have a bzrlib.pack container record just for the smallest read we may want to do22:36
abentleylifeless: We could also achieve it with the current API by chunking up the stream.22:37
lifelessabentley: jinx :)22:37
lifelessor did you mean chunking at arbitrary points like every 512K or something22:38
abentleyNo, I mean more or less what you did.22:41
lifelessI think its useful to be able to read part of a containers record22:45
lifelessbut perhaps not worth adding22:45
lifelessone way we can achieve small chunks is nested pack containers22:45
lifelessstill, this is down to serialisation now, and in the first instance what I need is the in-memory python code22:46
lifelessso I'll write up a developer doc now, and try and include these issues22:46
lifelessbrekkie time, back soon22:52
abentleySo to get back to your main question, I think that bundles could use this format.22:56
abentleyThey would probably ignore the fact that multiple entries were allowed per record.22:56
abentleyIt's a bit overkill for them, and for the other uses.22:57
abentleyBut for weave, it seems necessary.22:57
lifelessis that sha field in mpdiffs that of the reconstructed text?23:00
abentleyI'm on the phone.23:01
awilkinsDAmmit, why isn't REALLY USEFUL STUFF like "bzr modified" mentioned in the help index....23:04
jdongawilkins: WTF! I didn't know that even existed!23:05
awilkinsIt's great... you can just go bzr modified | xargs dostuff23:06
jdongawilkins: defintiely, except the only problem is that it outputs paths respective to the root of the branch23:06
jdong<wishlist>it'd be nice of bzr st and friends to display paths relative to `pwd`</wishlist>23:07
awilkinsI hadn't noticed that .... but I tend to do that stuff in the roor23:07
jdongawilkins: yeah, if there existed `bzr root` I would be happy too23:07
awilkinsPeh, it has a "hidden = true"23:08
awilkinsShould be "danguseful = true"23:08
awilkinsDoesn't even show if you pass --long to help ; but --long says "help on all commands", not "help on commands except really useful stuff we don't want you to see to retain our mystique as UBER DOODS"... :-P23:10
abentleyawilkins: bzr help hidden-commands23:10
awilkinsabentley: I hate to be pedantic, but (AFAICT) that topic is hidden by default, so how are you supposed to know it's there without picking through the source?23:11
awilkinsOk, I'm lying, it's in the topics list23:12
* awilkins cuts out his tongue and pickles it in a jar23:13
abentleyawilkins: Boutiuqe, not-maintained, achievable-by-other-means functionality is typically hidden.23:13
abentleyIf you can use xargs, surely you can use grep.23:14
abentleyThere should be a status --modified also.23:14
abentleyThere isn't at present, but there should be.23:14
awilkinsIs find-merge-base in the category of "achievable by other means" ?23:15
abentleybzr revision-info -r ancestor:23:15
abentleyAlso, it is in the category of boutique.23:16
awilkinsDefine boutique in the context of bzr code23:16
abentleyOperations that an end user should never need.23:17
awilkinsDoes boutique imply achievable-by-other-means or was your list above a set (not a list of synonyms?)23:21
abentleyA set23:22
lifelessawilkins: 'bzr root' exists23:23
awilkinsI found find-merge-base and revision-info to be useful enough to patch them into the BazaarClient library that bzr-eclipse is using (bot for use in bzr-eclipse, but so I could use the features in my current Eclipse plugin project.23:23
jdonglifeless: well it must've only appeared there after your announcement 30 seconds ago :D23:24
* jdong questions his own sanity23:24
awilkinsNow, I was less experienced with bzr at the time... they may well be achieveable through other means.23:24
awilkinsbzr root isn't even in the hidden list ....23:24
abentleyI don't think there's anything you can get out of revision info that you can't get out of log.23:25
bob2it is in the normal bzr help commands list23:25
awilkinsabentley: True, but it's nice to have the convenience of not having to parse it out.23:25
awilkinsabentley: I respect the Pythonic "do it one way" thing though23:26
* awilkins attending to food brb23:26
bob2wasn;t there a "bzr help allcommands" or something23:27
abentleyawilkins: More commands is more intimidating to users, so where possible, we prefer to expose functionality as options to existing commands.23:30
awilkinsMeh, I keep typing bz rviz]23:46
awilkinsIt does weird things with the bz utility23:46
awilkinsMmmm, faggots, mushy peaa, mashed spud and onion gravy23:52
radixdon't smoke awilkins23:52
radixbut definitely eat mushy pea and mashed spuds23:52
radixwith onion gravy23:52
awilkinsNot fags23:52
awilkins"british meatball" - they usually include offal such as liver23:53
radixoh. well, I also don't recommend eating sticks23:53
radixwhoah. that's one I haven't heard before :)23:53
awilkinsDefinitely comfort food.23:54
awilkinsEspecially "Mr Brains" brand faggots23:55
ubotuNew bug: #215426 in bzr "MemoryError - recv for HTTP through Proxy" [Undecided,New] https://launchpad.net/bugs/21542623:55

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