[00:20]  * ToyKeeper wonders if there is a way to make sftp://host/path resolve to host:path instead of host:/path
[00:20] <ToyKeeper> (so, a single slash after host would be relative to $HOME, and two slashes relative to root)
[00:35] <abentley> ToyKeeper: You can get that effect with sftp://~/
[00:35] <abentley> i.e. sftp://host/~/
[00:36] <ToyKeeper> Ah, I only tried that with bzr+ssh, which didn't work.
[00:37] <ToyKeeper> As sftp, it's fine.  I wonder if the other host is just too old to support that syntax.
[00:38] <lifeless> bzr+ssh doesn't support ~ yet
[00:40] <poolie> hello all
[00:41] <lifeless> hi
[00:42] <ToyKeeper> I don't recall the last time I wanted to specify a repo path from root instead of ~ ...  good to know it's not there yet.  :)
[00:59] <spiv> Good morning.
[00:59] <onox> good night
[01:01] <mwhudson> hello spiv
[01:06] <awmcclain> "bzr: ERROR: Transport error: Server refuses to fullfil the request" is a bzr error, correct?
[01:06] <awmcclain> (I'm just trying to do a sanity check on this script I'm writing)
[01:08] <poolie> awmcclain: yes
[01:08] <poolie> hello kiko
[01:09] <poolie> abentley: hi, how about a brief call?
[01:26] <abentley> poolie: sure.
[01:26] <abentley> skype?
[01:27] <poolie> sure, it'll just take a few minutes to start that machine
[01:36] <kiko> hey poolie
[01:37] <spiv> poolie: Ok, I've sent that to PQM.
[01:38] <spiv> poolie: (James and Ian's Branch.set_last_revision_info hook)
[01:41] <lifeless> spiv: do we both actually reading less than full records from streams at all?
[01:41] <lifeless> spiv: I'm writing up the new streams api proposal in detail, and wondering whether to do the read() callable thing, or just slap bytes around
[01:41] <spiv> lifeless: I'm not sure.  I remember doing some of the work to make that possible, I don't recall how far it got.
[01:44] <lifeless> just saying 'here are the bytes' seems easier to me; once we have the interface in widespread use we could version it again. What do you think?
[01:45] <spiv> I'm fine with what's easy.
[01:46] <lifeless> ok
[01:46] <spiv> Hmm, there's a few fully-approved things lingering on BB.
[01:47] <lifeless> I don't want to merge the inventory thing
[01:47] <lifeless> aaron raised important concerns about it in London
[01:47] <lifeless> that aren't addressed; for all that Ian has approved it.
[01:47] <lifeless> (so its not been sitting there due to lazy robert; its deliberate)
[01:47] <spiv> lifeless: you also have " Fix the test HTTPServer to be isolated from chdir calls made while it is running"
[01:48] <lifeless> that bounced with a spurious conflict I think
[01:48] <lifeless> NEWS update or something. Be good to merge that.
[01:48] <lifeless> abentley: btw, I sent a loom:Merge thing to the list yesterday; as the only other active loom dev would you like to approve/resubmit it?
[01:49] <spiv> (I don't actually see your inventory thing in the list)
[01:49] <lifeless> sorry, http://bundlebuggy.aaronbentley.com/request/<1199746830.1954.76.camel@lifeless-64>
[01:50] <lifeless> its resubmit
[01:50] <lifeless> but doing the things it lists isn't enough, is what I meant
[01:51] <lifeless> the problems are more conceptual than code
[02:01] <spiv> lifeless: well, I'm not too worried about the details of resubmit items, given the number of approved and conditionally approved items...
[02:01] <lifeless> sure, my memory was glitchy
[02:02] <spiv> That's why we have BB :)
[02:06] <lifeless> ok
[02:07] <lifeless> draft written, sending as MERGE hopeing for comments
[02:35] <abentley> Oh, I think I know a significant factor in the BB lockups-- the automatic merge detection seems to be triggering them.
[02:36] <lifeless> ah
[02:36] <abentley> It's a fairly long process, possibly it can be sped up.
[02:37] <lifeless> which reminds me
[02:37] <abentley> Or maybe I can reduce the period it takes out locks.
[02:37] <lifeless> I really need to track down the slow index lookups bug
[02:37] <lifeless> abentley: could you calculate the things you need to analyse, release lock, do the work, reacquire and insert results ?
[02:37] <abentley> That would be unspeakably awesome.
[02:38] <abentley> lifeless: Hard to say.  The framework has hidden the fact that any locks are being acquired.
[02:38] <lifeless> yes, they tend to do that.
[02:38] <lifeless> I've become quite allergic to that behaviour as the years have gone by
[02:39] <abentley> In terms of the process, yes, I don't need to hit the database until I've calculated what's new.
[02:42] <abentley> about stacking: one case that worries me is when the owner of the stacked-on branch doesn't realize that it's stacked-on.
[02:42] <abentley> And deletes it, thinking it won't break anyone else.
[02:42] <lifeless> right
[02:43] <abentley> Even though the person who stacked on it made an explicit choice.
[02:43] <lifeless> This is why I punted on auto stacking initially, because then users are always explicitly accepting that risk. Obviously thats not viable for Just Works long term though.
[02:43] <lifeless> But I don't see any good way of telling people
[02:44] <abentley> So you're okay with it, if the user explicitly chose to stack?
[02:45] <lifeless> I don't see a way out
[02:45] <lifeless> I have minor nightmares about what happened in arch
[02:45] <abentley> Make it a social problem?
[02:45] <abentley> It's rude to stack on someone who hasn't invited it?
[02:45] <lifeless> yeah
[02:46] <lifeless> bundles are a good example of a form of stacking that works quite well
[02:46] <abentley> Right.
[02:46] <lifeless> I think it would be ok for me to branch from you, but stack on bzr.dev. For instance.
[02:47] <lifeless> by ok, I mean 'pretty safe'
[02:47] <abentley> The policy stuff I'm working on would allow me to *recommend* that if you upload stuff to my site, you should stack on my copy of bzr.dev.
[02:47] <lifeless> thats nice
[02:47] <abentley> I'm leaving out auto-stacking on the local host.
[02:48] <abentley> Unless the user configures it.
[02:48] <abentley> But no local stacking by default, since it proved controversial.
[02:50] <abentley> So I think we don't need a way for branches to declare that they can't be stacked on.  Which means we don't need a new format for stacked-on branches.
[02:50] <lifeless> abentley: yup.
[02:50] <lifeless> (beyond it working of course :P)
[02:53] <abentley> Speaking of formats that don't work, if you decide supporting weaves is too painful, I'm definitely amenable to ditching them at this point.
[02:53] <lifeless> have a read of the doc
[02:53] <lifeless> I think it will be easy to work with
[02:53] <lifeless> and not leak abstractions everywhere
[03:00] <abentley> One thing I notice is that you provide a way to ensure that the stream can reconstruct a fulltext.
[03:01] <lifeless> the thing for inventories do you mean?
[03:01] <abentley> Yes, for inventories.  Bundles don't do that-- they get the compression parent fulltext from the target repo, convert it to the right format, and apply the delta to it.
[03:02] <lifeless> generally these streams will do the same. there is a case where that does not work though for fetch
[03:02] <lifeless> if you look at the model1To2Helper
[03:02] <lifeless> instead of copying inventories it does iter_rev_trees
[03:02] <lifeless> tweaks the content, and serialises
[03:04] <abentley> Did you have more to say?
[03:06] <lifeless> oh sorry; email distraction. damn thing.
[03:07] <lifeless> so a line delta of an xml6 inventory is not safe to apply to an xml7 inventory, etc.
[03:07] <lifeless> thats why the inventory option exists, because one needs to be able to construct the inventories to do iter_rev_trees in the model changing helper
[03:08] <abentley> But an xml7 inventory can be converted into an xml6 inventory.
[03:08] <abentley> And the delta can be applied to that.
[03:08] <lifeless> so read in the inventory, parse, downgrade, serialise, then apply the delta
[03:08] <lifeless> ?
[03:09] <abentley> Right.
[03:09] <abentley> You can do it however you want.  Just thought I'd mention the option.
[03:09] <lifeless> as long as we have deterministic serialisers that will work, but it feels like there is an element of risk we can avoid
[03:10] <lifeless> If you don't have a strong opinion I'd rather avoid having to have the text storage layer adapt back through the parsed data like that
[03:12] <abentley> Sure.  It looks fine to me.
[03:13] <abentley> (Aside from the fact that it doesn't fix bug #2:-)
[03:13] <lifeless> *blink*
[03:14] <abentley> BB thinks you promised that this patch would fix bug #2.  Perhaps the bug regex is too forgiving.
[03:14] <lifeless> ah
[03:15] <lifeless> I went to https://bugs.edge.launchpad.net/bzr/+bug/2
[03:21] <beuno> lifeless, just for the record, I feel bad my command not found code ended up getting into the core with both you and abentley being against it  :(
[03:21] <beuno> s/bad/not satisfied
[03:22] <beuno> so I'm open to go a different direction, if we can find one that makes everyone happier  :)
[03:23] <lifeless> beuno: that was a confusing message - not that my vote was 'approve'
[03:23] <lifeless> *note*
[03:23] <lifeless> beuno: The core code without a included database I am entirely happy with.
[03:25] <beuno> lifeless, yes, I saw the approve, I was referring to both of you being against it, even though I split it into two, so we could discuss the remaining part separately
[03:25] <abentley> beuno: If I felt strongly, I'd have vetoed.  I just don't like the feature very much.
[03:26] <abentley> So changing approach wouldn't help.
[03:26] <abentley> But please don't take it personally.
[03:26] <lifeless> beuno: thats why I'm saying my comment was confusing. The core I'm happy with. The remaining part I'm not.
[03:26] <lifeless> and as abentley sayss, if we felt stringly we can veto
[03:26] <beuno> alright, feel less bad about it being piped through with "because poolie said so"  :p
[03:26] <lifeless> I wrote that two days ago
[03:27] <lifeless> and thought it included the database at the time I wrote it
[03:27] <lifeless> then I realised it didn't, but didn't clear the comment field when I changed the vote to approve.
[03:27] <lifeless> lifeless, here for your confusion.
[03:27] <beuno> aaah, right, ok ok
[03:28] <beuno> I can continue the remaining steps as a plugin and try and find consensus along the way
[03:38] <beuno> ah, I can't reject my own stuff on BB
[03:55] <spiv> beuno: huh, that's odd.  Oh, because you don't have voting rights on BB in general?
[03:57] <beuno> spiv, yup yup
[03:57] <beuno> but I though I could reject my own stuff
[04:05] <beuno> jelmer, BB still hates me  :)    my patches get approved automatically (one vote), but I can't vote on other patches
[04:05] <lifeless> hmm, this isn't quite right
[04:06] <lifeless> the delta closure stuff fits the api, but the api doesn't make it clear how to serialise
[04:06] <lifeless> shrug; I think it will be more clear in the wash.
[04:08] <lifeless> actually, no - the key thing is that we're going to want to be able to ask for a full text
[04:08]  * lifeless goes back to api design for a bit
[04:13] <poolie> spiv: reading your #213425 fix
[04:18] <spiv> poolie: ah cool.  I'm just heading off for lunch
[04:58] <abentley> lifeless: I didn't realize 'till now that was a stale message.  I'll look, but I very much doubt BB caused the delay.
[05:15] <spiv> Hmm, the set_last_revision_info hook failed to merge.
[05:15] <Talden> What the recommended CVS to Bazaar path (HEAD, branches and tags)?  I know the cvs2svn does 'the right thing' as I've been through that process... Is the task of getting subvsersion changesets into bazaar straightforward? svn2bzr from a subversion dump dies on even the most trivial dumps I've tried.
[05:16] <mwhudson> there are versions of svn2bzr around that work, i don't know the details though
[05:16] <mwhudson> there is also cvsps-import, don't know if that does branches/tags though
[05:16] <AfC> spiv: that Subversion import is _still_ running. Seems to be going a bit faster, though [I have the shell script loop printing the date each cycle of 100 revisions].
[05:17] <Talden> cvs2svn is amazingly good at ironing out those CVS inconsistencies.
[05:17] <AfC> ﻿It almost seems to imply that accessing newer revisions in an upstream Subversion repo is faster than older ones. {shrug}. It is such a travesty that the pain inflicted by this reflects poorly on Bazaar.
[05:18] <mwhudson> Talden: there is also bzr-svn of course
[05:18] <AfC> Talden: you're probably better off to go from CVS to Bazaar direct. The less intermediaries the better.
[05:18] <Talden> I had a look at there were mentions of svn 1.5 and patching python bindings... I'd rather not have to learn all about python to use the tool.
[05:19] <spiv> jamesh: your set_last_revision_info branch is failing: http://rafb.net/p/p2S39x21.html
[05:19] <spiv> jamesh: I'm looking into it now
[05:19] <Talden> the cvs2svn tool is adding git conversion, hopefully bazaar shouldn't be any harder.
[05:21] <Talden> It will be interesting to see what happens with repo size... CVS 2.1GB -> Subversion 1.6GB... hopefully Bazaars is a little tighter.  If it's not we'll probably be forced to say bye-bye to a lot of the history to make it more manageable.
[05:36] <jamesh> spiv: hmm.  I wonder if the conversion code should use _write_last_revision_info()?
[05:37] <spiv> jamesh: yeah, I was just starting to think the same thing
[05:37] <spiv> jamesh: after all, we don't really want the hook to fire in this case anyway
[05:38] <jamesh> spiv: and we don't quite have a valid branch at that point either.
[05:38] <spiv> Right.
[05:38] <spiv> So giving that branch object to a hook would definitely be a bad idea.
[05:39] <spiv> Using _write_last_revision_info fixes the test.  I'll run the full suite and if it passes, I'll resubmit.
[05:39] <spiv> I suspect this is the only problem.
[05:39] <jamesh> well, it might be a valid branch by the time the hook is called if it didn't throw an exception earlier :)
[05:39] <spiv> Heh :)
[05:39] <jamesh> actually, it hasn't even written the branch/format at that stage
[05:40] <spiv> Right, so giving a branch 6 object that's pointing to a branch 5 on disk is asking for trouble.
[05:40] <spiv> Besides, the last_revision_info isn't being changed, so firing the hook is definitely the wrong thing to do.
[05:52] <spiv> jamesh: tests all pass locally, I'll resend to PQM with that one-line change.
[05:52] <jamesh> spiv: thanks
[06:31] <poolie> spiv: paramiko fix looks good
[06:31] <poolie> i'm going to start doing 1.4 now
[06:44] <abentley> Okay, Bundle Buggy should never drop mail now.
[06:45] <abentley> Even if hung when the mail comes in (it will just build up until processed).
[06:49] <spiv> abentley: nice!
[06:49] <jamesh> do you know why it dies occasionally yet?
[07:02] <poolie> is it just me or do we get a lot of lock warnings from the tests now?
[07:05] <lifeless> thats what prompted me to do my patch
[07:05] <poolie> is it still awaiting review?
[07:07] <spiv> We do get a lot of warnings, yeah.
[07:09] <poolie> it looks like there were a lot more than before
[07:14] <lifeless> abentley: it was in my browsers POST cache
[07:15] <lifeless> abentley: I hit retry and it went in; I erroneously blamed BB for the queing
[07:46] <siretart> hi folks
[07:47] <siretart> can someone look what going wrong here: http://paste.ubuntu-nl.org/62805/? is this a known bug, or did I manage to fuck up my branch on launchpad?
[07:48] <siretart> UserWarning: file group LockableFiles(<bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.launchpad.net/%7Esiretart/aspectc%2B%2B/debian/.bzr/repository/>) was not explicitly unlocked
[08:01] <ubotu> New bug: #215522 in bzr "bazaar internal error on FTP push" [Undecided,New] https://launchpad.net/bugs/215522
[08:01] <poolie> siretart: hi
[08:02] <siretart> hi poolie
[08:03] <poolie> i'll check it out
[08:03] <siretart> I'm trying to imort that into a an rich-pack-root shared repository, using bzr 1.3
[08:04] <siretart> seems to be related to that, becuase local branching does work, though
[08:06] <poolie> ah ok
[08:06] <poolie> this rings a bell
[08:06] <poolie> siretart: i think abentley will be around in a few hours and i think he is working on a bug related to this
[08:06] <poolie> sorry but i really need to finish up and leave here
[08:07] <poolie> if you search lp for "revision not present" you may find the bug
[08:15] <poolie> siretart: in your local repo would you please run
[08:15] <poolie> cat .bzr/repository/format
[08:19] <siretart> poolie: Bazaar pack repository format 1 (needs bzr 0.92)
[08:19] <poolie> ok
[08:19] <poolie> https://bugs.edge.launchpad.net/bzr/+bug/215533
[08:19] <ubotu> Launchpad bug 215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New]
[08:21] <siretart> poolie: wow. Thanks for filing the bug. Subscribing myself now
[08:22] <poolie> i suggest you should either upgrade the branch on launchpad
[08:22] <poolie> or upgrade locally and push up
[08:22] <poolie> assuming you are able to write to this branch
[08:22] <poolie> you should just make sure you have a backup first to be sure
[08:22] <siretart> :)
[08:23] <poolie> sorry for the interruption
[08:23] <poolie> when it's upgraded it should be much faster though
[08:23] <siretart> with 'pushing up', you mean rsyncing it over sftp? (does rsync support sftp at all?)
[08:25] <poolie> over sftp or bzr+ssh
[08:25] <ubotu> New bug: #215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New] https://launchpad.net/bugs/215533
[08:25] <poolie> oh obviously you can write to it
[08:56] <poolie> ppas building now...
[09:08] <poolie> good night
[09:23] <spiv> poolie: hooray!
[09:31] <AfC> Still importing...
[09:37] <AfC> Hm. Here's a stupid question. Anyone know if you can get an svn "dump" of a subversion repository with other than local filesystem access to it? Its gotta be faster to rsync that blob down locally and then pull revisions out of it directly. 9 minutes per 100 revisions is crazy.
[09:38] <mwhudson> svnsync
[09:39] <mwhudson> i doubt it's very fast though
[09:51] <AfC> Whoof. Bug report, I think: If bzr-svn is in the middle of a pull, and you try and branch from that repository, bzr breaks complaining index file blah .iix not found. Shouldn't the otherwise accursed locks be preventing this?
[10:23] <j^> hi, why does .bzr/branch/branch.conf have push_location but parent_location instead of pull_location?
[10:40] <poco> hi
[10:41] <poco> any idea on how to tunnel a bzr+ssh on windows? (windows->gateway->ssh-server)
[12:06] <AfC> Hm. I now have a pack that is 177.9 MB big
[13:50] <clarby> hi, is it possible to do a partial push? like, i commit A and B, but I only want to push B.
[13:52] <andrea-bs> clarby: are A and B two files or two revisions?
[13:53] <clarby> andrea-bs: ah, sorry, they are files (directories)
[13:54] <andrea-bs> clarby: you can revert the changes made to A, push and recommit A
[13:55] <clarby> ah, too much hassle .. I can just finish what I'm not done with yet and push it all
[14:05] <ubotu> New bug: #215674 in bzr-gtk "uncommit needs an option for saving commit messages" [Undecided,New] https://launchpad.net/bugs/215674
[14:07] <ubotu> New bug: #130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
[16:06] <ubotu> New bug: #215732 in bzr "bzr-buildpackage --native had an internal error" [Undecided,New] https://launchpad.net/bugs/215732
[16:08] <awilkins> Ok, I just had a massive all-nighter hackathon on my current horrible++ project (involving bzr). Someone give me something to do for the next 20 minutes that isn't hacking horrible Java code :-)
[16:09] <bob2> haha
[16:09] <awilkins> THen I can POETS
[16:19] <mw-home> is there a bzr-svn to go with bzr 1.4?
[16:20] <awilkins> jelmer: ping
[16:28] <dato> mw-home: no, according to jelmer in the mailing list
[16:28] <mw-home> dato: ouch!  I need to rollback to bzr 1.3 then.
[17:24] <jelmer> mw-home: it's not 1.4 that's out yet btw, it's just the rc
[17:34] <_MMA_> I don't know if this is a Launchpad or Bazaar question. Is there a way to keep specific files synced between branches?
[17:35] <jdahlin> Hi, are there any web based frontends for bzr similar to what is used on http://git.kernel.org ?
[17:35] <jdahlin> basically just a list of project / description / owner / last change
[17:35] <_MMA_> "Automatically" synced that is.
[17:39] <johnny> jdahlin, so you don't consider bzr-webserve or loggerhead to be similiar?
[17:40] <johnny> :)
[17:40] <jdahlin> johnny: can I get such a view from them?
[17:40] <johnny> similiar is a very broad term for web viewers :)
[17:40] <jdahlin> oh, no, not similar enough!
[17:40] <johnny> you'd have to customize the code
[17:40] <johnny> patches are accepted i'm sure tho
[17:41] <jdahlin> eg, I have to do it myself!
[17:41] <johnny> what do you find lacking?
[17:41] <johnny> well some things are prolly more on the upstream developer todo than others
[17:41] <jdahlin> a "list of project / description / owner / last change" and being able to track on a per user basis
[17:41] <johnny> track on per user i'm sure is coming
[17:42] <johnny> sorry.. i'm not sure of the details 100%
[17:42] <johnny> i'm doing the same thing you are prolly :)
[17:50] <jelmer> jdahlin: I think webserve has such a thing, but I'm nto entirely sure
[18:08] <ubotu> New bug: #215797 in bzr "regression in annotate on mysql tree" [Undecided,New] https://launchpad.net/bugs/215797
[18:35] <rocky> don't suppose there are gutsy packages for latest bzr-svn (0.4.9) and bzr 1.3.1 floating around?
[18:36] <_MMA_> rocky: They might have been backported.
[18:36] <rocky> ppa has bzr 1.4rc1 and bzr-svn 0.4.6 ... which are incompatible with one another
[18:37] <jelmer> rocky: I've just removed bzr-svn-0.4.6
[18:37] <rocky> jelmer: that... doesn't help ;)
[18:38] <clarby> Hmm, every other time I try to push a commit it just halts. I log into the server I'm pushing to , run break-lock, and it re-push and it works. consistently. Anyone else get this?
[18:39] <jelmer> rocky: at least it shouldn't complain about incompatible versions anymore..
[18:39] <clarby> (and my cpu goes to 100% when it halts/hangs)
[18:39] <rocky> hrm, can't seem to access packages.ubuntu.com
[18:39] <jelmer> rocky: there's no bzr-svn compatible with bzr 1.4
[18:40] <rocky> didn
[18:40] <rocky> *didn't suspect there was
[18:40] <rocky> mostly i'm just interested in using the latest bzr-svn
[18:40] <rocky> whatever bzr comes with that is fine
[18:41] <jelmer> debian sid and ubuntu hardy have the latest
[18:41] <rocky> don't suppose the src pkg for ubuntu hardy would just recompile on gutsy?
[18:43] <jelmer> I think that should work, not aware of anything that may break it
[18:45] <clarby> Does anyone know if you're supposed to send recipients into send_mail() in chunks, or if the MTA chunks them up? (roughly 550 email addresses).
[18:46] <rocky> jelmer: needs a newer version of python-central it seems
[18:48] <rocky> ok, looks like i'm good
[19:01] <rocky> jelmer: don't suppose you have a "getting started with bzr-svn" link for people who need DVCS, never used bzr, but have to deal with a company's svn repo? :)
[19:02] <jelmer> rocky: there's no specific documentation for bzr-svn other than the FAQ
[19:03] <jelmer> rocky: bzr-svn makes svn branches feel like regular bzr branches
[19:03] <rocky> so "bzr branch http://mysvnurl.com/something/trunk" should work just fine?
[19:03] <jelmer> rocky: yep
[19:03] <rocky> i'm getting a 401 error even tho svn has cached the credentials for my site
[19:04] <rocky> in other words, svn ls http://mysvnurl.com/something/trunk   works fine
[19:04] <rocky> but branch on the same url does not
[19:04] <jdahlin> jelmer: do you know of a site that uses bzr-webserve, I couldn't trivally find an example
[19:04] <jelmer> and you're using svn+http://... as the url?
[19:04] <rocky> no i'm not, lol
[19:04] <rocky> that's what i asked you above =P
[19:05] <jelmer> rocky: well, the svn+ stuff is a workaround for a bug in bzr itself
[19:05] <rocky> gotcha
[19:05] <jelmer> rocky: it's only necessary if you use authentication
[19:05] <rocky> i jus couldn't find any docs telling me that i need to prepend svn+ to the url any place
[19:05] <rocky> ah
[19:05] <jelmer> jdahlin: no, not aware of any; sorry
[19:06] <jelmer> jdahlin: bzr-webserve is derived from hgweb
[19:06] <jelmer> jdahlin: http://code.bitlbee.org/hgweb/ contains an hgweb instance using bzr branches
[19:07] <jelmer> I think the layout has changed since then though
[19:09] <jdahlin> jelmer: perfect
[19:18] <javierder> ping jelmer
[19:54] <keescook> hi!  I haven't been able to find docs for something I think should be simple to do -- I want to have some kind of hook to run syntax checks before I do a commit for my tree.  where should I be looking?
[20:09] <exarkun> I can't create tags because my branch format is too old or something.  "bzr upgrade --dirstate-tags", as suggested in the error message which is reported, doesn't fix the problem.
[20:10] <beuno> exarkun, what does bzr info output?
[20:11] <exarkun> this http://rafb.net/p/POS2mv85.html
[20:12] <beuno> exarkun, and what version of bzr are you using?
[20:12] <ubotu> New bug: #215872 in bzr-gtk "gtk.branchview.linegraph.linegraph() expets tuple but some functions still pass string" [Undecided,New] https://launchpad.net/bugs/215872
[20:12] <exarkun> I tried with 1.0.0.candidate.1 on one machine and 1.3 on another with the same results
[20:27] <mtaylor> anybody around with zen on bzr-cvsps-import
[20:28] <beuno> exarkun, I really don't know, I don't use tags at all  :(
[20:29] <beuno> maybe a plain "bzr upgrade && bzr reconcile"?
[20:29] <beuno> (this is me guessing though)
[20:29] <exarkun> hmm, bzr reconcile
[20:30] <beuno> exarkun, that's just to fix some problems that might arise on upgrade
[20:31] <jkakar> It would be cool to have a 'pull' revision identifier that would behave somewhat like last, but based on the pull history.
[20:31] <jkakar> For example, pull:1 would be the same as last:1.  pull:2 would be the revision before the last pull, and so on.
[20:31] <beuno> jkakar, feel free to open a bug requesting it  :)
[20:32] <beuno> you mean "after"?
[20:32] <beuno> I'm on revno 10
[20:32] <beuno> bzr pull:1 would pull in revno 11
[20:32] <beuno> ?
[20:32] <jkakar> This would make reviewing changes easier.  You could pull a branch, review some changes and make comments.  Then, when comments are addressed do 'bzr pull && bzr diff -r pull:2' to see the changes made since your review.
[20:32] <jkakar> beuno: Not quite.  pull:N would be a history of revisions at the time bzr pull was called.
[20:33] <beuno> jkakar, hm, seems a bit more tricky, as you'd have to know what set of revisions you last pulled
[20:33] <jkakar> beuno: Right, I suspect that's the hard part.  Make bzr pull store a revision history somewhere.
[20:33] <beuno> jkakar, IMHO, having what revisions you pulled would be a step closer
[20:34] <beuno> or even how many revisions got pulled/merged in
[20:34] <beuno> "now at revno X" doesn't really say much to me
[20:34] <jkakar> beuno: Well, I first thought I wanted exactly what you suggest, but that still means I need to remember an ID to do what I want.
[20:35] <jkakar> beuno: A better UI is to offer a symbol that I can use consistently.
[20:35] <bialix> mtaylor: hi, I did several conversion with bzr-cvsps-import and it worked for me.
[20:35] <beuno> jkakar, right, it's a step closer and seems easier though  :)
[20:35] <mtaylor> bialix: have you done any of those with rich-root-pack?
[20:36] <bialix> no, why for?
[20:36] <beuno> jkakar, I might give showing what revisions you pulled a try, so if you open a bug for that one I might give it a try
[20:36] <mtaylor> bialix: when trying to push to a rich-root-pack repo, or trying to upgrade, we're getting this:
[20:36] <beuno> the other one seems a bit over my head
[20:36] <mtaylor> bzr: ERROR: Revision {('cvs-1:mtaylor-20070503013257-q7msvneefnm8ft54',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x2aaab1ff6050>".
[20:36] <bialix> mtaylor: upgrade to rich-root-pack is currently broken
[20:36] <jkakar> beuno: Cool, will do! :)
[20:36] <mtaylor> bialix: for cvs based things? or in general?
[20:36] <bialix> I promote importance of corresponding bug report to Critical
[20:37] <bialix> in general
[20:37] <mtaylor> upgrade to rich-root-pack being broken should be Critical...
[20:37] <beuno> jkakar, you can file them as separate bugs, maybe someone else can pick the other one up
[20:37] <awilkins> Bug is aleady raised to critical
[20:38] <bialix> mtaylor: sorry for my english. I already promoted it.
[20:38] <mtaylor> good
[20:38] <mtaylor> :)
[20:38] <mtaylor> bialix: does that explain why pushing from a cvs-imported branch to a RRP repo would also break with the same error?
[20:39] <bialix> Aaron said that new format pack-1.4 should land soon, that's why this bug is not fixed still, IIUC
[20:39] <mtaylor> um, all the various incompatible formats is starting to get un managable
[20:40] <mtaylor> I'm trying to move an organization to bzr, and the formats and their inability to interoperate properly is causing various amounts of bitching... fwiw of course
[20:40] <bialix> mtaylor: I think some common codepaths from non-rich-root to rich-root is just broken and this is affect and cvs-import too.
[20:40] <mtaylor> ok
[20:41] <mtaylor> bialix: cool. thanks!
[20:41] <awilkins> crazy format diversity problem ++
[20:41] <bialix> currently rich-root needed only for bzr-svn
[20:41] <mtaylor> but packs are the good-and-efficient thing, no?
[20:42] <awilkins> Yes, packs ++
[20:42] <awilkins> rich-root ++ also because good interop with SVN is a key adoption feature
[20:42] <bialix> packs is very carefully tested and widely used
[20:43] <mtaylor> bialix: by "packs", do you mean "--pack-0.92"
[20:43] <jkakar> beuno: Bug #215903 filed. :)
[20:43] <ubotu> Launchpad bug 215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Undecided,New] https://launchpad.net/bugs/215903
[20:43] <bialix> so if you don't need bzr-svn interaction it's better to not using rich-roots
[20:43] <bialix> IMO, of course
[20:44] <beuno> jkakar, confirmed and assigned to me  ;)
[20:44] <bialix> mtaylor: yes.
[20:44] <mtaylor> see, this is the thing though... I even hang out in here alot, and I obviously can't figure out what format I should be using
[20:44] <jkakar> beuno: Awesome, thanks!
[20:45] <bialix> mtaylor: better to use default format. pack-0.92 is default
[20:45] <awilkins> I use rich-root-pack all the time because I have a lot of branches in svn
[20:46] <bialix> yes, of course
[20:46] <mtaylor> from an i'm-an-idiot standpoint, pack-0.92 sounds much less stable than rich-root-pack
[20:46] <mtaylor> something about that 0.92 in the name
[20:47] <bialix> that's why I called them simply packs
[20:47] <bialix> 0.92 is version number when they was landed to bzr
[20:47] <awilkins> Hmph. With pack-1.4 coming up, "pack" as a format alias would be dicey
[20:48] <awilkins> Are packs optimised for speed or size?
[20:48] <beuno> awilkins, both  :)
[20:48] <bialix> for size and speed. but some operations is still too slow with packs
[20:49] <awilkins> I've seen some papers where compressions formats got some serious performance boosts by sacrificing some size.
[20:49] <bialix> I'm still use knits for some cases
[20:50] <bialix> awilkins: there is plans about adding local cache for speeding things up. but still not.
[20:50] <ubotu> New bug: #215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Wishlist,Confirmed] https://launchpad.net/bugs/215903
[20:51] <bialix> currently some operations much faster with packs, but others with knits
[22:04] <jdahlin> mwhudson: thanks for doing the stoqlib/stoqdrivers import and applying the pydoctor patch!
[22:04] <mwhudson> no worries
[22:05] <mwhudson> sorry for taking quite so long on the patch, it completely slipped under my radar
[22:05] <jdahlin> no worries
[22:06] <jdahlin> :-0
[22:06] <jdahlin> :-)
[22:43] <fbond> lifeless: ping
[23:31] <ubotu> New bug: #78765 in bzr-gtk "Allow diff between two selected revisions in bzr viz" [Wishlist,Confirmed] https://launchpad.net/bugs/78765
[23:46] <ubotu> New bug: #215996 in bzr-gtk "Select revision dialog doesn't show "sub" revisions" [Undecided,New] https://launchpad.net/bugs/215996