[01:13] <poolie> jml or others, i'm just thinking about afc's suggestion that the format not be numbered 2.0
[01:13] <jml> poolie: what's the alternative suggestion?
[01:14] <poolie> well, his is to just give them arbitrary sequence numbers
[01:16] <jml> interesting.
[01:16] <jml> what's the advantage?
[01:17] <poolie> well
[01:17] <poolie> suppose we bump development-7 to be called 2.0 now
[01:17] <poolie> what happens if (unlikely but possible) we discover we need to change it for the real 2.0
[01:17] <poolie> also, it's a bit unfortunate that just saying "this is supported" requires a new name
[01:18] <jml> "it never works the first time", right? :)
[01:19] <poolie> that sort of thing
[01:19] <jml> poolie: why is a name-change to indicate support level unfortunate?
[01:21] <jml> does it affect the end-user, or is it more of a conflating-concepts thing?
[01:21] <poolie> well, it requires some work for us and for our users
[01:21] <poolie> so it's possibly waste
[01:21] <jml> *nod*
[01:22] <jml> from a #launchpad support perspective, formats matching release numbers _really_ helps.
[01:22] <poolie> things like people asking why they can't read a particular branch?
[01:22] <jml> yeah.
[01:23] <jml> or why stacking doesn't work.
[01:23] <jml> or what have you.
[01:24] <jml> poolie: hmm. it would also make reading graphs like these easier -- https://lpstats.canonical.com/graphs/RepositoryFormats/ -- if we actually used the UI format name on the graph.
[01:29] <poolie> mm
[01:30] <poolie> the other thing there is that you're reporting the repository format, and there are various independently versioned components
[01:32] <jml> yes.
[01:32] <jml> subjectively, it feels like repo fmt is the one that bites most often.
[01:33] <jml> we also report the branch format in a different graph.
[01:33] <poolie> it's also the one that changes most
[01:33]  * fullermd isn't sure he buys THAT...
[01:33] <poolie> both most often and most substantially
[01:33] <fullermd> I think we've had more branch formats...
[01:35] <jml> fullermd: well, that's easy enough to verify/falsify.
[01:36] <fullermd> Don't you go muddying the discussion with facts...
[02:00] <jml> poolie: so I guess that wasn't a very conclusive discussion :)
[02:01] <poolie> jml, actually it was a bit helpful
[02:01] <poolie> i wrote an email
[02:01] <poolie> i'd like if you would read it
[02:02] <jml> I saw the email just after I hit enter :)
[02:02] <jml> I'll read it now
[02:02] <jml> poolie:  * a set of formats for which this is the best recommended format
[02:02] <jml> is that supposed to be 'a set of versions' or similar?
[02:02] <poolie> yes
[02:03] <jml> cool.
[02:11] <poolie> i'm going to sign off for a while
[02:11] <poolie> what did you think, in a nutshell?
[02:11] <jml> poolie: extremely helpful map of the problem space :)
[02:11] <jml> poolie: I think 2.0mk1 or whatever would work well.
[02:12] <poolie> 2.0 mark twain :)
[02:12] <jml> poolie: not 100% sure about the creation UI.
[02:12] <poolie> btw thanks (to whoever) made merge reviews quote the parent post
[02:12] <jml> poolie: that's almost certainly abentley.
[02:14] <jml> poolie: I think the thing w/ creation UI is that you should almost always never have to think about format in order to get the optimal experience.
[02:14] <jml> but that's kind of a separate discussion.
[02:14] <jml> "what does it take to get a supported format to be the default?"
[02:14] <abentley> jml, poolie: It wasn't me, but it's in-line with my ideas.
[02:15] <poolie> jml, i agree
[02:16] <poolie> we could take the tack that we'll just always hide it so it doesn't matter how they're named
[02:16] <poolie> but that's not realistic
[02:16] <poolie> so we need to improve both sides
[02:16] <jml> yep
[02:17] <jml> so maybe a thing to think about with naming is, under what circumstances does a user need to identify a format?
[02:17] <garyvdm> Has anyone here used guppy
[02:17] <jml> anyway I really want to go and do Saturday things.
[02:17] <jml> particularly, I want some yerba maté
[02:17] <poolie> me too
[02:17] <garyvdm> is it possible to pass it an known object and see how big it is?
[02:31] <LaserJock> I'm a little confused about the state of the bzr-git plugin
[02:32] <LaserJock> http://bazaar-vcs.org/BzrForeignBranches/Git says the latest version is 0.3.2 but https://launchpad.net/bzr-git/+download just has 0.1.0
[02:47] <Peng_> Dozer reliably crashes Firefox. Nice. :D
[05:23] <jfroy> jelmer: I just got a fairly verbose exception from CachingRevisionMetadata
[05:30] <jfroy> jelmer: 384192, similar to 324970
[05:33] <johnjosephbachir> hello folks
[05:33] <johnjosephbachir> i scoured the man file, i promise-- how do i ask a bzr binary what version it is? :)
[05:33] <jfroy> johnjosephbachir: bzr --version
[05:34] <johnjosephbachir> nope -- that's for the version of the tree i believe
[05:34] <jfroy> no
[05:34] <jfroy> try it :p
[05:34] <johnjosephbachir> oh actually, it's not a flag
[05:34] <johnjosephbachir> at least, it's not mentioned in the man page
[05:34] <johnjosephbachir> (i was looking at --versionED)
[05:35] <johnjosephbachir> whoops-- my bzr is barfing on an error, that's the problem
[05:35] <johnjosephbachir> sorry for the bother
[05:36] <johnjosephbachir> (although-- it is true that that flag isn't mentioned in the man page)
[05:38] <jfroy> perhaps
[05:38] <jfroy> it a relatively common option for all UNIX programs
[05:38] <jfroy> (along with -v)
[07:52] <garyvdm> johnjosephbachir: fwiw --version is mentioned in "bzr help global-options"
[07:52] <johnjosephbachir> okay, cool
[10:05] <GPHemsley> jfroy: You awake?
[10:05] <jfroy> yeah
[10:05] <GPHemsley> wow
[10:05] <GPHemsley> when do you sleep?
[10:05] <jfroy> not much :/
[10:06] <GPHemsley> oh
[10:06] <jfroy> and when I can :p
[10:06] <GPHemsley> sorry to hear that :/
[10:06] <jfroy> lol it's fine :p
[10:06] <GPHemsley> but, on the other hand, not ;)
[10:07] <GPHemsley> so what do you think of uninstalling both the fink and MacPorts versions of my SVN and then reinstalling via MacPorts?
[10:07] <GPHemsley> do you think that will solve my problems?
[10:07] <jfroy> it might
[11:08] <GPHemsley> jfroy: Hmm... MacPorts even had trouble updating subversion
[11:08] <GPHemsley> So I tried uninstalling it
[11:08] <GPHemsley> Reinstalling it now (which will also bring it from 1.5.5 to 1.6.2)
[11:08] <jfroy> yeah
[11:09] <jfroy> I'm going to bed now, but, hopefully that will solve your problem
[11:09] <GPHemsley> alright
[11:09] <GPHemsley> thanks for your help :)
[11:09] <jfroy> np
[11:19] <LarstiQ> jfroy: thanks for your suggestion to joschan, unfortunately it seems he didn't pay attention :/
[11:28] <Peng_> mwhudson or beuno: ping
[11:30] <Peng_> Oh, right, it's Saturday. Oh well.
[12:12] <mwhudson> Peng_: tentative hello
[12:13] <Peng_> mwhudson: Good morning.
[12:14] <mwhudson> Peng_: you're right about not being good at timezones then :)
[12:14] <mwhudson> (it's 23:14 here)
[12:14] <Peng_> :P
[12:14] <Peng_> I always say "Good morning". For me, it *is* morning locally, but I'm probably gonna go to bed soon. :P
[12:15] <Peng_> mwhudson: Anyway, the ping was just because I want bug #382765 to be on someone's radar, because Loggerhead uses a deprecated bzrlib API that may soon be removed from bzr.dev.
[12:15] <Peng_> mwhudson: Kind of unnecessary, since everyone reads bugmail, but it's too late to take it back now. :P
[12:16] <mwhudson> there's a branch about this right?
[12:16] <Peng_> mwhudson: No.
[12:17] <Peng_> mwhudson: beuno has a branch about other deprecated stuff, but not this.
[12:17] <mwhudson> ah
[12:18] <mwhudson> ah, i misunderstood your comment :)
[12:19] <mwhudson> i'm fairly sure just deleting the stuff in loggerhead will be fine
[12:19] <mwhudson> but i'll make sure on monday :)
[12:20] <Peng_> mwhudson: Thank you. :)
[15:37] <aboSamoor> Hi, I have a personal repository, I branched it on my laptop and desktop. Trying to push from my laptop I got this error "bzr: ERROR: These branches have diverged."
[15:48] <sidnei> hey folks, im wondering if bzr supports specifying the revision in the url like subversion does, eg: 'bzr branch lp:something@123' to get revision 123 of lp:something
[15:49] <jpds> sidnei: bzr branch -r 123 lp:something
[15:50] <sidnei> jpds: yeah, that much i know, just wondering because subversion supports the alternative @rev format
[15:55]  * sidnei considers filing a feature request
[15:55] <LarstiQ> sidnei: it's been talked about in the past
[16:11] <sidnei> LarstiQ: so what was the conclusion? yagni?
[16:13] <LarstiQ> sidnei: don't clearly recall
[16:17] <ddaa> knowing the bzr style it would probably end up being something pedantically correct like "lp:something?r=123"
[16:17] <ddaa> Not that there is anything wrong with pedantic correctness.
[16:25]  * LarstiQ heads to Amsterdam
[16:29] <LeoNerd> $ bzr missing --remember sftp://cel/var/bzr/leo/perl/IPC-PerlSSH/
[16:29] <LeoNerd> bzr: ERROR: no such option: --remember
[16:29] <LeoNerd> ^-- what do I mean there..? I thought it had a --remember
[16:31]  * LeoNerd goes for  vim .bzr/branch/branch.conf
[19:30] <javaJake> Is there a way I can lock a folder or repo so that only one person can make edits? There's some areas in our repo that unforunately cannot be merged easily, so it would be nice if there's a way to "remind" others that committing is not allowed for a folder at that moment.