[00:01] <maxb> Hrm. bzr-svn seems to be doing a lot more work fetching tags now than it used to
[00:02] <jelmer> maxb: yes, consistent with bzr itself it now fetches all revisions referenced by tags, not just those in the branch tip ancestry
[00:02] <maxb> jelmer: unfortunately, on my largish work repository, this is the difference between bzr pull working, and taking so long that I give up and Ctrl-C it
[00:04] <maxb> wait.... all revisions referenced by tags? Doesn't that mean, given svn tags are not per-branch, that branching any branch of a svn repository has to walk and fetch the revisions on any branch which has been tagged?
[00:05] <jelmer> maxb: any relevant tag
[00:05] <jelmer> maxb: it doesn't fetch the branch tips, just the tags that would be in the branch that's fetched
[00:06] <jelmer> maxb: IOW for the 'ant' project in Apache SVN it would only fetch the revisions referenced by ant tags
[00:07] <jelmer> there has been some discussion about whether it's a good idea to fetch all revisions referenced by tags; perhaps it's something useful to bring up on the list
[00:07] <maxb> jelmer: but, consider some experimental branch that has tags - if the tags are bounded by project, branching trunk will now need to also pull in that experimental branch
[00:07] <maxb> For native bzr, it just about makes sense, because tags are per-branch
[00:08] <jelmer> maxb: it will only bring it in until the last revision that is tagged
[00:08] <maxb> which could still be a LOT of extra data transfer and processing time
[00:10] <jelmer> maxb: what about a svn tag that is based off a revision on the current branch but makes one additional modification?
[00:10] <maxb> hrm :-/
[00:12] <jelmer> maxb: I don't think this problem is specific enough to bzr-svn
[00:12] <jelmer> I had some unrelated tags on one of my bzr branches and also ended up fetching a lot of unrelated revisions
[00:21] <mgz> jelmer/maxb: if you notice any new plugin test failures with the latest bzr.dev please subscribe me to the bug
[00:21] <mgz> I changed the run_bzr args semantics a little and lots of the plugins' test suites use it.
[00:21] <jelmer> maxb: Suggestions on how to better handle tags on non-tip-ancestry revisions welcome
[00:22] <jelmer> mgz: ok
=== Ursinha-afk is now known as Ursinha
[01:00] <spiv> Good morning.
[01:01] <poolie> hi there spiv
[01:01] <poolie> like clockwork :)
[01:01] <spiv> :)
[01:02] <poolie> how are you, spiv?
[01:05] <spiv> Good, I seem to have escaped the worst of the cold going around this household.
[01:05] <poolie> you guys seem to have had a really bad run with that
[01:06] <poolie> over the last year or so i mean
[01:06] <spiv> Yeah.  Aside from the last week we'd been pretty good for maybe 2 months finally.
[01:06] <lifeless> EBABY
[01:07] <spiv> We think V picked this one up from another baby's 1st birthday rather than daycare for once.
[01:07] <poolie> itym fork() != 0
[01:07] <lifeless> len(pgroup)
[01:07] <lifeless> perhaps
[01:08] <poolie> i wish bug 456418 were fixed
[01:08] <ubot5> Launchpad bug 456418 in Launchpad itself "merge proposal status info should reflect status of prerequisite branch" [Medium,Triaged] https://launchpad.net/bugs/456418
[01:08]  * poolie tries to work out which of vila's patches comes first
[01:11] <poolie> jelmer: hooray for more tariff tests
[01:12] <poolie> jelmer, did you want to talk about the config mps or point me to any of them in particular?
[02:56] <poolie> spiv do you use selftest --subunit regularly?
[02:56] <poolie> i seem to have a bug where partway through the tests, the stream starts going to stderr
[02:58] <lifeless> wow
[02:58] <lifeless> poolie: do you say that because you've captured it, or because you start seeing the raw stream?
=== Ursinha is now known as Ursinha-afk
[03:02] <poolie> i am piping it into tribunal and part way through tribunal stops seeing updates and i get it in my terminal
[03:02] <poolie> it may well be a bzr test doing something weird with global state
[03:02] <poolie> just trying to narrow it down
[03:03] <lifeless> my guess would be a print statement (or debug statment) printing to stdout and not puttingn a \n on the statement
[03:04] <poolie> ah, yuck
[03:04] <poolie> and then the subunit libraries and tribunal are printing it out
[03:05] <poolie> i'd forgotten about that
[03:05] <poolie> that's easy to test with a simple redirection
[03:23] <spiv> poolie: I don't, although I use --parallel regularly, which does something similar I assue
[03:23] <spiv> *assume
[03:29] <lifeless> yup, --parallel does subunit for each core
[04:23] <poolie> it's probably a tribunal bug
[04:23] <poolie> too many yaks
[07:56] <poolie> maxb, hi
[07:56] <poolie> we might as well cease building for karmic in the daily ppa, hey?
[07:57] <maxb> poolie: hah
[07:57] <maxb> I was just finishing off an email proposing that before responding to your bing
[08:10] <jam> morning poolie
[08:21] <poolie> hello?
[08:22] <poolie> hi jam
[08:35] <jam> just saying hi
[08:37] <spiv> jam: hi :)
[08:43] <poolie> hi spiv
[08:47] <jam> hey spiv
[08:55] <spiv> Hmm, webnumbr seems to have stopped being able to fetch from launchpad :(
[09:00] <poolie> is there any indication why?
[09:02] <spiv> poolie: not that I can see.  Trying to create a new webnumbr against lp eventually just gives me a blank page, which suggests a problem on webnumbr's end
=== hunger_ is now known as hunger
[09:59] <poolie> good night all
[10:01] <jelmer> g'night poolie
[11:03] <jelmer> jam: Do you know what the difference between Inventory._get_mutable_inventory and Inventory.copy is ?
[11:04] <jam> jelmer: CHKInventory._get_mutable_inventory() returns an Inventory() instead of a CHKInventory
[11:04] <jelmer> jam: I knew there was something I was missing. Thanks.
[11:10] <spiv> I wonder how many uses of _get_mutable_inventory are left.
[11:11] <spiv> We mostly just use explicit deltas now.
[11:11] <jelmer> I'm about to remove one, that leaves two uses
[11:11] <jelmer> one in a test, and one in MutableTree.update_basis_by_delta
=== wallyworld__ is now known as wallyworld
[12:38] <jam> jelmer: talk about chasing the rabbit down the hole. Fixing iter_changes caused bugs to show up for WT.inventory which causes more test failures...
[12:38] <jam> we actually have some tests that we *don't* auto-detect nested trees (probably for performance reasons?)
[12:38] <jam> anyway, still chasing
[12:42] <jelmer> jam: ugh :-/
[12:43] <jam> jelmer: I think our tree-reference implementation is pretty incomplete, and basically it is 'just enough' to get the test suite to pass
[12:43] <jam> but alter one detail...
=== mrevell is now known as mrevell-luncheon
[12:53] <jelmer> jam: I can see how that's frustrating.. One of these days we should JF finish tree references..
=== mrevell-luncheon is now known as mrevell
[14:03]  * jelmer lunches
=== Ursinha-afk is now known as Ursinha
[15:29] <ablmf333> jelmer:  Morning.  Have u fixed the commit problem of bzr-svn?
[15:32] <jelmer> ablmf333: no, not yet
[15:32] <jelmer> ablmf333: https://bugs.launchpad.net/bzr-svn/+bug/765286
[15:33] <ubot5> Ubuntu bug 765286 in Bazaar Subversion Plugin "commit to checkout with pending merges breaks" [High,Triaged]
[15:34] <ablmf333> jelmer: Then, is there anyway to completely remove bzr info in svn repo, so I would be able to get a fresh check out that I can commit?
[15:34] <ablmf333> I deleted all the bzr:xxx properties
[15:34] <ablmf333> But I still couldn't commit
[15:35] <ablmf333> bzr still complains that I need to update before commit
[15:35] <jelmer> ablmf333: If you remove the bzr: properties you need to remove your bzr-svn cache and do a clean checkout
[15:35] <jelmer> ablmf333:
[15:36] <ablmf333> jelmer:  Where is the bzr-svn cache?
[15:36] <jelmer> ablmf333: usually ~/.cache/bazaar/svn/<uuid>
[15:37] <jelmer> jam: Nice work on the status improvements!
[15:37] <jam> jelmer: it could be better, I still don't get the improvement I wanted for 'bzr status' after 'bzr co', but I'm getting there
[15:37] <ablmf333> jelmer: How do I know which uuid should I delete?
[15:38] <jam> ah, I'm missing symlinks
[15:38] <jelmer> ablmf333: "svn info <url>" should display the UUID
[15:38] <jelmer> ablmf333: are these revision properties or file properties?
[15:38] <jam> (the tree I'm testing has a symlink in it, and we don't cache symlink targets on initial create, and it gets updated during first status)
[15:39] <ablmf333> jelmer: I just deleted every bzr:xxx on the trunk directory on svn server
[15:41] <jelmer> ablmf333: That won't help
[15:42] <ablmf333> jelmer: k, then how do I delete revision properties?
[15:42] <jelmer> ablmf333: That's not the point; removing *any* properties won't help with this issue.
[15:44] <ablmf333> jelmer: I don't get it.  What else could make bzr-svn thinks that my local branch is out of date?
[15:44] <jelmer> ablmf333: it's a bug that's got to do with your pending merges and its analysis of the revision graph
[15:45] <ablmf333> jelmer: No, no, I've committed the merge with svn.  Now I just want bzr-svn works on a fresh new checkout.
[15:48] <jelmer> ablmf333: so what's not updating exactly?
[15:49] <ablmf333> jelmer: I use `bzr co svn://....` to get a new checkout. Made some test modification and tried to commit, bzr tells me that the local is out of date.
[15:50] <ablmf333> jelmer: I just removed bzr-svn's local cache.  Hope that will help.
[15:52] <jelmer> ablmf333: what sort of changes are you committing, a merge?
[15:52] <ablmf333> jelmer: No, just a line of comment.
[15:55] <ablmf333> jelmer: bzr: ERROR: This operation requires storing bzr-svn metadata in Subversion file properties. These file properties may cause spurious conflicts for other Subversion users during merges. To allow this, set `allow_metadata_in_file_properties = True` in your configuration and try again.
[15:55] <ablmf333> jelmer: Should I do that?
[15:56] <jelmer> ablmf333: yep (it's consistent with what bzr-svn did for you previously)
[15:58] <ablmf333> jelmer: Thanks!  Finally I could use bzr-svn to work again.  Is there anything I should avoid in the future when using bzr-svn?
[15:59] <jelmer> ablmf333: not really, this is just a bug that's been fixed recently
[15:59] <jelmer> ablmf333: I would recommend /not/ removing file properties, that just breaks your bzr-svn cache and makes it slower
[16:01] <ablmf333> jelmer: k.  Thanks, hope u can fix the bug soon.
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
=== BasicPRO is now known as BasicOSX
=== Ursinha is now known as Ursinha-lunch
[19:20] <maxb> jelmer: FYI I have changed the dulwich-daily recipe to use ~vcs-imports/dulwich/trunk instead of ~dulwich/dulwich/trunk, because I think that will avoid the BzrCheckError
=== BasicPRO is now known as BasicOSX
=== Ursinha-lunch is now known as Ursinha
[23:44] <knighthawk> okay guys sorry for all the newbie questions but I'm lost again and RTFM hasn't helped me yet. So again I created a bzr repo using svn-import (no working tree) then I used 'bzr branch' to create a branch from the repo. Now from my brach (working tree) I'm trying to run 'bzr pull' from the svn repo. but I get 'bzr: ERROR: These branches have diverged. Use the missing command to see how.' it looks like I'm only one revision away from being able to do this
[23:44] <knighthawk>  (according to 'bzr missing') so It *seems* to me that I should run a merge then I should be able to pull only how do I merge a working tree with a none working tree?
[23:46] <knighthawk> btw if I got any of the terminology wrong please point it out. I'm trying to use it so I can get it right the terms all seem similar to svn but I'm thinking it may not be quite the same.
[23:53] <poolie> hi all
[23:53]  * fullermd waves at poolie.
[23:54] <fullermd> knighthawk: It's not quite clear what you're wanting or expecting...
[23:54] <fullermd> knighthawk: So you've got a branch from svn-import; call it A
[23:54] <fullermd> knighthawk: And a branch you made from A; call it B.
[23:54] <fullermd> Now you're wanting to...   pull from SVN into B?