[00:01] <awmcclain> poolie: Ahhh... that's it. I merged to trunk, found a significant bug, shelved the barnch for a while. I must not have reverted that merge in trunk.
[00:01] <awmcclain> Oh, what a headache.
[00:03] <poolie> awmcclain: so um
[00:03] <poolie> try doing something like this:
[00:03] <poolie> run log on the feature branch, to find the revisions with changes you want to keep
[00:03] <poolie> then do a cherrypick merge of them into trunk
[00:03] <poolie> this should bring the files back into existance
[00:04] <awmcclain> then merge back into feature branch?
[00:04] <awmcclain> Or, what if I create a new feature branch, and just cherrypick merge from my old branch into that?
[00:05] <poolie> spiv: alive?
[00:05] <poolie> spiv: did you already fix a dupe of bug 356699 perhaps?
[00:06] <poolie> awmcclain: oh sorry you're trying to merge trunk in, i see
[00:06] <poolie> how about
[00:06] <poolie> merge trunk, then do
[00:06] <poolie> 'bzr merge -r 10..20 .'
[00:06] <poolie> ie replay those changes from this branch
[00:06] <awmcclain> oh, smart.
[00:07] <awmcclain> where 10 is the feature revision where trunk and feature diverge, and 20 is the feature revision just before i merge trunk back in
[00:10] <kenichi_> hello, a dev here just committed a change to a branch, somehow it included a remove and add of the same file, even though his 'bzr st' and 'bzr diff' before commit didn't show this change, and he claims he didn't touch that file.
[00:11] <kenichi_> now a checkout of that branch fails with "bzr: ERROR: Revision {.......} not present in "....."
[00:11] <poolie> kenichi_: using plain bzr or bzr-svn?
[00:12] <kenichi_> i didn't set up this branch, but i believe the trunk it came from was initially set up with bzr-svn
[00:19] <spiv> poolie: I'm alive, I don't remember fixing that bug, although anything is possible...
[00:19]  * spiv quickly checks the recent changes
[00:21] <poolie> it just sounded like something you changed
[00:22] <spiv> lifeless has touched that code recently as part of cutting out more roundtrips from push.
[00:22] <kenichi_> poolie: does bzr-svn cause  this?  is there somewhere you could point me to read up on issues like this?
[00:23] <spiv> He may have accidentally fixed that at the same time, I'm not sure.
[00:23] <poolie> kenichi_: i've seen some bug reports similar to this, i don't know specifically what's happening sorry
[00:23] <poolie> jelmer might, or you can ask on the bazaar list
[00:23] <kenichi_> ok, thanks
[00:27] <jelmer> kenichi_: what's the bug # exactly?
[00:28] <kenichi_> jelmer: i haven't filed a bug report, just the abridged paste above.
[00:29] <jelmer> kenichi_: It's hard to say anything specifically related to the error class, can you perhaps pastebin the traceback?
[00:32] <kenichi_> jelmer: i'm not actually getting a traceback, just the error, and a non-working checkout.  is there a arg i can pass to get more info?  (tried -v)
[00:38] <kenichi_> jelmer: here's as much info as i have to give http://pastebin.com/d176d4a49
[00:48] <lifeless> poolie: we have bugs remaining in autostacking
[00:49] <lifeless> poolie: its possible I fixed the most recently opened one, but I haven't explicitly checked
[01:13] <lifeless> spiv: how goes the ghost inventory tests?
[01:21] <igc> morning all
[01:24] <AmanicA> morning
[01:26] <lifeless> hi igc
[01:27] <igc> hi lifeless
[01:28] <vxnick> hi guys - is there any way I can remove a "pending merge", as it's not showing up in my repository viewer for some reason :S
[01:28] <lifeless> vxnick: bzr revert
[01:28] <lifeless> vxnick: a pending merge is one that has been done to your working tree but not committed to the repository
[01:28] <vxnick> lifeless: I see, thanks
[01:29] <vxnick> lifeless: any way I can "undo" that revert? I didn't realise it'd remove everything I've just done :)
[01:30] <lifeless> vxnick: uhm heh. It will have backed up to files with ~ in their name anything you had edited
[01:30] <igc> poolie: fyi, my top tasks today are admin-related: hr, expenses, etc. I'll then try to get an email out re branch specific rules status & options going forward
[01:30] <poolie> igc, thanks
[01:30] <poolie> thanks for the user documentation
[01:30] <lifeless> vxnick: things changed by the merge that you had not edited are recoverable by repeating the merge
[01:30] <poolie> mine are too, specifically expenses, report and reviews
[01:31] <vxnick> lifeless: sorry to bother you - how can I merge these back?
[01:32] <lifeless> vxnick: can you rephrase, I don't quite follow the question
[01:32] <vxnick> lifeless: well, I've reverted as you suggested - I see the ~ files; how do I put my changes back into the main files? Not sure how else to explain it I'm afraid
[01:33] <lifeless> vxnick: first, repeat the merge
[01:33] <vxnick> lifeless: bzr merge?
[01:33] <lifeless> yeah, however you did it before
[01:34] <vxnick> lifeless: well I didn't do it specifically last time; it just kinda happened :P
[01:34] <vxnick> I'll give it a go
[01:35] <vxnick> argh
[01:35] <lifeless> ok, so once you've got the merge done, you can copy the ~ files back over
[01:35] <vxnick> no idea
[01:35] <lifeless> ok
[01:35] <lifeless> what commands had you run leading up to this
[01:36] <vxnick> right - initially I made a single-file commit; I then went on to work on some other files, and committed those as a newer revision. This stated that it would merge r127 (the single commit) into r128
[01:36] <vxnick> the problem then being that r127 doesn't show up in my repo viewer
[01:36] <vxnick> so I have since uncommited back to r126
[01:36] <vxnick> then reverted as you suggested
[01:37] <lifeless> interesting
[01:37] <vxnick> in a bad way? :P
[01:38] <lifeless> I'm trying to imagine why you would get told a merge is happening when you haven't apparently being doing merges
[01:38] <lifeless> is this a checkout of a branch other people commit to as well?
[01:38] <vxnick> I'm using bzr as a centralised system in this case
[01:38] <vxnick> just myself
[01:38] <vxnick> it made me bzr update before I could commit r127 (the single file)
[01:38] <lifeless> ok!
[01:38] <lifeless> bzr update is a form of merge
[01:38] <vxnick> I see
[01:39] <lifeless> ok
[01:39] <lifeless> now, 127 is probably 126.1.1 now, because of the merge
[01:39] <lifeless> but because you uncommitted its all rather invisible
[01:39] <vxnick> right
[01:39] <lifeless> have you got bzrtools installed? there is a command in there 'bzr heads' that may be useful
[01:40] <vxnick> I believe so - I'll run it...
[01:40] <lifeless> bzr heads --dead
[01:40] <vxnick> just going to install it
[01:40] <vxnick> I appreciate your help btw :)
[01:40] <lifeless> anytime
[01:43] <vxnick> bah bzrtools isn't working for me
[01:45] <vxnick> probably because it's not compatible bzr 1.5 by the looks of it
[01:45] <lifeless> you'd need bzrtools 1.5
[01:45] <vxnick> ah yes, just trying it
[01:47] <vxnick> lifeless: unknown command "head"
[01:47] <lifeless> heads
[01:47] <lifeless> its a plural ;)
[01:47] <vxnick> returns nothing
[01:47] <lifeless> bzr heads --dead ?
[01:47] <vxnick> yeah a load of stuff
[01:47] <vxnick> anything in particular I'm looking for?
[01:48] <lifeless> well, it will let us undo the uncommit, if you want to
[01:48] <lifeless> I'm not quite sure what the best way out of this is
[01:48] <vxnick> hmm
[01:48] <lifeless> anything you have committed is recoverable
[01:49] <vxnick> so a revert only affects my working copy, not the repo?
[01:49] <lifeless> and the backup files will contain any edits you'd made and not committed
[01:49] <lifeless> right
[01:49] <igc> poolie: if you get a chance, I'd like you feedback on the user doc as well, though that can wait til early next week
[01:49] <vxnick> so if I wanted to, I could delete my working copy and do a fresh checkout?
[01:49] <lifeless> a revert puts your local tree back to the state of the branch
[01:49] <lifeless> it gets rid of edits and of pending merges
[01:49] <vxnick> I see
[01:50] <vxnick> not quite sure where to go from here to be honest
[01:51] <lifeless> so, whats your current state? if I understand correctly you have
[01:51] <lifeless>  - some stuff you uncommitted
[01:51] <lifeless>  - some stuff we reverted
[01:51] <lifeless> what would you like to have?
[01:52] <vxnick> ultimately, I'd like to separate this merged r127 so I can commit it seperate to r128; but short-term I'd like to get back to where I was, which was without reverting :P
[01:52] <vxnick> before reverting, even
[01:52] <lifeless> so before reverting you had the content of the thing you'd uncommitted
[01:52] <vxnick> let me just have a quick scroll up
[01:54] <lifeless> I'm just gonig to reboot; I'll be back in a few minutes
[01:54] <AmanicA> I keep on getting the following with bzr.dev (even after trying make clean; make  and I don't see old bzrlibs lying around in my pythonpath)
[01:54] <AmanicA> bzr: ERROR: The API for "<module 'bzrlib' from '/stuph/projects/bzr/bzr.repo/bzr.dev/bzrlib/__init__.pyc'>" is not compatible with "(1, 14, 0)". It supports versions "(1, 15, 0)" to "(1, 15, 0)".
[01:54] <vxnick> lifeless: thanks for letting me know
[02:01] <AmanicA> (andrew) Bump api_minimum_version to 0.15.0 because of the removal of
[02:01] <AmanicA>         InstallFailed.
[02:01] <AmanicA> ^^^ that seems to be the culprit (pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m)
[02:03] <lifeless> back
[02:03] <vxnick> hi
[02:03] <vxnick> right, I've checked my history
[02:04] <vxnick> I uncommitted 128 and 127, so I'm currently at 126
[02:04] <lifeless> ok
[02:04] <lifeless> you should be able to just 'bzrpull -r revid:<whatever128was> .'
[02:04] <vxnick> and all my changed files are at r126
[02:04] <vxnick> I'll give that a try
[02:05] <lifeless> (and bzr heads can give you the revid for what you had at 128)
[02:05] <vxnick> it doesn't unfrotunately
[02:05] <vxnick> heads --dead doesn't anyway
[02:05] <lifeless> thats odd
[02:05] <lifeless> well it will be in your  ~/.bzr.log
[02:06] <vxnick> can I grep for 128 in that log?
[02:06] <vxnick> it's pretty packed
[02:06] <lifeless> yah
[02:06] <lifeless> or at least  less, then /128
[02:07] <lifeless> you're looking for a revid, which looks like email-date-random
[02:07] <vxnick> righto
[02:08] <vxnick> I've grep'ed for 20090508 and have one result, which I'm presuming is 128
[02:08] <AmanicA> anyways, I'm surprised that nobody else is getting that problem, must be on my setup then.   have to sleep now. goodnight.
[02:08] <lifeless> AmanicA: are you running nightlies?
[02:08] <AmanicA> :)
[02:09] <AmanicA> 3am
[02:09] <lifeless> AmanicA: if you're running bzr.dev or a nightly package, you will get skew like this from time to time
[02:09] <AmanicA> not sure what nighties are
[02:09] <AmanicA> ah
[02:09] <AmanicA> no bzr.dev
[02:09] <lifeless> it means a plugin (e.g. bzrtools, or bzr-svn) hasn't updated.
[02:10] <AmanicA> ok thx. I thought so but it seemed to be in __init__.pyc so I thought it a core issue
[02:10] <vxnick> lifeless: is the revid the full me@domain-datetime-random string?
[02:10] <vxnick> or just part of it
[02:10] <lifeless> the full thing
[02:10] <vxnick> thanks
[02:10] <lifeless> to give it to the ui, prefix it with revid:
[02:11] <vxnick> trying now
[02:11] <lifeless> AmanicA: __init__ has 1,15,0, whatever is asking is asking for 1,14,0
[02:11] <AmanicA> but that may just be wher bzr complains
[02:11] <vxnick> lifeless: do I need the < > around it?
[02:11] <AmanicA> ok thx
[02:11] <lifeless> vxnick: no
[02:12] <lifeless> for instances, revid:pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m
[02:12] <vxnick> bah, gotta install bzrpull too by the looks of it :)
[02:12] <lifeless> vxnick: 'bzr pull ...'
[02:12] <lifeless> vxnick: you missing a space: )
[02:12] <vxnick> woops
[02:12] <vxnick> I was copying you literally
[02:13] <lifeless> *I* missed a space ;)
[02:14] <AmanicA> lifeless: thanks a lot for responging, I thought I was losing it for a while. Would have been nice if it said what wanted the new version, will look into it another night. anyways goodnight.
[02:14] <vxnick> lifeless: I think you may possibly be a genius :)
[02:14] <vxnick> lifeless: it says I'm on r128 now so I just need to resolve some conflicts
[02:14] <lifeless> vxnick: ok, cool
[02:14] <vxnick> are the .moved files the newer ones (r128) or the r126 ones?
[02:16] <lifeless> older I would expect
[02:16] <vxnick> many thanks for your help - I'll try to do it from here :)
[02:16] <vxnick> really appreciate it
[02:21] <lifeless> igc: responding to your doc is on my todo as well
[02:21] <lifeless> however today is already quite full :)
[02:21] <lifeless> spiv: reping, see above
[02:23] <vxnick> I'm afraid I need some help merging these .moved files :(
[02:23] <vxnick> not really sure how to do it
[02:24] <lifeless> well
[02:24] <lifeless> the easiest way is just to mv them over the non .moved files; if the non .moved files are unchanged (don't show up in bzr st or bzr diff)
[02:24] <lifeless> then you can do 'bzr diff' and see the difference
[02:25] <vxnick> I also have these ~1~ files left
[02:25] <lifeless> similar/same process for them
[02:26] <vxnick> these .moved files look identical - you're saying delete them basically?
[02:26] <vxnick> or delete the originals
[02:28] <lifeless> if they are identical delete them
[02:28] <vxnick> question - are they conflicting because they're identical? bzr auto-resolves conflicts usually doesn't it?
[02:29] <lifeless> they're conflicting because they were existing files where bzr wanted to put files
[02:29] <vxnick> gotcha
[02:29] <lifeless> bzr resolve can be used to tell bzr that you have resolved a conflict
[02:29] <vxnick> thanks
[02:33] <vxnick> ok, I've removed the duplicates however bzr resolve is still showing the conflicts
[02:33] <vxnick> my mistake
[02:33] <vxnick> I didn't do --all
[02:35] <vxnick> lifeless: any chance we could attempt separating the merged r127 from r128?
[02:35] <vxnick> or isn't that possible
[02:38] <lifeless> vxnick: I'm reasonably sure they are separate in bzr's internals
[02:38] <lifeless> vxnick: what does 'bzr log' show?
[02:38] <vxnick> lifeless: it'd just be nice to view the changes in my repo viewer
[02:39] <vxnick> lifeless: bzr log shows all revs up to 128
[02:39] <vxnick> including 127
[02:39] <vxnick> ah - it has 126.1.1
[02:39] <lifeless> what happened is that you had two things happen at once
[02:40] <lifeless> and you needed to merge to combine them - the 126.1.1 shows the thing that happened outside the 'trunk'
[02:41] <vxnick> so is there anyway I can go back and do that?
[02:41] <vxnick> the reason I'm so keen to view r127 is that it was a massive commit
[02:42] <igc> bbiab
[02:43] <lifeless> vxnick: well your repository view should be able to show it
[02:43] <lifeless> just look at 126.1.1
[02:43] <vxnick> 126.1.1 is the commit prior to the big one though
[02:43] <vxnick> 126.1.1 was a single file commit
[02:44] <jam> hey lifeless, I'm around for a bi
[02:44] <jam> bit
[02:44] <lifeless> jam: hi; just keen to get bbc->production readiness planned
[02:44] <lifeless> I'm worried about iter_changes and stacking
[02:44] <lifeless> jam: also we need to write our talks
[02:44] <lifeless> for next week
[02:44] <lifeless> s/for/during/
[02:45] <jam> dang, its friday already ...
[02:45] <lifeless> yup
[02:47] <vxnick> lifeless: slight problem - I've checked-out the repo in a different place and bzr revno is showing as r126 :S
[02:47] <vxnick> rather than 128
[02:47] <vxnick> I tried bzr co -r revno:128 (not sure of the syntax) but it said no such revision
[02:51] <lifeless> vxnick: that sounds like they are in your checkout only.
[02:51] <lifeless> vxnick: if you are happy with how it looks now, do 'bzr push repo'
[02:52] <lifeless> where repo is the url you checkout from
[02:52] <vxnick> lifeless: any chance we can sort the 126.1.1 or is it stuck like that?
[02:52] <vxnick> i.e. get it into its own rev no
[02:52] <lifeless> vxnick: its basically stuck like that
[02:53] <vxnick> lifeless: ok no probs - i'll push
[02:53] <lifeless> it can be rewritten but its getting kinda complex
[02:54] <vxnick> lifeless: "pushed up to revision 128" :-)
[02:54] <vxnick> anything else or should I be good now?
[02:54] <lifeless> should be good
[02:54] <lifeless> go to your other checkout and do 'bzr update' to see
[02:54] <vxnick> yeah am currently runnig
[02:54] <vxnick> works fine
[02:54] <vxnick> thanks loads
[02:55] <vxnick> I'm glad there's a decent community around here
[02:56] <lifeless> no problem
[02:58] <jam> lifeless: did you just get a new gpg key?
[02:58] <jam> I guess it is now "(My Canonical long address)"  :)
[02:58] <lifeless> jam: I added a new signing subkey for a machine
[02:58] <igc> jam: so 'log DIR' is slow in dev6rr because ...
[02:58] <jam> so igc, 'log DIR'... I think we are fundamentally approaching it from the wrong direction, simply because that was the easiest for XML formats
[02:59] <lifeless> jam: my laptop has it, but that new machine has only it.
[02:59] <igc> Inventory.filter() is slow
[02:59] <jam> igc: 'log DIR' is slow because the algorithm is structured to hit every item in the directory each time
[02:59] <jam> rather than starting with changes
[02:59] <igc> and it's slow because children is slow
[02:59] <jam> 'log -v' on 1k revs of mysql is 3s
[02:59] <jam> log DIR is 1m30s
[02:59] <jam> O(tree) algorithms are *bad*
[03:00] <igc> jam: so post-processing the delta will probably work *much* quicker
[03:00] <jam> igc: From what I can tell, part of the issue is handling 'recursion'
[03:00] <igc> jam: precisely
[03:00] <jam> in that if someone gives "DIR" we need to figure out if "some-random-delta-file-id" is part of that DIR
[03:00] <jam> there are a few ways we can do it
[03:01] <jam> 1) Change Inventory.filter() for CHKInventory
[03:01] <igc> jam: I couldn't see how to that faster down at the inventory layer (i.e. iter_entries(dir=X))
[03:01] <jam> the size of specific_fileids() is always going to be much smaller and define a smaller subset of the set
[03:01] <jam> iter_entries_by_dir(dir=X for X in specific_fileids)
[03:01] <lifeless> jam: s/always/usually/. Pathological users abound.
[03:01] <jam> but that still scales poorly
[03:02] <jam> lifeless: this is a case where optimizing for the common case is probably going to give the best wins, as long as we aren't terribly pathological
[03:02] <jam> 2) Do 'changes' first, and then filter that after the fact
[03:02] <jam> technically the path filter can be computed from the parent_id_basename =>file_id map
[03:02] <lifeless> jam: oh agreed; I'm just making sure we don't forget that silly things happen
[03:02] <jam> and can be 'cached' between trees that have the same root hash
[03:02] <jam> however, that still scales as O(entries_in_dir)
[03:03] <jam> when O(num_changes) is often ~5-10
[03:03] <jam> (on average)
[03:03] <lifeless> also!
[03:03] <lifeless> remember we're about to change iter_changes
[03:03] <jam> So I was thinking that if we do a smart inversion of
[03:03] <lifeless> this will impact chk delta stuff
[03:03] <lifeless> and it may do so helpfully
[03:03] <jam> for ..., file_id, ... in iter_changes():
[03:03] <jam>   parents = get_id_path(file_id)
[03:04] <jam> if file_id or parents in specifice_fileids:
[03:04] <jam>  add
[03:04] <jam> lifeless: right, because we are looking to include parents of changes, right?
[03:04] <jam> igc: so I would inline the get_id_path part
[03:04] <jam> because
[03:04] <jam> a) You can keep a set of "known_uninteresting" directories
[03:04] <lifeless> jam: yes, in an as-yet-un-pinned-down-way
[03:05] <jam> as well as a set of "known_interesting" ones
[03:05] <jam> so that you only have to recurse to the root sometimes
[03:05] <jam> and as changes are likely to be grouped by dirs
[03:05] <jam> you'll likely get fast culling
[03:06] <igc> jam: sounds promising
[03:08] <jam> igc: I *think* you could push some of that down into iter_changes, except you lose any chance to cache info between trees
[03:08] <jam> as the *tree_shape* information could be cached between trees
[03:08] <jam> as long as parent_id_basename_root_id (sha1) didn't change
[03:08] <lifeless> jam: we could pass a cache in
[03:08] <lifeless> lunchtime
[03:08] <jam> however, by my numbers that only gives... 5:1 hits
[03:09] <jam> so *something* but unless we added 'delta' support to the cache maintenance, I'm not convinced it saves a whole lot
[03:09] <jam> (you could have the delta look at the parent_id_basename map changes, and determine what could be kept/discarded, but that takes more thinking.)
[03:10] <jam> igc: do you feel like that is enough info for you to work on it?
[03:10] <igc> jam: yes thank-you
[03:10] <lifeless> I have a couple of thoughts too
[03:10] <jam> lifeless: If I'm still here when you get back, I'd be interested in chatting a bit about stacking requirements and GC+CHK
[03:10] <jam> GC makes stacking 'easy' because it doesn't have deltas
[03:10] <lifeless> have you guys considered using the per-file graph to jump back in log DIR?
[03:10] <jam> but CHK is doubly difficult
[03:11] <lifeless> jam: stacking is currently serialiser-locked, I don't see how CHK impacts it
[03:11] <jam> lifeless: as in finding the recursive set of possible file ids, and then grabbing all of their graphs
[03:11] <jam> etc
[03:11] <lifeless> jam: [recursive set] - no
[03:11] <jam> lifeless: CHK 'externals' are not easily deduced from just the index
[03:11] <jam> and they are potentially "deep"
[03:11] <jam> in that the direct referenced one will reference more
[03:11] <lifeless> I mean, in rev Y, under DIR, 5-10 files are changed
[03:12] <lifeless> consider only their per-file graphs, and you get 5-10 possible revs to jump to
[03:12] <jam> lifeless: I don't think you know that in Y-1 another 3 files disjoint were modified
[03:12] <lifeless> jam: oh bother
[03:12] <lifeless> jam: I really wish we'd had time to do the recursive-change field in inventories; it would solve this trivially
[03:13] <jam> lifeless: right
[03:13] <jam> though at the expense of a bit more data churn
[03:13] <igc> lifeless: and another minor issue: the per-file graphs don't contain delete info yet & log needs to report that
[03:14] <jam> lifeless: so if your smart fetch requires the complete inventory for a given revision in order to determine the file-ids to fetch
[03:14] <jam> we only know the chk pages by *walking* them
[03:14] <lifeless> igc: indeed
[03:14] <jam> we can get some of that by the first pass as we transmit data
[03:14] <jam> but that only gives us a single depth of referenced pages
[03:14] <lifeless> igc: we can fix that by including a node at deletes
[03:14] <jam> so we may need to walk *those* as well, in case of > depth-2 trees
[03:15] <lifeless> jam: smart fetch requires a delta, not a inventory
[03:15] <lifeless> jam: [once we have the delta patch finished]. CUrrently your 'make xml' hack is in place
[03:15] <jam> lifeless: ouchie
[03:16] <jam> lifeless: so GCVF already supports fallback versioned files
[03:16] <jam> and passes the VF test suite for that
[03:16] <jam> So the *only* whole I can think of for stacking support
[03:16] <jam> is how we handle CHK pages
[03:16] <lifeless> jam: I'd approach this by a) turning it on and reenabling it, see how it goes
[03:17] <lifeless> b) look closely at whether we're going to have showstopper design issues, or things we can tweak to improve
[03:17] <lifeless> hole?
[03:18] <lifeless> today, I'd say we want the entire CHK tree for edge-revisions in the stacking branch, as this philosophically matches our current 'can get full inventory' rule for them.
[03:18] <jam> lifeless: well, 99% of all current trees we work in are only going to be depth 2
[03:19] <jam> (one root, then leaves, or at most 1 root + 1 internal + 1 leaf)
[03:19] <jam> but the design is that they can be much deeper
[03:19] <jam> I'm somewhat concerned that we won't have problems because depth 2 won't trigger bugs
[03:19] <lifeless> ideally we can drop that back to 'all CHK page needed to generate a delta of any revision present against its parents'
[03:20] <lifeless> jam: I'm really not quite understanding the concern; are you saying fetch won't copy the right data?
[03:20] <jam> ATM, fetch has 2 passes, right?
[03:20] <lifeless> or can't be made to copy it? or will be slow if it does?
[03:20] <jam> The first pass could inspect the data it wants to transmit
[03:20] <jam> to determine the data it needs to transmit
[03:20] <lifeless> jam: StreamSource can do as many passes as it wants
[03:21] <jam> except for CHK pages, that might need yet-another pass to get to the actual end
[03:21] <lifeless> it generates 1 stream
[03:21] <lifeless> StreamSink can, after insertion, say 'I need more data'
[03:21] <lifeless> and that will result in a second stream
[03:21] <jam> It only gets to say that 1 time, right?
[03:21] <jam> but I guess you're right about stream sending a multi-pass stream
[03:21] <jam> since we already do that now
[03:22] <lifeless> the CHK pages introduced in the revs being pushed should all be included in the first stream, always.
[03:22] <lifeless> if the revs are at the edge of the stacking repository, it will ask for the inventories of the adjacent-absent revisions
[03:22] <lifeless> StreamSource in that case should provide all the CHK pages of those inventories
[03:23] <jam> lifeless: so the 'pages introduced' should always be included, I'm wondering if the 'pages referenced' should always be included
[03:23] <jam> as well as the inventories for adjacent
[03:23] <jam> though I suppose that should overlap
[03:23] <jam> I'm not sure it is 100% overlap
[03:23] <jam> (might be)
[03:23] <lifeless> pages referenced-and-not-introduced should be included in adjacent-inventories-full-page-set
[03:24] <lifeless> a future improvement would be to have the second stream be 'pages-required-to-delta-against-this-but-not-the-full-closure' - and thats where it gets tricky and is why you are concerned.
[03:25] <lifeless> that should be done after basic support is up
[03:25] <jam> lifeless: right, especially because it depends on the delta algorithm
[03:25] <lifeless> I think for fetch we should be only deltaing adjacently
[03:25] <lifeless> or within the set being sent
[03:29] <lifeless> really lunching now
[03:35] <jam> lifeless: btw, I think dev6rr fetch just picks 'an' adjacent revision, not *all* adjacent revisions. Though it could certainly do so.
[03:35] <lifeless> jam: if we can consolidate the two similar code paths it would do all
[03:35] <lifeless> :)
[03:39] <lifeless> hmm, regression in ignore:(
[03:39] <lifeless> bzr ignore foo, where foo is a versioned directory, and contents of foo showing as unknown
[04:00] <jml> a revision object has no reference to its repository
[04:00] <jml> is this deliberate?
[04:01] <lifeless> is it something we care deeply about? I don't think so
[04:01] <lifeless> deliberate is harder to answer
[04:01] <mwhudson> i can't say i've ever found that surprising
[04:02] <mwhudson> revisions have always seemed pretty atomic in some sense to me, not that much more structured than strings in some sense
[04:03] <mwhudson> huh, nice repetition hudson
[04:03] <lifeless> in some sense
[04:09] <jml> what's the difference between supports_delta and supports_diff in a log formatter?
[04:11] <mwhudson> jml: delta is like bzr st, diff is like bzr diff
[04:11] <mwhudson> (i think)
[04:11] <jml> ok. that makes sense.
[04:11] <jml> mwhudson: so, what you were saying earlier about revisions not being more than structured strings
[04:12] <jml> mwhudson: I get that, but it can go either way wrt having a reference to a repository
[04:13] <mwhudson> jml: yes
[04:13] <mwhudson> well,
[04:13] <mwhudson> no
[04:13] <mwhudson> jml: i guess what i mean is that you don't go directly from a string to something else
[04:13] <jml> sure
[04:13] <jml> the string is often a key into a real object
[04:13] <mwhudson> you might look up something under a string to find something else
[04:13] <mwhudson> but you don't go string.object_with_key
[04:14] <mwhudson> revisions are like that
[04:14] <jml> *nod*
[04:14] <jml> but maybe they could also be such that revision.get_parents() worked.
[04:14] <mwhudson> yeah
[04:15] <jml> I'm just noticing that I can't use a log formatter to show the author of the second-to-left parent revision of mainline as the author of the mainline revision.
[04:20] <mwhudson> ah
[04:20] <mwhudson> the log formatter doesn't get the branch or repo or anything?
[04:20] <mwhudson> well, i guess there may not be a branch
[04:21] <jml> mwhudson: no.
[04:21] <mwhudson> ugh
[04:21] <jml> mwhudson: I mean, you subclass the log formatter, so you can pass it one yourself
[04:22] <mwhudson> yeah, but that's pretty icky
[04:22] <mwhudson> will work for what i guess you're doing :)
[04:22] <jml> and in the canonical use case, there is a branch
[04:25] <spiv> lifeless: late pong
[04:26] <lifeless> spiv: its all there in history ;P
[04:26] <lifeless> how is it going basically
[04:27] <spiv> lifeless: I've been taken a little by surprise by fileids_altered_by_revision_ids, when a (stacked, no fallbacks set) repo has say rev-2 but not rev-1, and rev-2 doesn't change any files from rev-1, fileids_altered_by_revision_ids(['rev-2']) still reports rev-1.
[04:28] <lifeless> right
[04:28] <lifeless> thats the root of the bug in fact
[04:28] <lifeless> heres why it occurs:
[04:28] <lifeless> without rev-1's inventory, we can't calculate the delta
[04:28] <lifeless> so we get everything that is referenced
[04:28] <lifeless> not new references
[04:29] <lifeless> its why we want rev-1's inventory in the stacking repo
[04:30] <spiv> Yeah, it makes sense (the fulltext inventory clearly says "this file is at version rev-1"), but for some reason I was expecting fileids_al... to incorrectly deduce rev-2 there.
[04:30] <lifeless> ah
[04:30] <lifeless> :)
[04:30] <lifeless> it used to return nothing
[04:30] <lifeless> this lead to bugs in fetch where incorrect inventories caused stuff to be dropped
[04:30] <lifeless> so we fixed that
[04:30] <spiv> It doesn't really matter which version it reports, so long as it reports something and I can check that it's present.
[04:31] <spiv> i.e. this doesn't break my fix, but it's caused me grief when designing tests.
[04:31] <lifeless> if rev1's inventory is there it will report nothing
[04:31] <lifeless> if its not there it will report rev1's version, because rev2 doesn't have a version
[04:32] <lifeless> ok
[04:32] <spiv> (Also, there are no explicit unit tests for this corner of fileids_al...'s behaviour)
[04:32] <lifeless> what do you want to test
[04:32] <lifeless> spiv: uhm, there are actually, its just that those tests are pretty much inpenetrable
[04:32] <spiv> That the fix works ;)
[04:32] <lifeless> ok
[04:32] <spiv> More specifically,
[04:32] <lifeless> less broads
[04:34] <spiv> [re: fileids_al...'s tests, grep didn't find any other than test_fileid_involved.py, and it has no tests that show a revision in the result that wasn't passed as an arg to fileids_al...)
[04:34] <lifeless> hmmm, you may be right
[04:35] <lifeless> I know I wrote tests when I changed it
[04:35] <lifeless> it may be layered
[04:37] <lifeless> so - what behaviours do you want to ensure
[04:38] <lifeless> 'it works'
[04:38] <lifeless> that can be expanded
[04:38] <lifeless> are there things that shouldn't happen
[04:38] <spiv> Anyway, I'm testing: simple linear history where [parent inv missing + all texts present -> ok], [parent invs present + new texts present -> ok], [parent inv missing + text missing -> not ok]
[04:38] <lifeless> and things that should
[04:38] <lifeless> ok
[04:38] <spiv> Also, ghost rev that does not cause missing texts -> ok
[04:39] <lifeless> that shouldn't interact badly with fileids_altered
[04:39] <lifeless> branchbuilder supports ghosts now
[04:39] <spiv> Ah, handy, I didn't know that.
[04:39] <lifeless> I added it for a test
[04:40] <lifeless> look at record_snapshot's docstring
[04:41] <spiv> Also, I found I needed to use add_inventory directly on the target repo rather than get/insert_record_stream, because ensuring that I get a single fulltext inventory record was too fiddly with the stream API.
[04:43] <lifeless> thats surprising
[04:44] <lifeless> I would have expected roughly insert_record_stream(FullTextRecord(get_record_stream(foo, 'topological', True).next())) to Just Work
[04:45] <spiv> Right, I could probably manually assemble a FullTextContentFactory, but that's considerably more complicated than just calling add_inventory.
[04:45] <lifeless> true
[04:45] <lifeless> add_inventory is fine too
[04:46] <spiv> Yeah.  I was a bit reluctant too at first, because it takes the test slightly further away from the way streaming fetch works, but I made peace with the idea fairly quickly :)
[04:46] <spiv> s/too/to/
[04:47] <spiv> Anyway, I feel that I do understand all the dark corners now, so it's going rapidly now.  But right now it's lunch time!
[04:48]  * spiv -> food
[04:48] <lifeless> excellent
[04:48] <lifeless> I'm doing pdr stuff
[04:48] <lifeless> so just ping if you are able to save me from it at any point
[05:01] <lifeless> oh yeah
[05:01] <lifeless> jml: https://code.edge.launchpad.net/~lifeless/subunit/autoconf/+merge/6328 is textually large, but code wise tiny
[05:01] <lifeless> jml: I'd love a review :)
[05:02] <jml> lifeless: I might not get around to it for a week or so
[05:02] <jml> lifeless: but I'll put it on my todo list -- who knows what will happen!
[05:03] <lifeless> jml: I'lll nag other people then
[05:03] <lifeless> jml: as it will block me
[05:03] <jml> lifeless: ok.
[05:03] <lifeless> jml: or you can opt and and I'll land it as is
[05:03] <jml> lifeless: I'm basically talks talks talks until next weekend :)
[05:04] <lifeless> beamer where art thou?
[05:04] <lifeless> jml: basically it moves subunit to use autoconf; this gives the library a good soname and makes it packagable
[05:05] <jml> ok.
[05:05] <lifeless> jml: no python code changes at all; minor changes to the shell tests to support VPATH builds
[05:10] <lifeless> spiv: I've checked, build_snapshot in bzr.dev has support for ghosts
[05:10] <krisfremen> hello there, i'm gettign "Cannot build extension "bzrlib._btree_serializer_c"."
[05:11] <krisfremen> anyone knows a little bit of insight as to what is wrong?
[05:11] <lifeless> there should be more output than that
[05:11] <krisfremen> it's quite long
[05:11] <lifeless> if you can pastebin it somewhere I will look at it
[05:17] <krisfremen> http://pastebin.com/d2a36e92d
[05:18] <lifeless> #
[05:18] <lifeless> bzrlib/_btree_serializer_c.c:4:20: error: Python.h: No such file or directory
[05:18] <lifeless> #
[05:18] <lifeless> that suggests you don't have the python library header files on your system
[05:19] <lifeless> you might prefer to use a prebuilt bzr, but if you do want to build bzr yourself you need 'python-dev' or whatever the package is called on your operating system
[05:19] <lifeless> or you can run bzr without building the extensions (it can run as pure python)
[05:19] <krisfremen> i do have that package
[05:20] <lifeless> can you do
[05:20] <lifeless> ls /usr/include/python2.5/Python.h
[05:21] <krisfremen> hmm
[05:21] <krisfremen> not there
[05:21] <lifeless> are you running jaunty ?
[05:22] <krisfremen> debian lenny
[05:23] <lifeless> hmm, I think that has 2.5 as defalt
[05:23] <lifeless> *default*
[05:23] <lifeless> anyhow, you need /usr/include/python2.5/Python.h
[05:23] <lifeless> I think its normally in python2.5-dev, which is pulled in by python-dev usually
[05:26] <krisfremen> sudoed it and it worked
[05:26] <krisfremen> weird, maybe some permissions are messed up
[05:27] <krisfremen> thanks!
[05:29] <lifeless> no probs
[05:31] <jam> spiv, lifeless: btw, if you add a FulltextContentFactory, I believe it goes down to '.add_lines()' which can create a delta
[05:31] <jam> you have to insert a KnitFulltext record if you want to force it to be a full text
[05:31] <jam> though I believe add_inventory() can also generate a delta
[05:32] <lifeless> jam: it won't create a delta if the target repo is missing the parent
[05:32] <lifeless> jam: which is the scenario
[05:32] <lifeless> jam: the point is to avoid dragging the parent content around by mistake
[05:44] <lifeless> -> pdr stuff done
[05:45] <lifeless> deep hacking time on check; if anyone wants me SMS or ring
[06:12] <lifeless> abentley: if you're around; we used to have code for determining left-hand-distance-to-null; do you happen to recall what we did with it?
[06:13] <lifeless> (I'm refactoring Branch.check to take a precalulated graph rather than every branch doing the same thing)
[06:20] <jml> does bzrlib have a standard way of taking an optional location and turning it into a branch?
[06:20] <jml> should it?
[06:20] <lifeless> EPARSE
[06:20] <lifeless> [what talk are you writing btw, and if you're all talk at the moment, consider  mailing jam and I]
[06:21] <jml> lifeless: I think the cost of explaining what I mean is greater than or equal to the cost of figuring it out myself :)
[06:21] <lifeless> jml: if you mean 'open_or_init' or something like that, uhm no, And I don't think so
[06:22] <lifeless> if you mean something else, maybe, who knows.
[06:22] <jml> lifeless: I mean more like a command-level thing for saying "just default to the branch that's in the current directory."
[06:23] <jml> lifeless: but I think that's just if location is None: location = '.'
[06:25] <jml> talks I'm doing are: Introduction to Twisted; Tour of Launchpad Code; Teach Me Packaging; "Your Code Sucks and I Hate You"
[06:26] <jml> lifeless: and whatever help I can spare for your & jam's talk
[06:31] <lifeless> jml: we're doing two :P
[06:31] <lifeless> so please pluralise :)
[06:31] <lifeless> jml: anyhoo, thats Branch.open_containing
[06:31] <jml> lifeless: the one I submitted the proposal for :)
[06:31] <lifeless> and yes, if location is None: location='.'
[06:32] <lifeless> jml: la-la-la-la
[08:03]  * igc celebrates completing his just-in-time hr paperwork by starting his many-weeks-late expenses paperwork
[08:09] <spiv> igc: :)
[08:09] <spiv> igc: I know the feeling!
[08:10] <igc> spiv: does that mean you've remembered my "review me" invitiation? :-)
[08:13] <spiv> igc: yes :)
[08:13] <spiv> igc: (doing those now, in fact)
[08:22] <bialix> luks: ping
[08:22] <luks> pong
[08:23] <bialix> luks: I'd like to make Gary admin of qbzr google group. He's most active these weeks
[08:23] <luks> sure, no objections to that
[08:23] <bialix> ok
[09:28]  * igc packs it in for the day
[09:28] <igc> have a good weekend all
[12:46] <abentley> lifeless: It's on Graph.
[12:47] <abentley> lifeless: Graph.find_distance_to_null
[12:49] <lifeless> abentley: thanks
[14:53] <Mez> how do I create a working tree for something that doesnt have one ?
[14:53] <beuno> Mez, bzr co .
[15:03] <ricardokirkner> hi. is there any way to have a bzr repo be pushed to svn, and keep each commit author? (I mean, every team member commits to a central bzr repo, and from there one person pushes to a svn repo... each individual commit.. retains authorship, or are all commits re-owned by the person who effectively pushes to svn?)
[15:07] <lifeless> jelmer: I've packaged subunit
[15:07] <lifeless> jelmer: if you want to change the maintainer field and do the upload to close your bug in debian, that would be fine
[15:08] <lifeless> ricardokirkner: bzr will add metadata saying the original author, but I'm not sure whether svn looks ast that or not; I suspect it doesn't.
[15:09] <ricardokirkner> lifeless, it uses svn properties for that right?
[15:10] <ricardokirkner> I had some issues with that... its not very nice from the svn point of view to have a lot of properties set/reset on each commit
[15:26] <jelmer> ricardokirkner: it uses revision properties if you have a new enough version of svn (svn >= 1.5)
[15:26] <jelmer> lifeless: ah, nice
[15:27] <jelmer> lifeless: care to be co-maintainer ?
[15:27] <lifeless> jelmer: sure
[15:27] <ricardokirkner> jelmer, and if you have a lesser version? what does it use?
[15:28] <jelmer> ricardokirkner: file properties
[15:28] <ricardokirkner> jelmer, sorry I am missing something here..
[15:29] <ricardokirkner> svn:ignore is a svn property... this is a revision property?
[15:29] <ricardokirkner> if so, what is a file property?
[15:32] <jelmer> ricardokirkner: svn:ignore is a file property
[15:32] <jelmer> ricardokirkner: revision properties are generally not visible for the user
[15:32] <lifeless> jelmer: https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases revno 70
[15:33] <savvas> does bzr require repackaging like git if it gets big?
[15:34] <lifeless> savvas: bzr automatically packs as needed
[15:34] <lifeless> you can manually trigger a pack if you have reason to, but its not something we recommend
[15:34] <jelmer> lifeless: whu
[15:34] <jelmer> lifeless: what sort of fancy branch is that?
[15:34] <lifeless> jelmer: package branch
[15:35] <savvas> it's ok, I like "automagic" :)
[15:35] <lifeless> halt()
[15:35] <lifeless> gnight
[15:36] <Odd_Bloke> How can I list the files changes in a commit?
[15:37] <Odd_Bloke> *changed
[15:37] <beuno> Odd_Bloke, -v
[15:38] <lifeless> Odd_Bloke: bzr st -c revno
[15:38] <lifeless> Odd_Bloke: log -v -c revno
[15:38] <lifeless> bzr diff -c revno | diffstat
[15:38] <lifeless> (really gone now)
[15:38] <jelmer> lifeless: ah, interesting
[15:38] <jelmer> lifeless: 'night
[15:39] <lifeless> jelmer: oh
[15:39] <lifeless> one more thing
[15:39] <lifeless> there is a tarball
[15:39] <jelmer> lifeless: and appropriately set debian/watch ? :-)
[15:39] <lifeless> no
[15:39] <lifeless> watch can't do bzr well
[15:39] <lifeless> https://edge.launchpad.net/~subunit/+archive/ppa
[15:39] <jelmer> lifeless: it can deal with tarballs though :-)
[15:40] <lifeless> grab the -65 tarball from there
[15:40] <jelmer> lifeless: btw, how do I register new package branches?
[15:40] <lifeless> jelmer: yes, but I'm not making official release tarballs at this point
[15:40] <lifeless> jelmer: usual way, push to em
[15:40] <jelmer> lifeless: ah, k
[15:40] <jelmer> lifeless: but mirrorred branches? There's no register link
[15:40] <lifeless> the tarball of -65 is a snapshot, you could make your own but nicer to reuse
[15:41] <lifeless> jelmer: I don't know that you can, or that it has even been considered
[15:41] <james_w> jelmer: not currently possible to have a mirrored package branch
[15:41] <lifeless> jelmer: anyhow, lp is fast now
[15:42] <jelmer> lifeless: Yeah, but I'd like to register the branches on bzr.debian.org
[15:42] <lifeless> good use case
[15:42] <lifeless> jelmer: ^
[15:42] <jelmer> as packaging branches seem to be supported for debian in lp too
[15:42] <lifeless> james_w: ^
[15:42] <lifeless> ciao
[15:43] <james_w> they are
[15:43] <james_w> I think the immediate problem is that the form for registering just has a space for "Project:"
[15:43] <james_w> so it can't be used
[15:43] <james_w> I don't know if there are more fundamental issues
[15:46] <Kamping_Kaiser> Is any special work required for a bzr 'head' branch?
[15:46] <Kamping_Kaiser> (in a configuration sense)
[15:47] <jelmer> james_w: should I file a bug?
[15:47] <james_w> Kamping_Kaiser: you might like to set "append_revisions_only", but other than that there isn't much
[15:48] <james_w> that's not required, it just enforces something that most people expect for a "head" branch
[15:48] <james_w> jelmer: bug 347755 I think
[15:48] <Kamping_Kaiser> james_w, thanks.
[15:49] <LarstiQ> whatever is a head branch?
[15:49] <jelmer> james_w: thanks
[15:49] <Kamping_Kaiser> LarstiQ, something I link to on a public site as a 'known working' rcs snapshot
[16:11] <LarstiQ> Kamping_Kaiser: ah ok, so not trunk if that isn't guaranteed to be known working
[16:12] <Kamping_Kaiser> LarstiQ, true, the wording on my part was bad.
[16:40] <gcerquant> I have a noob question: I just did a merge and have some conflicts. I understand the .OTHER files are the one from the branch I am merging into the branch I am working on. Could someone clarify what is the .BASE and .THIS?
[16:42] <awilkins> Can anyone tell me how to get the Nautilus integration going in bzr-gtk?
[16:42]  * awilkins installs the GNOME-python binding
[16:43]  * awilkins discovers they are already there
[16:44] <james_w> gcerquant: THIS is from the tree you merged in to
[16:44] <james_w> gcerquant: BASE is the common ancestor
[16:45] <gcerquant> But I branched a copy, worked on it, and then merged it back
[16:45] <gcerquant> shouldn't THIS and BASE be the same ?
[16:46] <awilkins> They won't be because if THIS and BASE were the same, there would be no conflict
[16:46] <awilkins> Which OS are you using?
[16:47] <gcerquant> Mac
[16:47] <gcerquant> ok, I get it
[16:47]  * awilkins doesn't know much about 3-way merge editors for Mac
[16:47] <vxnick> gcerquant: changesapp.com is good
[16:47] <gcerquant> I forgot I did a revert on the main branch
[16:47] <awilkins> I was going to suggest it might be easier if you open it in meld / TortoiseMerge / stuff
[16:47] <gcerquant> Changes.app is awesome, yes
[16:48] <gcerquant> thanks for your help
[16:48] <vxnick> gcerquant: you can also integrate it with bzr if you haven't already :)
[16:48] <gcerquant> I did :)
[16:49] <gcerquant> with this alias: diff = diff --using=chdiff
[16:49] <gcerquant> anything more efficient?
[16:50] <vxnick> gcerquant: add it your .bashrc file
[16:50] <vxnick> sorry
[16:50] <vxnick> ignore that
[16:51] <gcerquant> np
[16:51] <vxnick> gcerquant: ALIASES]
[16:51] <vxnick> chdiff = diff --using chdiff --diff-options --wait
[16:51] <vxnick> gcerquant: in ~/.bazaar/bazaar.conf
[16:51] <vxnick> [ALIASES] on the line above it
[16:51] <gcerquant> yep, that's what I have
[16:52] <gcerquant> except for the --wait options
[16:52] <gcerquant> what does it change?
[16:52] <james_w> --diff-options isn't passed to chdiff in that case is it?
[16:52] <vxnick> gcerquant: http://pastie.org/472261
[16:52] <vxnick> gcerquant: it means you can use "bzr chdiff"
[16:53] <vxnick> gcerquant: --wait means bzr halts until changes.app is quit
[16:53] <gcerquant> but unless I miss something, I prefer it without the wait
[16:53] <vxnick> fair enough :)
[16:54] <gcerquant> so I can open a diff, look at it in Changes, maybe do an other commands in my term (bzr conflicts, or just ls...)
[16:54] <vxnick> yeah
[16:54] <vxnick> I see your point
[16:54] <vxnick> I think I just copied/pasted the whole thing from the changes website
[16:54] <vxnick> it wasn't a conscious decision
[16:54] <gcerquant> :)
[16:55] <gcerquant> I had done a script for Changes in svn to edit the files in place, with the right name. So I could edit and save within Changes, and be done
[16:55] <gcerquant> might adapt it for bzr
[16:56] <gcerquant> vxnick, what do you develop for Mac?
[16:56] <vxnick> gcerquant: I just do web stuff - LAMP type stuff
[16:57] <awilkins> Here's a thought - could we use an "ignored" status change kind ; e.g. - you've got a file that you want to stop tracking, the only way being to `bzr rm --keep foo` and then `bzr ignore foo` ; unfortunately when others pull your revision this will delete their local copy of the file instead of just ignoring it.
[16:59] <awilkins> In other words, would tracking the use of `rm` vs `rm --keep` as separate types of change be useful (for me, yes).
[16:59] <vxnick> awilkins: I think that sounds sensible
[17:00] <vxnick> prevention is better than the cure ;)
[17:00] <awilkins> Specific example, using Maven with the eclipse plugin ; it generates .project files ; someone has added these to version control in error.
[17:00] <awilkins> I want to remove and ignore them without spoiling his day.
[17:00] <awilkins> Ok, he can just regenerate them :-)
[17:04] <gcerquant> http://paste.lisp.org/display/79905
[17:04] <gcerquant> It looks like my merge produce a conflict because I removed a new line.
[17:04] <gcerquant> Is this possible?
[17:04] <gcerquant> Is there an option for that?
[17:48] <gcerquant> I. Just. Love. Bazaar.
[17:49] <LeoNerd> .oO( "Get a roooom!" )   ;)
[17:49] <gcerquant> :-p
[17:50] <vxnick> I love it too - can't bring myself to use anything else :P
[17:50] <gcerquant> I have check other system, but bzr has the right approach for so many things it's a no-brainer decision
[17:51] <vxnick> yeah
[17:51] <vxnick> I *love* bzr uncommit ;)
[17:51] <gcerquant> can you unrevert as well?
[17:52] <gcerquant> I was once burned by this with svn (used an newly alias the wrong way. alias was deleted just after I finished crying)
[17:53] <LeoNerd> revert saves a backup copy of the modified files in the local checkout. I don't know if it has an automatic "unrevert" command, but you can just  mv foo.c.~1~ foo.c
[17:53] <LeoNerd> Though usually I use vimdiff between them
[17:54] <james_w> there is no unrevert
[17:54] <james_w> one day...
[17:57] <bialix> jelmer: are you around?
[17:57] <james_w> hi bialix
[17:57] <bialix> hi james_w
[18:00] <bialix> there is question about conversion from svn: http://stackoverflow.com/questions/839683/how-to-migrate-from-a-complicated-subversion-repository-to-a-distributed-version
[18:02] <bialix> jelmer: ^^
[18:06] <jelmer> bialix: answered
[18:08] <bialix> thx
[19:47] <Peng_> Haha, subunit switched from scons to autoconf *one day* after i installed scons specifically for it. :P
[19:47] <LarstiQ> make it switch back!
[19:50] <Peng_> Since I'm just using it for Python, I don't even need to compile it though.
[20:29] <LarstiQ> ronny: try again. I note http://paste.pocoo.org/show/116024/ doesn't include releases like 1.14.1
[20:30] <ronny> LarstiQ: yes, its a bit incomplete, its just a pretty generic guess
[20:30]  * LarstiQ nods
[20:30] <LarstiQ> ronny: you could try parsing http://pypi.python.org/simple/bzr or something like that
[20:31] <ronny> LarstiQ: i will probably put dealing with that in an actual py.test extension using the xmlrpc api or some code i worte for the pida plugin updates
[20:32]  * LarstiQ might want some code like that too
[20:32] <LarstiQ> ronny: anyway, for the releases in that script, they should now work :)
[20:33] <ronny> LarstiQ: i just wrote a scanner for the simple http pypi
[20:33] <ronny> its pretty nasty and just has some regex
[20:33] <ronny> it works semilar to things like easy_install and pip
[20:33] <ronny> #its just less smart
[20:34] <LarstiQ> right
[20:34]  * LarstiQ has read the easy_install code
[20:34] <LarstiQ> that's actually how I got to know about /simple/
[20:35] <ronny> i hope you didnt cry in tears of blood
[20:35] <LarstiQ> only a little bit
[20:35] <ronny> reading code by pje is a #1 health danger
[20:35] <ronny> well, luckyly hes now a self-refactoring guru and wont fuck up python any more
[20:37] <LarstiQ> he has had some good ideas tough
[20:38] <LarstiQ> mainly thinking of wsgi here
[20:45] <yam> quick ? - I want to look at a file from December in my bzr repo, and then go back to today's version
[20:45] <yam> possible?
[20:47] <jam> yam: bzr cat -r XXX file
[20:47] <jam> or bzr revert -r XXX file; bzr revert file
[20:51]  * LarstiQ thought yam was talking to himself
[20:51] <LarstiQ> jam: how are you doing?
[20:51] <jam> LarstiQ: I'm doing pretty good. how about you?
[20:51] <yam> Sorry, not talking to myself, trying it out - works!
[20:52] <LarstiQ> yam: I meant you and jam's nicks being very similar
[20:52] <yam> thank you kindly - I knew that IRC would be the answer I needed
[20:52] <LarstiQ> jam: feeling a bit ground by work and studying, but otherwise not unhappy
[20:53] <yam> LarstiQ: yam jam sounds pretty good, actually
[21:03] <andriijas> how do i remove a pending merge tips?
[21:03] <jelmer> andriijas: bzr revert --forget-merges
[21:04] <andriijas> thx
[21:26] <rellis_> HI everyone. I am seeing this bug https://bugs.launchpad.net/bzr-svn/+bug/373726. Has anyone else seen this, is there a nifty workaround?
[21:34] <LarstiQ> rellis_: I haven't seen that before, but it violates an invariant of bzr, I wonder how you got to that point.
[21:35] <LarstiQ> hmm, I can think of one way to do that.
[21:36] <psykidellic> Hi, I guess I am missing something very stupid in the docs. But how do you init a branch with an existing branch info?
[21:36] <jelmer> rellis_: hi
[21:36] <psykidellic> *init a new
[21:37] <jelmer> rellis_: I think this might be a bug that's fixed in 0.5.4, is there any chance you can try with that?
[21:37] <jelmer> rellis_: Is this repo publicly accessible?
[21:41] <LarstiQ> psykidellic: do you want a copy of the other branch? `bzr branch old new`
[21:41] <LarstiQ> psykidellic: if not, it is unclear to me what effect you're after
[21:55] <psykidellic> LarstiQ: We have a branch at: /bzr/project/branch..... . I created a new repo using: init-repo. I want to import project/brnach with all its history to the new repo.
[21:55] <psykidellic> *branch
[21:56] <LarstiQ> psykidellic: if it's one branch, just `bzr branch` it.
[21:56] <psykidellic> LarstiQ: Alright. And it will be added to repository when I push it first time.
[21:56] <LarstiQ> psykidellic: if I understand you correctly as having added a repository after deciding a standalone branch wasn't the way to go, `bzr reconfigure` might be handy.
[21:57] <psykidellic> LarstiQ: Exactly :)
[21:57] <LarstiQ> psykidellic: that's fine too
[21:57] <psykidellic> LarstiQ: You read my mind!
[21:57] <LarstiQ> psykidellic: specifically, `bzr reconfigure --use-shared` would have been of help to you
[21:58] <psykidellic> I have not yet branched to new one. I will look into reconfigure now.
[21:58] <psykidellic> Thanks.
[21:58]  * psykidellic goes back to docs.
[22:30] <lifeless> jelmer: bah, packaging fail. I'm fixing
[23:00] <lifeless> jelmer: all fixed now
[23:00] <lifeless> missing pkg-config build-dep
[23:00] <lifeless> Peng_: its packaged now
[23:00] <lifeless> launchpad.net/~subunit/+archive/ppa
[23:18] <xlax> Can anyone explain why I can't push any repo? I constantly get "Target directory xx already exists [...]" or "Generic path error"
[23:19] <xlax> Or permission denied errors are common too.
[23:22] <lifeless> xlax: are you pushing to launchpad?
[23:23] <xlax> lifeless: no, I'm trying my own (s)ftp solution.
[23:24] <xlax> Because I need the project to be private, and I didn't see any option for that in launchpad.
[23:24] <FurnaceBoy> hi all. is there a pure CLI way to achieve per-file commit messages? I'm using bzr on a headless box
[23:24] <lifeless> launchpad cann host private projects, but its for a fee.
[23:25] <lifeless> anyhow - Target directory xx already exists - means you've made a directory rather than having bzr push to a  new directory.
[23:25] <lifeless> either pass --use-existing-dir to push, or don't make the branch directories by hand
[23:25] <lifeless> the GPE I'd need to see a backtrace of - there will be one in ~/.bzr.log
[23:25] <xlax> lifeless: using --use-existing-dir will get me the GPE ^^
[23:25] <lifeless> FurnaceBoy: I don't think so
[23:26] <FurnaceBoy> lifeless, hm ok, thanks. just on a project whose policy encourages them.
[23:26] <Peng_> lifeless: Oh, nice. I've already set up running it from source, so I'm not sure I'll bother with the PPA though. Plus I don't run Jaunty.
[23:26] <lifeless> FurnaceBoy: you could use the python interface, or write aplugin to support it.
[23:26] <lifeless> FurnaceBoy: mainly a UI problem, its a lot easier to write that sort of thing in a gui
[23:26] <FurnaceBoy> lifeless, interesting!
[23:26] <FurnaceBoy> lifeless, I'll think about that. thankyou
[23:26] <lifeless> FurnaceBoy: feel free to file a bug saying you'd like it in the CLI
[23:27] <lifeless> Peng_: lenny?
[23:27] <FurnaceBoy> lifeless, is the main Bzr on lp?
[23:27] <Peng_> lifeless: Hardy. Plus Gutsy. :X
[23:27] <Peng_> (I'll upgrade soon i swear!)
[23:27] <lifeless> FurnaceBoy: http://launchpad.net/bzr
[23:27] <lifeless> Peng_: :)
[23:28] <FurnaceBoy> lifeless, ok, so if i wanted to write such a plugin, would i branch to do it? (sorry i'm new to bzr/lp)
[23:28] <lifeless> Peng_: hopefully jkakar will do the autoppa magic and I can upload gutsy and hardy too
[23:28] <lifeless> FurnaceBoy: well a plugin is a new separate project; so you'd start a new project, which would be a bzr plugin
[23:28] <Peng_> lifeless: Is creating gutsy packages even allowed anymore? It's not supported...
[23:28] <lifeless> FurnaceBoy: or you could just patch bzr itself; it might be easier in this particular case:- for that you would branch bzr, yes.
[23:29] <lifeless> Peng_: not sure.
[23:29] <lifeless> hardy is
[23:29] <xlax> Hmm. It seems my host has an odd way of calling its directories...
[23:29] <jkakar> lifeless: AutoPPA magic for Bazaar?
[23:29] <lifeless> jkakar: subunit
[23:29] <lifeless> jkakar: (hi)
[23:29] <jkakar> lifeless: Ah, okay, yeah, I should finish that since it's already half done.  Hi! :)
[23:30] <lifeless> jkakar: I've done C/python/tools/C-dev packages
[23:30] <jkakar> lifeless: I noticed that.  I'll see if I can review/integrate your changes sometime this weekend.
[23:30] <lifeless> jkakar: they're built https://edge.launchpad.net/~subunit/+archive/ppa and code is https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases
[23:31] <jelmer> lifeless: btw, the last entry in changelog is by robertc@lifelessdesktop
[23:31] <lifeless> debian/changelog?
[23:31] <lifeless> meh, I haven't set DEBFULLNAME and DEBEMAIL yet on that machine
[23:32] <jelmer> lifeless: ah
[23:32] <lifeless> my desktop went bang
[23:32] <lifeless> I have a new i7 920 :)
[23:32] <jelmer> lifeless: also, any chance you can use 0.0.1~bzr65 for the upstream version? That way bzr-builddeb can Do The Right thing at some point
[23:33] <jelmer> lifeless: what's an i7 ?
[23:33] <lifeless> 4-core, 8 hyperthreadedvcpu's goodness
[23:33] <jelmer> lifeless: nice
[23:33] <lifeless> intels current gamer/workstation cpu
[23:34] <lifeless> jelmer: I used - deliberately
[23:34] <jelmer> lifeless: why the - ?
[23:34] <lifeless> jelmer: its an upstream release
[23:34] <lifeless> not on the path to 0.0.1, after 0.0.1
[23:35] <lifeless> we could use 0.0.2~bzr65 if we wanted
[23:35] <jelmer> lifeless: so it's actually 0.0.1 ? or just a snapshot after 0.0.1 ?
[23:35] <lifeless> the latter
[23:35] <jelmer> lifeless: what about 0.0.1+bzr65 ?
[23:35] <jelmer> I guess we could also get bzr-builddeb to support something like 0.0.1-bzr65 though
[23:35] <lifeless> bzr-builddeb should support it
[23:36] <lifeless> in terms of parsing etc, its legit
[23:36] <jelmer> lifeless: it might be confusing for native packages though
[23:36] <lifeless> no, if foo-x-y, -y is debian revision, -x is part of upstream version
[23:37] <lifeless> jkakar: overview is 'used autoconf to get a soname, and after that its stock debhelper magic mostly'
[23:37] <lifeless> jkakar: the thing that you could do that would be nice is get it working with autoppa for future release builds
[23:37] <jelmer> lifeless: what I mean is that it makes parsing the version string harder for bzr-builddeb
[23:38] <lifeless> jelmer: it should be getting parsed by python-dpkg anyhow ;)
[23:38] <lifeless> jelmer: which DTRT
[23:38] <lifeless> if it does make it harder, well I'm not married to this
[23:38] <james_w> python-apt, but yeah
[23:39] <lifeless> hi :)
[23:39] <lifeless> james_w: I went with -f on autoreconf
[23:39] <james_w> it should work with two -, but is currently broken, fixed in the 2.1 branch
[23:39] <lifeless> datestamps and patches, eww.
[23:39] <james_w> lifeless: cool
[23:39] <james_w> plus, it doesn't care if you create a native package with - in it
[23:39] <jkakar> lifeless: Cool, that shouldn't be hard.
[23:40] <james_w> hi jkakar
[23:40] <jkakar> Heya james_w! :)
[23:40] <james_w> jkakar: did you know that launchpad will soon support uploads with a target of "hardy intrepid jaunty"?
[23:40] <lifeless> jkakar: I'd like to keep two packaging branches. One 'official' this-is-packaged-for-$distro [debian with flow-down to ubuntu for now], and one 'upstream' this-is-ppa-magic.
[23:41] <lifeless> jkakar: the ppa one should descend from the official one
[23:41] <jkakar> lifeless: Cool, that makes sense.
[23:41] <lifeless> james_w: awesome
[23:41] <jkakar> james_w: I didn't, no.  That sounds pretty awesome.
[23:41] <james_w> yeah, it removes the simple case that autoppa solves
[23:42] <james_w> then you should just write your package so the same source works on multiple distributions :-)
[23:42] <jelmer> james_w: that's awesome
[23:42] <jkakar> james_w: Well, sort of.  That's only half of the case AutoPPA solves--the other half is providing some simple templating so that slightly different control files and such can be used for each build.
[23:42] <james_w> also, you two may be interested in https://launchpad.net/bzr-builder that I wrote
[23:43] <james_w> jkakar: yeah, but that's rarely required, though can often be nice to have
[23:43] <jkakar> james_w: Really?  I probably just don't know enough about packaging, but that seems to be required for every single project I've packaged (which is like 4 things).
[23:44] <lifeless> james_w: you've reinvented config-manager ;)
[23:44] <jkakar> james_w: For example, on dapper my Python libraries need to Build-Depends on python-support, whereas on newer releases they need to Build-Depends on python-central.
[23:44] <jkakar> james_w: The same kind of problem crops up when you need to depend on version 1.1 of libfoo on dapper and 1.2 on hardy.
[23:44] <james_w> lifeless: yeah
[23:45] <jkakar> james_w: Anyway, I really hope it is rarely needed... it'd be great for AutoPPA to be killable.
[23:45] <james_w> jkakar: yeah, Build-Depends is the main case. Depends you can do from within the package
[23:45] <james_w> python-central isn't something you can do with an "|" though, unless you are really sneaky
[23:46] <Peng_> Would it make sense for the SMP test stuff to use the multiprocessing module? Nose does, Or So I Heard.
[23:46] <james_w> Build-Depends: package-that-only-exists-in-dapper | python-central
[23:46] <lifeless> Peng_: no
[23:47] <lifeless> Peng_: we want full isolation ;)
[23:47] <james_w> so http://bazaar.launchpad.net/~dailydebs-team/bzr-builder/cookbook/annotate/head%3A/bzr/jaunty.recipe is what controls what is uploaded to the jaunty nightly PPA now
[23:47] <james_w> lifeless: the plan is apparently to integrate this with launchpad
[23:48] <lifeless> back in a bit
[23:48] <jelmer> james_w: what's advantage of bzr-builder and nested trees (when they land..)
[23:48] <jelmer> james_w: ?
[23:48] <Peng_> lifeless: I don't know what that means, but okay. :D
[23:48]  * Peng_ doesn't know a thing about multiprocessing.
[23:49] <james_w> jelmer: I don't know how it will work with nested trees, it will probably do a join there I guess
[23:49] <james_w> jelmer: I just throw away the created tree at the moment, so I don't really care
[23:49] <james_w> it does mean that it can't use bzr-builddeb currently, which nested trees would allow us to do
[23:50] <james_w> lifeless: oh, I also tested a larger package earlier. A chunk of nautilus was 2 minutes to branch, 30 seconds to apt-get
[23:59] <lifeless> james_w: not a great ratio
[23:59] <lifeless> james_w: but better than the past