[00:00] <lifeless> jam: yes, thats my thoughts too
[00:00] <lifeless> jam: want to work up a patch, or shall I?
[00:01] <lifeless> the packing heuristics still bother the heck out of me
[00:01] <jam> obviously I won't have time to do so today... :)
[00:01] <lifeless> :P
[00:01] <jam> "packing heuristics"?
[00:01] <lifeless> I'm still looking at this critical bug today I expect
[00:01] <lifeless> keys to nodes
[00:01] <lifeless> the gzip magic
[00:01] <jam> ah, that part
[00:01] <jam> well, we can punt on it
[00:01] <poolie> jam, spiv, hi
[00:01] <jam> but it is fairly useful
[00:02] <lifeless> jam: its needed I think
[00:02] <jam> hi poolie
[00:02] <lifeless> jam: but its gets very bad on bzr-search indices
[00:02] <jam> IIRC it shrunk them by a significant amount
[00:02] <jam> lifeless: how long are your bzr-search keys?
[00:02] <lifeless> jam: tiny
[00:02] <lifeless> jam: 4, 5 bytes
[00:02] <jam> the pack work was certainly tuned around 60-byte keys, and often 120 bytes as tuples
[00:03] <lifeless> the keys are document ids
[00:03] <lifeless> e.g. '1'
[00:03] <lifeless> well, ('1',)
[00:03] <spiv> Good morning.
[00:03] <poolie> jam, merging from BB urls was working for me on monday
[00:03] <jam> poolie: it seems to be a BB thing
[00:03] <jam> as BB is giving a 200 OK, Status: 404 results
[00:03] <mwhudson> beuno: hm you said something about making the breadcrumb stuff less inventory specific
[00:03] <poolie> make up your mind :)
[00:03] <mwhudson> beuno: did you get to that?
[00:03] <jam> so something is confused about the return code
[00:03] <mwhudson> spiv: hello
[00:04] <jam> I don't know HTTP well enough to know if "Status: " is supposed to overwride
[00:04] <beuno> mwhudson, no, I didn't. I left that for after we fixed the root issue
[00:04] <lifeless> jam: so, inventories
[00:04] <mwhudson> beuno: hmm
[00:04] <lifeless> jam: I mailed,  you replied - is it paused now ?
[00:05] <lifeless> hi poolie
[00:05] <jam> lifeless: today was painting the deck redux
[00:05] <jam> I want to follow up
[00:07] <spiv> mwhudson: hi
[00:08] <lifeless> jam: ok
[00:09] <lifeless> jam: I'd like that
[00:22] <mwhudson> beuno: http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/209
[00:23] <beuno> mwhudson, I knew you'd find a simpe way around it  :)
[00:23] <mwhudson> it's a bit of a hack, but then hey! it's loggerhead
[00:24] <mwhudson> at least it's a localized hack
[00:24] <beuno> hahaha
[00:24] <aquarius> I'm a bit confused by bzr init and init-repo. I'd like to store my home folder on my laptop in bzr, with a centralised repo on a remote sftp server (so I can check out from there to other machines).
[00:25] <james_w> hey aquarius
[00:25] <james_w> you probably don't need init-repo in that case
[00:25] <aquarius> ah. I'm not clear what the difference between init-repo and init is...
[00:26] <james_w> you may want it on the server if you are going to have branches "desktop" and "laptop" that are slightly different and you merge between them
[00:26] <beuno> mwhudson, so you think it's ready for merging, or do you want me to have another look at it?
[00:26] <james_w> but I doubt you'll be making feature branches on your laptop to try out experimental new settings
[00:26] <james_w> hey besonen_mobile__
[00:26] <aquarius> so can I just, on the laptop, do "bzr init sftp://server; bzr checkout sftp://server $HOME" ?
[00:26] <james_w> hey beuno
[00:26] <beuno> hey james_w, how are you?
[00:26] <mwhudson> beuno: which?  directory_breadcrumbs? no
[00:26] <james_w> good thanks beuno, you?
[00:26] <james_w> enjoying work?
[00:27] <aquarius> james_w: for the moment, assume that I want all checkouts to be identical on every machine. (I may add cleverness later. :))
[00:27] <james_w> aquarius: that will work in principle, though it would probably fail as $HOME already exists
[00:27] <beuno> james_w, good good, enjoying it very much, yes  :)
[00:27] <james_w> aquarius: you probably want to create the branch locally and then push to the server
[00:27] <james_w> beuno: cool :-)
[00:28] <aquarius> james_w: OK...see, now I'm confused again. How do I do that, then? :)
[00:28] <james_w> aquarius: "cd $HOME; bzr init; bzr add <files you want to version>; bzr commit; bzr push sftp://server/" or similar
[00:29] <james_w> aquarius: plain "bzr add" is probably not what you want, so I would avoid that.
[00:29] <james_w> judicious use of "bzr ignore" will probably help you avoid problems
[00:29] <aquarius> james_w: excellent. A few questions. can I just do plain "bzr add" if I already have a .bzrignore file that correctly ignores the stuff I want to ignore?
[00:29] <james_w> unless you actually aim to version ~/Videos/ and ~/Music/
[00:30] <aquarius> second: does sftp://server/whatever/I/put have to exist before I push to it, or will push create it if it doesn't exist?
[00:30] <james_w> aquarius: yeah, if you've set up ignores then bzr add won't add them. If you "bzr add <something you've got in .bzrignore>" then it will be added
[00:30] <aquarius> *nod* win
[00:31] <james_w> aquarius: no, it doesn't have to exist, but if sftp://server/whatever/I doesn't exist then you will need --create-prefix
[00:31] <aquarius> third: once I've done all that, on machine2 can I just "cd $HOME; bzr checkout sftp://wherever/ ." ?
[00:32] <aquarius> fourthly: imagine that I'd tried to do all this a couple of weeks ago and got it wrong (this is why i have a .bzrignore file). If I just remove $HOME/.bzr then all my previous screwups are eliminated, yes? bzr doesn't keep my info anywhere else magic?
[00:32] <james_w> in principle, but again, I think it will fail due to . existing, though it's probably worth a try
[00:32] <aquarius> *nod*
[00:33] <james_w> a workaround is to checkout in to a tempdir, then move .bzr from that tempdir to $HOME
[00:33] <james_w> you will also need to move any files not already on the machine from the tempdir
[00:33] <james_w> just running "bzr diff" will tell you what is missing and modified
[00:33] <aquarius> final question (you've been really helpful!): if I want to work on other projects hosted in bzr (say, a project currently in launchpad) and I grab a branch into $HOME/Projects or similar -- is this going to screw up because I'm putting one bzr project inside another?
[00:33] <james_w> you can add anything else you like of course
[00:34] <james_w> 4) there's no secret hidden stuff, so removing .bzr should be enough
[00:34] <james_w> the exception would be if you had run "bzr init-repo ." in / or /home, which is very unlikely
[00:35] <aquarius> nah, I didn't do that :)
[00:35] <james_w> you can check "bzr info" output before removing the old .bzr to make sure
[00:35] <james_w> finally, no that's not a problem.
[00:35] <james_w> let me find you a reference on what init-repo actually is
[00:40] <james_w> aquarius: does http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#repositories explain what "init-repo" is for sufficiently?
[00:41] <aquarius> james_w: sorta, yeah. So if I'm not doing multiple branches then I don't need init-repo at all.
[00:42] <james_w> aquarius: yeah, that's the main point for you in this case
[00:42] <aquarius> right, ok. makes a bit more sense now, I think :)
[00:42] <james_w> but if you do work on a project and use multiple branches for it, then shared repositories (in the bzr sense) are a big win
[00:44] <aquarius> *nod* I can imagine.
[00:45] <aquarius> if I don't create a shared repo now (on my sftp server) and later wish I had created one after all, can I take the existing pushed-to repo and "upgrade" it to be a shared one?
[00:46] <james_w> aquarius: yup, see the reconfigure command
[00:46] <aquarius> coolness. so, it sounds to me like doing it the simple way first is the best plan and then being more complex later if I need to will work :)
[00:47] <james_w> aquarius: I've never done it myself, so I can't give you the recipe, but if you do come to need it then swing back here and someone will be able to help
[00:49] <markh> lifeless: fyi, that samba issue yesterday turns out to be fairly non-deterministic - it randomly fails and works without the additional gc.collect().  Would it be useful to keep it added and to try and determine if it ever fails *with* it?
[00:50] <lifeless> markh: well its not a 'solution'
[00:50] <lifeless> markh: but if we can track down an actual cause - ftw
[00:51] <markh> yeah, hence me not knowing if that avenue is worth spending more time on...
[00:53] <markh> I figure than in the short-term, if we can get everything working correctly on native windows (ie, no attempts to move/delete open files), then we can be fairly confident we aren't leaking such handles in a major way.  Which led to me looking at those test failures yesterday I submitted a patch for
[00:58] <lifeless> right
[01:19] <beuno> mwhudson, bundle branch up for review. Is pickscrape's branch ready?  Do you want me to merge it?
[01:19] <mwhudson> beuno: it should have breadcrumbs on all pages
[01:19] <pickscrape> beuno: once the branch root problem is solved I need to apply it to a few other pages before it should be merged
[01:20] <mwhudson> and the last 'crumb' shouldn't be a link
[01:20] <beuno> pickscrape, lp:~mwhudson/loggerhead/directory_breadcrumbs
[01:20] <beuno> it's fixed
[01:20] <mwhudson> and we should think about how it interacts with the --user stuff
[01:20] <mwhudson> but perhaps that's less important
[01:20] <beuno> ok, so a few more things to chew before
[01:21]  * beuno is going office -> home   bbiab
[01:21] <pickscrape> mwhudson: excellent, thanks!
[01:22] <pickscrape> I'll get to spreading that feature out to other pages as soon as I can
[01:26] <mwhudson> pickscrape: cool
[01:26] <mwhudson> pickscrape: please try to find some way of extracting the common code, not copy+paste :)
[01:56] <Toksyuryel> That seems like bad advice, except the last one.
[01:59] <mwhudson> Toksyuryel: ?
[02:00] <Toksyuryel> komputes's quitline
[02:00] <mwhudson> oh
[02:00]  * mwhudson has mental filters for those
[02:00] <Toksyuryel> heh
[02:04] <poolie> markh, it would be interesting to do a test transport decorator that forbids moving/deleting open files
[02:05] <markh> yeah, that would be cool.  How would it work?  monkeypatching?
[02:05] <lifeless> wouldn't help with tree transform stuff
[02:06] <lifeless> but I don't think we actually do that; I think its more reference leaks and the like due to slack gc
[02:07] <markh> I think most of the problems I found last night were caused by exceptions keeping files alive slightly longer than normal.
[02:07] <poolie> that's true it won't particularly help with tree transform
[02:07] <markh> and most of these were fairly close to the "surface" of the API - so its only a problem in practice for a single process doing multiple bzr "commands" before terminating - eg, the test suite.
[02:08] <poolie> i guess you could either monkeypatch or otherwise intercept file open/close
[02:08] <markh> ie, I haven't yet found a problem a user of normal 'bzr' would see.
[02:08] <poolie> oh i see
[02:10] <markh> there is actually one strange bit of code in a decorator that might be responsible for the exception causing the cycle - lemme find it
[02:12] <markh> decorators._fast_needs_read_lock() - it has a try/except/raise construct where a try/finally appears more logical.  Keeping the traceback alive in a local variable is potentially a cycle that wouldn't otherwise exist.
[02:13] <poolie> i was thinking of something similar but a bit different, which is catching on unix problems that might break windows
[02:13] <markh> the fact the name includes "_fast" though makes we worry someone has benchmarked things or something and found that to be faster
[02:13] <poolie> specifically relating to transport/control file stuff
[02:13] <markh> yes, I think that would be beneficial
[02:13] <poolie> see for example fakevfat.py
[02:13] <lifeless> markh: the fast refers to docstrings
[02:13] <markh> similarly for locks ;)  Was there some conclusion to that?
[02:13] <lifeless> markh: and the like
[02:13] <lifeless> markh: did you read the dirstate RFC I posted a few days back
[02:14] <markh> lifeless: regarding the ability to avoid locks in many cases?
[02:14] <lifeless> yes
[02:14] <poolie> it seems to me we want to run most tests with the lowest-common-denominator transport...
[02:15] <markh> lifeless: it sounds good to me, but I have to admit the conversation was a little too far over my head to make any meaningful contribution :s
[02:15] <lifeless> I think we should run the entirely in memory - but we can make that as low as we want
[02:15] <jml> hmm. running bzr selftest --no-plugins only drops about 700 tests compared to the full suite for me.
[02:16]  * jml should write more tests for his plugins
[02:17] <markh> poolie: fakevfat does seem to be the way to approach it
[02:17] <markh> they even list that as the first feature to be added ;)
[02:18] <poolie> i don't know if there are any interesting behaviours in ntfs that wouldn't occur on vfat
[02:18] <poolie> lifeless, i'd think we should gradually go to running on vfat+memory
[02:19] <poolie> it would be interesting to profile how many tests use which transport class
[02:19] <markh> not many we use.  ntfs has recently grown links
[02:20] <lifeless> poolie: ntfs won't do things worse for us than vfat
[02:20] <markh> but - back to the locks in the short term.  Many tests on windows are failing due to an assumption locks are not exclusive - any ideas about how to handle that in the short term?  Just leave them failing?
[02:20] <lifeless> poolie: it simply has additional capabilities we could use if we wanted [but generally explorer dies in the arse if you use them, so we shouldn't]
[02:21] <lifeless> markh: its in the definition of behaviour for that tree type; I don't know that there is much we can do
[02:21] <poolie> sure
[02:21] <poolie> lifeless, i was thinking of things like unicode handling
[02:21] <poolie> it may not differ meaningfully to us
[02:21] <markh> we could arrange for them to be either skipped or known failures if it was worth the bother, and if it wasn't going to stay that way for the long term :)
[02:21] <poolie> at any rate the code that's affected should mostly not use transports
[02:21] <lifeless> vfat is the same as NTFS for unicode to all intents and purposes -
[02:22] <poolie> markh, so one approach here is to avoid having two objects addressing the same file
[02:22] <lifeless> poolie: so, tree rules, whats the outcome there?
[02:22] <poolie> we're seeing the conflict aaiu because we have that aliasing
[02:23] <markh> I'm still not sure of the impact of the locks - do_merge is being called by the test suite with the same dir - are there real user scenarios that would hit this?
[02:24] <lifeless> markh: yes
[02:24] <lifeless> markh: I answered that yesterday FWIW
[02:24] <markh> oops
[02:24]  * markh scrolls back...
[02:24] <poolie> lifeless, well, i think we should still do what i said: remove the code that reads it
[02:24] <poolie> unless someone proposed an alternative?
[02:25] <lifeless> its a real bug, it causes problems and its not amenable to changes without changing the format, because of old bzr clients
[02:25] <poolie> lifeless, re _buffer_all, would those repos have also OOM'd in 1.5?
[02:25] <lifeless> poolie: no, just hadn't got the go-ahead
[02:25] <lifeless> poolie: yes, but they won't in 1.6
[02:25] <lifeless> unless we start triggering _buffer_all
[02:26] <poolie> but at the price of getting substantially slower for things that currently _do_ work
[02:26] <lifeless> yes
[02:26] <lifeless> constraints and accomodations again
[02:28] <poolie> lifeless, i had in mind to make the api just something like _readahead_hint('per_file_graph')
[02:29] <poolie> or 'per_file_log'
[02:29] <poolie> then those repos in this release can buffer everything, but there's no implied promise it's doing so
[02:29] <jml> lifeless: btw, I was looking around the test scenario stuff. It seems that objects in the scenario dict are shared between tests?
[02:30] <lifeless> jml: bzr's scenarios?
[02:30] <lifeless> jml: the parameterisation stuff ?
[02:30] <poolie> markh, re do_merge, i didn't see lifeless's specific answer but it seems possible
[02:31] <poolie> but, i would think that locking the same object twice should not be a problem- it will just increment the internal counter
[02:31] <markh> I looked and failed to find his specific answer too :)
[02:31] <poolie> the problem we want to avoid is having two objects pointing to the same file
[02:31] <markh> 2 different objects involved IIRC
[02:31] <lifeless> markh: it wasn't as detailed as I just gave
[02:31] <poolie> if you can do that, there should be no problem with locks being exclusive or not
[02:31] <lifeless> the case it occurs for users is when the working tree is two of the coordinates in a merge operation
[02:31] <lifeless> one readonly one write, it will self-exclude on windows
[02:32] <poolie> if this is only happening in tests not in real use this may be a problem of, say
[02:32] <poolie> an api that implicitly opens a wt when it should allow the object to be passed in
[02:32] <poolie> jml, in the scenario they're just directly assigned to the test object
[02:32] <poolie> they're typically strings or valueobjects
[02:33] <poolie> if you pass a mutable object then yes, it may cause contamination between tests
[02:33] <lifeless> jml: we could deep copy to actively prevent bugs
[02:33] <poolie> which would be bad ;-)
[02:33] <lifeless> jml: but we've never had mutated objects there to day
[02:33] <jml> right.
[02:33] <poolie> lifeless, that kinda sounds like an accomodation ;-)
[02:33] <jml> I guess you guys use format specifiers and the like.
[02:33] <lifeless> poolie: python doesn't have 'const' :)
[02:33] <poolie> i mean it's pythonic to have mutable objects and tell people to use them carefully
[02:33] <lifeless> poolie: its also slow
[02:34] <lifeless> and many other things; we accomodate all the time
[02:34] <poolie> lifeless, slow to copy?
[02:34] <lifeless> poolie: just slow :>
[02:34] <poolie> anyhow there's no guarantee that deep copy would work correctly on arbitrary objects
[02:34] <lifeless> actually there is
[02:34] <poolie> oh you're agreeing?
[02:34] <mwhudson> sockets, for example :)
[02:34] <lifeless> there is a deep copy protocol
[02:34]  * markh wonders why the merge code can't detect the same tree is being used and not bother taking the second read lock...
[02:35] <jml> so, I'm thinking that I want to do something a lot like what TestScenarioApplier does, except have it take a scenario *factory*
[02:35] <lifeless> jml: pass the factory in as the scenario
[02:35] <lifeless> jml: ?
[02:35] <jml> lifeless: right, that's what I'll do in the short term.
[02:35] <lifeless> jml: whats the use case?
[02:35] <poolie> jml, for instance, just put a callable as the scenario parameter
[02:35] <poolie> or a class
[02:35] <poolie> (which is a callable of course)
[02:35] <lifeless> we pass in factories all the time
[02:35] <jml> poolie: right, that's what I'll do in the short term.
[02:36] <poolie> jml, this would be worth documenting though
[02:36] <lifeless> so I'm keen to understand the use case that makes you think of this as a short term solution
[02:36] <lifeless> rather than the right solution
[02:36] <poolie> want to send a one-para patch to the hacking file?
[02:36] <jml> poolie: maybe a bit later -- after I've successfully used it.
[02:36] <poolie> markh, having two objects and not locking one of them would be risky
[02:37] <poolie> also probably futile as the object might implicitly lock itself
[02:37] <poolie> however, saying 'oh these should be the same object i'll fix them up' would be,
[02:37] <jml> lifeless: it's short term because in the slightly longer term I want to try doing things my way and see if it's better :)
[02:37] <lifeless> jml: there are many varied examples in bzrlib; I'd be delighted to help you choose a good one to cult from
[02:37] <poolie> um, maybe not optimal but worth looking at
[02:37] <poolie> jml, lifeless, i was wondering whether it is really tasteful to have the scenario written into arbitrary test attributes
[02:37] <poolie> rather than .scenario
[02:38] <lifeless> jml: so we started with a fully general thing that was called per function if I remember correctly
[02:38] <poolie> for instance
[02:38] <markh> poolie: but if its an oslock, its only purpose is to keep others out isn't it?  And as we work correctly when the locks aren't exclusive, I don't see much risk.  But I'm sure I'm just blinkered :)
[02:38] <lifeless> poolie: I think its tasteful; you can always have a scenario that puts everything on .scenario
[02:38]  * jml disagrees
[02:38] <jml> but taste is a matter of... taste.
[02:39] <lifeless> jml: which statement do you disagree with ?
[02:39] <markh> I can imagine all the decorators failing though...
[02:39] <poolie> markh, you might get two in-memory objects that are out of sync with each other
[02:39] <lifeless> markh: no, they are exclusive
[02:39] <poolie> but, presumably it already has to deal with this on unix
[02:39] <jml> lifeless: I disagree that it's tasteful.
[02:39] <lifeless> jml: to write to any attribute?
[02:39] <markh> yeah - that's what I'm a little lost with still...
[02:39] <jml> lifeless: yeah.
[02:40] <lifeless> markh: so, on unix they are exclusive *cross process*
[02:40] <poolie> markh, btw, today's my last day here, do you want to catch up?
[02:40] <lifeless> markh: its a special case that it doesn't exclude the same process
[02:40] <poolie> i do have a bunch to do
[02:40] <markh> lifeless: right - so in process you could theoretically detect and avoid 2 locks on the same file?
[02:40] <lifeless> markh: not locking would allow two bzr processes to stamp on each other on windows *as well* as allowing a single-process to behave as bzr on linux does
[02:41] <markh> but I'm only saying not to lock when we already have a write lock
[02:41] <lifeless> markh: I guess you could reinstate the global dict we used to have
[02:41] <lifeless> markh: but IIRC we took it out cause it caused other bugs
[02:41] <markh> but why not just compare paths, and if we already have a write lock on the same path, just don't take the read lock.  Could theoretiucally be all detected in do_merge
[02:42] <poolie> lifeless, do you agree that the general approach is to try to have one in-memory object corresponding to each real-world or fs object?
[02:42] <lifeless> jml: I think forcing the core code to only write to one attribute is not treating callers like adults; and it doesn't stop people having all the issues arbitrary attributes have in micro
[02:42] <lifeless> poolie: no, I don't agree with that
[02:42] <poolie> ok
[02:42] <markh> it would just solve the problem for a single "Merger" object, that that seems the only real use case that its a real problem with
[02:42] <lifeless> poolie: I think its good when we do that but aliasing can trivially stop that working, so we need to be correct regardless
[02:43] <lifeless> poolie: consider z: and f: mapped to the same SMB drive, for instance.
[02:43] <poolie> sure
[02:43] <lifeless> jml: I will agree that as a convention having stuff on .scenario is good for documentation and predictability; but thats up a layer in the 'userspace' of the facility
[02:44] <lifeless> markh: I think we should just fix the underlying bug and issue a new recommended format for windows
[02:45] <jml> lifeless: well, actually, I think that the nicest way would be to call a method on the test.
[02:45] <lifeless> jml: to set stuff?
[02:45] <jml> lifeless: yes.
[02:45] <lifeless> jml: kind of like _setattr_ but different?
[02:45] <jml> lifeless: kind of like setScenario(scenario)
[02:46] <lifeless> jml: I think that would be great; I also want python unittest compatibility
[02:46] <lifeless> jml: but doing a getattr for setScenario first would be fine IMO
[02:46] <jml> lifeless: of course, then the way you set attributes would have to match whatever the default implementation of setScenario does.
[02:47] <poolie> jml, that seems pretty close to just poking into .scenario_* then letting setUp() run...
[02:48] <poolie> lifeless, yeah i was thinking of .scenario* just as a convention not a requirement
[02:48] <jml> poolie: well, the difference is that the test decides what to do with the scenario.
[02:48] <lifeless> jml: yes, but hopefully both are in the same codebase
[02:49] <jml> lifeless: I've got use cases for doing otherwise.
[02:49] <lifeless> jml: you're making me guess here
[02:49] <poolie> i guess in my experience it's often just storing them
[02:49] <poolie> but your cases would be interesting
[02:49] <jml> lifeless: bzr plugins
[02:50] <jml> lifeless: like bzr-loom
[02:50] <poolie> jml, out of curiousity, did addCleanup go from bzrlib to pyunit3k?
[02:50] <jml> wait, wrong example
[02:50] <jml> poolie: no.
[02:50] <markh> lifeless: I'm not sure exactly what the bug is?  I got the impression from yesterday that they were *intended* to be exclusive?
[02:50] <jml> poolie: I implemented addCleanup using test-driven development for Twisted and then re-implemented it with TDD as a patch to Python
[02:50] <jml> poolie: the one in pyunit3k is from the latter.
[02:50] <lifeless> markh: WT4 is designed with a built in flaw; its a design bug we need to fix
[02:51] <markh> and that would impact the recommended default format for windows?
[02:51] <jml> poolie: the addCleanup in bzrlib isn't tested, per se.
[02:51] <lifeless> markh: for everyone
[02:51] <markh> or you mean we'd end up with a wt5?
[02:51] <markh> right
[02:51] <poolie> really?
[02:51] <lifeless> wt5
[02:51] <jml> poolie: really no tests.
[02:52] <lifeless> markh: 'bzr commit' -> opens editor
[02:52] <lifeless> in the editor, !bzr diff, or similar
[02:52] <lifeless> -> FAIL
[02:52] <markh> right - you mean implement your RFC?
[02:52] <lifeless> yes
[02:52] <markh> gotchya - cool
[02:54] <markh> which will still leave us with the longer term problem of how to disable the existing tests once this new wt comes out - the old tests aren't going away...
[02:54] <jml> poolie: the Twisted one allows cleanups to return Deferreds and ensures they are run in serial, fwiw.
[02:54] <markh> disable on windows
[02:54] <markh> but that can wait ;)
[02:54] <jml> poolie: and as such is way more complex than any other implementation I've seen.
[02:54] <poolie> jml, i meant did the idea come from bzrlib or was it independent reinvention
[02:55] <jml> poolie: oh, the idea is from bzrlib.
[02:55] <lifeless> markh: we'd add a feature
[02:55] <lifeless> markh: and requireFeature those tests
[02:55] <markh> ahh - nice clue - thanks!
[02:55] <jml> poolie: in fact, I don't know of anyone else who's done it apart from bzrlib and myself.
[02:55] <lifeless> the feature would be something like
[02:56] <lifeless> BrokenInProcessLocksFeature
[02:56] <lifeless> jml: I think that bzrlib is one of the drivers of testing facilities in unittest tests in python
[02:56] <poolie> let's use a more specific word than 'Broken'
[02:57] <lifeless> jml: other than e.g. nose which seems half cool half terminally confused
[02:57] <lifeless> poolie: :)
[02:57] <lifeless> poolie: I tried to think of one, to represent what linux os locks do
[02:57] <lifeless> poolie: but nothing other than 'fucked' and 'broken' came to mind
[02:57] <lifeless> so I went polite
 don't goof off too much
[02:57] <poolie> ^^ at me laughing at you
[02:57] <markh> :)
[02:57] <lifeless> :)
[02:57] <jml> lifeless: well...
[02:58] <jml> lifeless: Twisted and Zope have both explored new testing territory.
[02:58] <poolie> ProcessWideFileLocks
[02:58] <jml> lifeless: Zope, for example, has definitively shown that layers are a terrible idea.
[02:58] <poolie> jml, congratulations on the user reviews of the code review feature!
[02:58] <jml> lifeless: that's progress.
[02:59] <poolie> markh, so do you need anything from me before i go?
[02:59] <poolie> (at about 5pm today)
[02:59] <poolie> it looked like the questions about packaging were fairly well answered?
[03:00] <markh> poolie: yeah, thanks.  Over that period I ill have binaries available and I'm not sure what I should do with them exactly :)  Current plan is to mail the mailing list and host them on that starship server I have access to.  Anything else I should do with them while you are gone?
[03:01] <poolie> you can put them up as file downloads on launchpad?
[03:01] <poolie> s//can't you/
[03:01] <poolie> you might need to join the right team there...
[03:01] <markh> yeah - will that give them much visibility?
[03:01] <poolie> https://edge.launchpad.net/bzr/+download
[03:02] <markh> yeah - that's what I'm thinking - I'm still a total newb with launchpad
[03:02] <poolie> and then link them from the /Download page on the main site
[03:02] <poolie> do you get an 'add download file' link there?
[03:02] <markh> the fact mailing lists were attached to teams is what threw me before
[03:02] <lifeless> jml: :)
[03:02] <lifeless> jml: I meant positive directions
[03:02] <lifeless> jml: we're still on for sunday?
[03:02] <poolie> markh, yeah that's one of those possibly too clever ideas
[03:02] <jml> lifeless: I thought it was Saturday
[03:02] <lifeless> jml: ah yes, it is
[03:03] <lifeless> I was thinking with my wow-addict-hat for a second
[03:03] <lifeless> jml: btw, can you log in sometime and hit return on the stuff in your mailbox ;)
[03:03] <markh> poolie: no "add download file" link
[03:03] <jml> lifeless: to which machine?
[03:04] <poolie> what's your lp userid?
[03:04] <lifeless> caelstraz
[03:04] <markh> mhammond
[03:04] <poolie> lifeless, jml, i assume you wouldn't object to me adding him to ~bzr?
[03:04] <lifeless> not at all
[03:05] <lifeless> though perhaps you meant jam & abently there :)
[03:05] <jml> lifeless: oh, right. I guess so.
[03:06] <poolie> markh, try again?
[03:07] <thumper> is there any easy way to check the revno of the public branch?  like `bzr revno -d :public`?
[03:07]  * thumper waves hands around
[03:08] <spiv> thumper: "bzr revno :public"
[03:08] <thumper> spiv: thanks#
[03:09] <markh> poolie: awesome, thanks!  You now have my permission to enjoy yourself for a couple of weeks on that BMW riding north! :)
[03:09] <poolie> :-)
[03:13] <jml> spiv: bzr://rhino.local/addCleanup-args
[03:14] <thumper> abentley: I don't suppose bzrtools has a command that does the equivalent of "branch X into shared repo, then do a lightweight checkout" ?
[03:14] <abentley> thumper: Sounds like cbranch.
[03:14] <thumper> abentley: can I tell cbranch to --hardlink from a different working tree though?
[03:15] <thumper> abentley: normally I go `bzr cbranch local-a local-b` and that's exactly what I want for that use case
[03:15] <abentley> thumper: Yes.  --files-from
[03:15] <thumper> abentley: but if I want to go `bzr cbranch lp:~a/b/c` that works?
[03:16] <abentley> thumper: Yes, you can cbranch from any location that bzr understands.
[03:16] <thumper> abentley: you rock!
[03:16] <abentley> btw, you need to supply *both* --hardlink and --files-from if you want that.
[03:17] <thumper> abentley: gotcha
[03:17] <thumper> abentley: I have cbranch aliased to `cbranch --lightweight --hardlink`
[03:17] <abentley> Me too.
[03:19] <abentley> thumper: If you forget to supply --files-from, you can use "bzr link-tree" to hardlink after the fact.
[03:19] <spiv> Hmm, "bzr diff -r submit:" is including the changes in the common ancestor revision in the diff.
[03:19] <spiv> That's weird.
[03:19] <thumper> abentley: and that converts copies to hard links?
[03:19] <abentley> thumper: Yes.
[03:20] <thumper> cool
[03:20] <thumper> is link-tree in bzrtools or trunk?
[03:20] <thumper> s/trunk/core/
[03:20] <lifeless> poolie: there is a squid meetup in sydney while you are away
[03:21] <lifeless> poolie: ok if I pop down there for a bit? not sure how much time I want to spend; its monday and tuesday next week
[03:24] <spiv> Ah, it's because my mirror of bzr.dev is older than the branch I'm making a diff of.
[03:27] <lifeless> beuno: around still?
[03:34] <poolie> lifeless, np
[04:14] <pickscrape> mwhudson/beuno: ping
[04:34] <beuno> lifeless, pong
[04:34] <beuno> pickscrape, pong
[04:37] <lifeless> beuno: hi
[04:37] <beuno> hi lifeless
[04:37] <lifeless> beuno: uhm, what was it, oh yeah - does loggerhead have a way to get favicon.ico from a branch ?
[04:37] <lifeless> beuno: wondering if I should file a bug for that
[04:38] <pickscrape> beuno: hi. I was looking to move the breadcrumbs markup out into a shared place. It looks like metal is what I'm after
[04:38] <beuno> lifeless, I've seen your comments on the bug.  What do you mean "from a branch"?  from the actual tree?
[04:38] <beuno> pickscrape, yes, or in macros.pt
[04:38] <pickscrape> There is a template there already called 'macros.pt', but it contains a full-HTML macro and it doesn't like it if I try to define any outside of the html element
[04:38] <beuno> but that will just make rockstar move them to a separate tempalte later on
[04:39] <pickscrape> Ah, he's unifying or something like that isn't he
[04:39] <lifeless> beuno: I mean from the branch, so for non-launchpad installs of loggerhead
[04:39] <beuno> he's spliting things up so it's more themeable
[04:40] <beuno> lifeless, currently LH gets it's favicon statically from it's own dir
[04:40] <beuno> you would want to add a favico.ico to each dir of each branch?
[04:41] <pickscrape> favicon just gets served from root doesn't it?
[04:41] <lifeless> beuno: sure, why not :)
[04:41] <lifeless> pickscrape: I think documents can override per-document
[04:42] <beuno> pickscrape, I can help you place it in the templates, if you get the python code in place to spit out the content
[04:42] <beuno> lifeless, no reason why not, it would make projects more personalized. Although I wonder how many people will go through the trouble of creating one per project/branch
[04:43] <pickscrape> beuno: I'm actually keen to learn how this works myself. I've been playing around and have actually got it working from a separate macros template, though I'm sure that's not ideal
[04:43] <beuno> lifeless, I'm all for it, just not on the top of the list right now. I agree with you  :)
[04:43] <lifeless> beuno: well, if it was (say) .favicon.ico, I'd happy put one in most of my projects
[04:44] <beuno> pickscrape, separate macros template?  embeded in each template?
[04:45] <pickscrape> I created a breadcrumbs.pt file in the same location as macros.pt, and also had to add a line to loggerhead/templatefunctions.py to get it to recognise it
[04:45] <beuno> pickscrape, that sounds correct  :)
[04:46] <rockstar> pickscrape, the "unify" was because the branch was started with a different idea then what actually came out of it.  :)
[04:46] <tacone> favicon can be specified in <head> as well
[04:46] <pickscrape> Is that the approach that rockstar will be taking?
[04:46] <beuno> pickscrape, yes, that's why it sounds right  :)
[04:46] <rockstar> Yes, absolutely.
[04:46] <rockstar> The idea is that someone might want to put the breadcrumbs somewhere else.
[04:46] <pickscrape> Oh sweet. I was concerned that calling it 'breadcrumbs' was being a bit too granular.
[04:47] <rockstar> So they should just have a template function that generates the  breadcrumbs, and they can call that wherever they like.
[04:47] <pickscrape> Yes, that makes sense
[04:48] <pickscrape> In that case it doesn't sound like I'll be conflicting with rockstar as much as I was afraid I might be.
[04:48] <rockstar> beuno, are you gonna merge my branch before or after 1.6?
[04:48] <beuno> rockstar, not at all, ASAP
[04:48] <beuno> so, before
[04:49] <rockstar> Cool.
[04:49] <beuno> anything that's laying around and intersting goes in. I just don't want more features, or it will be like bzr's 1.6
[04:49]  * beuno ducks
[04:51] <rockstar> :)
[04:54] <lifeless> beuno: so I should file a bug?
[04:56] <beuno> lifeless, haven't you already?  Where have you been ping-ponging with poolie about this then?
[04:56] <lifeless> bazaar-launchpad, different use case
[04:57] <lifeless> almost entirely unrelated in fact :)
[04:58]  * beuno looks
[04:58] <beuno> ah, right. I pictured it in my head on how I'd implement it, so I ended up thinking it was on LH  :p
[04:58] <beuno> lifeless, sure, go ahead
[05:00] <pickscrape> night all
[05:00] <lifeless> done
[05:00] <thumper> beuno, rockstar: I've commented on the review, and I think they should be looked at before merging
[05:01] <mwhudson> lifeless: oh, i thought your bug report was about loggerhead too :)
[05:01] <beuno> thumper, just saw it and replied. I fully agree with most of it. Does answering by email automagically work?
[05:01] <thumper> beuno: it should do :-)
[05:01] <beuno> pickscrape, g'night
[05:01] <beuno> thumper, it did, yay!   Now I like reviews better
[05:01] <mwhudson> oh, it was
[05:02] <thumper> beuno: :-)
[05:02] <thumper> beuno: you can thank abentley
[05:02]  * beuno thanks abentley
[05:03] <abentley> beuno: just doing my job
[05:03] <beuno> abentley, still worth thanking you  :)
[05:06] <beuno> hm, LP's sends me back the email I sent as a review
[05:06]  * beuno takes back 1/8th of his thank you from abentley 
[05:07] <abentley> beuno: Mailing lists generally do that.
[05:07] <beuno> abentley, isn't it disabled on most of em?
[05:08] <lifeless> beuno: no
[05:08]  * beuno can't think of any lists he's on that work that way
[05:09] <abentley> bazaar@lists.canonical.com, bzr-gtk@lists.canonical.com
[05:10] <beuno> the bzr ml doesn't send me back my own emails AFAIK
[05:10] <abentley> beuno: It sends me mine.
[05:10] <mwhudson> it's a per-user option in mailman
[05:10] <spiv> Mailman lists let subscribers opt out of having their own messages sent back to them.
[05:10] <beuno> (I'm not actually complaining anymore, just truthfully curious now)
[05:10] <spiv> By default those lists will send them back, I believe.
[05:11] <abentley> beuno: I find it essential to have the mail sent back to me so that I can read mail threads I've participated it.
[05:11] <abentley> participated *in*
[05:11] <beuno> hm, I wonder if it's gmail "doing stuff for me" then
[05:13] <lifeless> abentley: speaking of this
[05:13] <lifeless> abentley: I find I miss reviews when folk use BB's web interface because it doesn't mail me
[05:13] <lifeless> abentley: how do you feel about reimplementing mailmain in turbogears/
[05:14] <lifeless> ?
[05:14] <beuno> ROFL
[05:14] <lifeless> beuno: gmail hides N>1 instances of a mail with the same id
[05:15] <abentley> You miss reviews because they aren't addressed to you personally?
[05:15] <lifeless> yes
[05:15] <beuno> lifeless, ah, ok. So I've been protected from reality up to today.  Why doesn't this apply to LP then?
[05:15] <lifeless> I send in a patch, someone reviews on the web, I notice a few days later when I'm doing a list-scan or BB web UI check
[05:15] <AfC> "I've been protected from reality". Heh. I'm going to steal that.
[05:15] <lifeless> beuno: LP sends its mails with a different id
[05:15] <lifeless> beuno: rather than as a bounce
[05:16] <abentley> lifeless: I am too busy reimplementing Mailman in launchpad to reimplement it in TurboGears :-)
[05:16] <abentley> beuno: This is arguably a bug.
[05:17] <beuno> abentley, yeah, it at least felt odd to my normal workflow.  Mind if I file it then?
[05:17] <abentley> Not at all.  It should have had the same id.
[05:17] <lifeless> abentley: is it actually the same content?
[05:18] <abentley> lifeless: More or less.  May have a header prepended or a footer appended.
[05:18] <lifeless> then I agree
[05:19] <lifeless> FWTW
[05:19] <beuno> \o/
[05:20] <lifeless> thumper: hi
[05:21] <beuno> abentley, I found bug #240564
[05:21] <lifeless> I keep asking this
[05:21] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/205416/+addbranch
[05:21] <lifeless> can we make the whiteboard be shorter so I don't have to scroll on that page?
[05:21] <beuno> fixing that would fix this too, wouldn't it?
[05:21] <beuno> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/240564
[05:21] <lifeless> thumper: if you say yes I'll file a bug
[05:21] <lifeless> thumper: also, at least for me, the common case is 'fix available' not 'work in progress', so could we change the default too ?
[05:23] <thumper> lifeless: please file a bug, and assign it to rockstar
[05:23] <thumper> lifeless: I know you've been asking, but I've been implementing something else you asked for ;-)
[05:23] <rockstar> Yes please.  Assign all bugs to me.
[05:23] <rockstar> :)
[05:23] <thumper> rockstar: something for you to do :)
[05:24] <rockstar> thumper, job security  :)
[05:24] <thumper> :)
[05:25] <mwhudson> watch out, at current rates our team will run out of work ... in 2120 or so
[05:27] <lifeless> thumper: rockstar whats your lp id ?
[05:27] <rockstar> rockstar
[05:27] <rockstar> :)
[05:28] <rockstar> mwhudson, after my talk on LP and bzr tonight, people were telling me all about the bugs they've discovered, as if I was the bug tracker myself.  :)
[05:28] <mwhudson> yeah, people do that
[05:33] <beuno> abentley, so, still file a bug inspite of https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/240564 ?
[05:33] <beuno> it's the last thing I'm doing before *really* going to bed
[05:34] <abentley> beuno: Yes.  This bug is "The message id isn't being preserved when handling incoming mail"
[05:35] <abentley> 240564 is "Only code review messages are threaded, not other messages about the merge proposal".
[05:36] <beuno> abentley, thanks, filed as #257494
[05:37] <beuno> I'm really off now, g'night everybody
[05:38] <abentley> beuno: g'night.
[05:39] <lifeless> gnight beuno
[05:44] <Peng_> This is late, but good night.
[05:49] <abentley> lifeless: If Bundle Buggy CC'ed the submitter, would that stop you from missing reviews?
[05:53] <lifeless> abentley: yes indeed
[05:55] <abentley> lifeless: I've got Mailman configured not to mail me duplicates.  So I think if it sent a message to bazaar@lists.canonical.com that was cc'ed to me, Mailman would not forward it to me.
[05:56] <abentley> That would mean we've covered both cases without having to introduce any per-user settings on BB.
[06:40] <lifeless> abentley: cool
[06:45] <lifeless> spiv: bb:tweak on the testing docs btw
[06:45] <lifeless> spiv: I think I forgot to say
[06:45] <spiv> lifeless: oh cool, thanks
[07:08] <lifeless> spiv:
[07:08] <lifeless> if I could ask for a review, my InterTree + remove tweaks would be a lovely pair to do
[07:10] <spiv> lifeless: I'll take a look.
[07:12] <poolie> lifeless: hm this might have been faster if i'd re-read your rfc before we talked for so long
[07:12] <poolie> it's good
[07:12] <lifeless> poolie: :)
[07:13] <lifeless> poolie: thats good to hear
[07:21] <poolie> hm
[07:21] <poolie> so it's basically like being split by directory, except not necessarily by directory
[07:22] <poolie> i'm not sure if explaining that way is going to cause more or less confusion
[07:22] <lifeless> split by directory achieves some of the goals
[07:22] <lifeless> but conceptually its what a lot of people reach for first
[07:22] <poolie> right
[07:24] <lifeless> I think its important that we explain why that isn't sufficient; and also why its good so that we can use the good bits
[07:26] <lifeless> the good bits are having a canonical form, being updatable in < tree
[07:28] <lifeless> the bits that are not sufficient are being == dir size, and pathological cases have such a strong habit of turning up
[07:29] <lifeless> (also not mapping fileids -> paths at all well)
[07:29] <poolie> that last one may be a challenge for many designs
[07:30] <lifeless> if its too hard its too hard
[07:30] <lifeless> but trivially consider three things
[07:30] <lifeless> a path->id index
[07:30] <lifeless> a id->path index
[07:31] <lifeless> content
[07:32] <poolie> sure
[07:33] <lifeless> making the indices outside the core data is possiblty doable
[07:33] <lifeless> and another thing to consider
[07:37] <lifeless> if we put them outside and use a parallel design to implement the index, it might make the 'core' smaller but is it simpler
[07:39] <lifeless> right now we have no path<->id indices, instead we derive them on th efly
[07:40] <lifeless> we could do that too
[07:40] <lifeless> as long as there was an index on (say) basename<->fileid, and fileid->content
[07:46] <lifeless> then path-> content is 'basename) -> fileid set, repeat lookup on fileid->content until a parent  mismatches
[07:56] <poolie> hm
[07:57] <poolie> i do feel very excited about trying to write such a thing
[07:57] <poolie> :/
[07:57] <lifeless> :)
[07:57] <lifeless> thats a good sign
[07:57] <lifeless> it indicates the design sounds attractive
[08:13] <poolie> hm
[08:13] <poolie> i want to talk more about how to prototype it but really should not
[08:14] <lifeless> :>
[08:16] <lifeless> thanks for the feedbackm its was good
[08:16] <lifeless> I have replied
[08:16] <poolie> i'd be inclined to start by prototyping something that takes an in-memory inventory and writes it out in a new form
[08:16] <lifeless> yes, that would give you a canonical form
[08:17] <lifeless> the converter has to do that anyhow :P
[08:19] <poolie> sue
[08:19] <poolie> sure*
[08:19] <poolie> i mean that might be an interesting place to start
[08:19] <lifeless> I am inclined to start by crisping-up the interfaces for diff etc
[08:19] <lifeless> so that we pass inventory deltas around more
[08:20] <lifeless> rather than upcasting dirstate to an inventory
[08:20] <lifeless> so diff -r -3 internally becomes
[08:20] <lifeless> a call to diff -3..-1 updated by -1..current:
[08:23] <lifeless> poolie: if you do want to chat, I am around for 30 more minutes, raid is at 6
[08:23] <poolie> i have some more mail to send and then need to clean up here
[08:23] <poolie> sadly
[08:23] <poolie> i kind of wish i was disconnecting with a laptop and less interruptions
[08:24] <lifeless> heh
[08:28] <lifeless> would be less of a holiday wouldn't it :)
[09:11] <robsta> hi
[09:12] <robsta> is it possible to push a sequence of bzr commits to an svn repo as a single commit?
[10:02] <james_w> robsta: hi, it's not as far as I know, you need to do a squash merge first.
[10:04] <lifeless> robsta: do you want to discard the history, or to make it look like a single merge?
[10:05] <robsta> make it look like a single commit in svn
[10:10] <lifeless> robsta: bzr checkout svn:/// fo
[10:10] <lifeless> cd fo
[10:10] <lifeless> bzr merge <your branch>
[10:10] <lifeless> bzr commit
[10:10] <lifeless> that will result in a single commit to svn
[10:11] <lifeless> you'll want the latest bzr-svn which has a raft of bugfixes
[10:11] <robsta> ok, so i need two branches
[10:11] <lifeless> jelmer announced it monday or something
[10:11] <robsta> fair enough
[10:14]  * robsta wondering how to best leverage the combination of gnome's svn and bzr-playground
[10:18] <lifeless> spiv: ping
[10:51] <rjek> Incase it's not been reported before; http://rafb.net/p/cqMCzd70.html
[10:51] <rjek> (bzr explosion when doing bzr vis with no DISPLAY on 1.3.1)
[10:52] <lifeless> fun
[10:52] <lifeless> please file a bug?
[10:52] <rjek> Sorry, I don't have an account on Launchpad.
[10:53] <lifeless> oh, ok
[10:53] <lifeless> uhm, perhaps a mail to the bzr-gtk list?
[10:53] <lifeless> you don't need to subscribe, moderator can let it through
[10:53] <rjek> Right, OK.  I'll do that.
[10:54] <rjek> Do you happen to know its address, or an URL of a page that describes it?
[10:54] <lifeless> http://bazaar-vcs.org/bzr-gtk
[10:54] <rjek> Ta.
[10:56] <rjek> sent!
[10:56] <rjek> Thanks.
[12:04] <Peng_> BB down?
[12:08] <Peng_> Oh, good, just slow.
[12:57] <markh> I think I'm still missing something conceptually to do with merging. Let's say i have 3 branches, 'bzr.dev', and 2 'work' branches 'bzr.1' and 'bzr.2'.  I periodically update bzr.dev then pull from 'bzr.dev' into 'bzr.1' - but in the meantime I also make a number of changes in bzr.2, then 'bzr merge' them into bzr.1 and commit them (into bzr.1).  When a do 'bzr log' of bzr.1, all I see is a single 'merge' commit, and not the individual comm
[12:59] <james_w> markh: even with "bzr log --long" (the default, but you may have it aliased)?
[13:00] <markh> james_w: yeah
[13:01] <james_w> and I assume you didn't do "bzr revert --forget-merges" at any point?
[13:01] <james_w> and the merge wasn't a cherry pick?
[13:01] <james_w> i.e. it was just "bzr merge ../bzr.2" not "bzr merge -rx..y ../bzr.2" ?
[13:04] <markh> actually, when I first started looking at this, the initial merges were '-r x..y' - but even then I'd expect to see the logs for r..y?  I'm experimenting now with trying to stitch 2 related branches together without a '-r' though...
[13:04] <james_w> if you use "-rx..y" then it's a cherry pick, and so all of the commits will be collapsed
[13:04] <markh> (for x..y)
[13:04] <james_w> -ry or no -r won't do that
[13:05] <james_w> could you pastebin a transcript showing what you did, and the resulting log?
[13:07] <markh> this is all kinda "post-mortem" - I do need to try some controlled experiments (or find clear docs :)
[13:24] <markh> yeah, merge without -r does what I expect.  So maybe I'm confused about how to make 2 branches "re-converge", so a simple 'bzr merge' keeps them up to date even when they previously diverged.  IIUC, 'bzr pull --overwrite' will lose history too.  I'm still too confused to phrase a reasonable question though :-S
[13:26] <james_w> yeah, pull --overwrite is the wrong thing
[13:26] <james_w> if you "bzr merge" one way you can "bzr pull" the other way afterwards, then the branches should be mirrors
[13:26] <james_w> if you run "bzr pull" and it succeeds then the two branches are mirrors
[13:27] <james_w> "bzr merge" allows you to bring in the changes from another branch regardless of whether a pull would succeed
[13:30] <markh> but once I've done a merge, how do I then get a pull to work again in the future once things are back together?
[13:30] <markh> eg, I checked in locally, then sent a bundle which was merged to bzr.dev - but in the meantime, I've had to "bzr merge" from bzr.dev.  But now it was merged upstream, what do I do?
[13:30] <markh> start a new branch?
[13:31] <markh> (but in the meantime I've also merged various other branches in - although everything in bzr.dev is now in my branch)
[13:32] <markh> eg, I've 3 outstanding merge requests with bundle-buggy - all these are already in my branch that I'm otherwise keeping up-to-date with bzr.dev.  hence my general confusion :)
[13:34] <awilkins> Here's a thing ; the smart server requires the dumb server to work
[13:34] <awilkins> On modern webserver ; fine, on IIS 6 ; annoying
[13:35] <awilkins> How much work would it be to get the smart server to just serve the files that normally come from the dumb server?
[13:36] <Peng_> The smart server already provided VFS access, so I think it should be *possible*.
[13:36] <Peng_> The ideal solution is for the smart server to do everything through RPCs.
[13:36] <awilkins> IIS7 works fine
[13:36] <awilkins> IIS7 has a way of catching /smart links though
[13:37] <awilkins> IIS6 only likes directing things with dotted file extensions to ISAPI modules though
[13:41] <markh> yeah - merging into a new tree seems to be much closer to what I expect.
[13:41] <markh> it avoids the need to cherry pick.  I think trying to stick to an initial "base tree" that has diverged from public branch is the problem
[13:43] <markh> (and it seems I also get to learn about "criss-cross merging" :)
[13:43] <james_w> markh: if you are merging multiple things in to a branch, including bzr.dev then you won't be able to resynchronise to bzr.dev, but you can keep merging it
[13:46] <markh> i've got myself into the state where the only merge that works is to cherry-pick - which collapses the merges as we mentioned.
[13:46] <james_w> hmm, I'm not sure why that would happen
[13:47] <markh> I think I'm looking for the "--oh-yeah-i-know-i-merged-something-silly-before-but-please-just-reconcile-things" option ;)
[13:47] <james_w> heh :-)
[13:47] <james_w> does the command say that you are not allowed to do it, or are you hitting an error?
[13:48] <james_w> the only way I know of to prevent merge working is to have no common ancestor, which shouldn't be the case here
[13:48] <markh> it actually just ended up merging more than I wanted.  things got very confusing when I ended with with both 1.6 and .dev branches
[13:49] <james_w> hmm, interesting
[13:49] <markh> so I've got patches I'm submitting against bzr.dev, but still applying locally to a 1.6 based branch
[13:50] <markh> starting with a clean, new branch up the upstream, then merging in the various ".work" branches seems to be working fine.
[13:50] <markh> I think I just got myself working on the "rhs" of a branch, not the left.
[13:50] <markh> (or something like that :)
[13:50] <markh> s/branch up the upstream/branch *of* the upstream/
[13:51] <markh> I've now got 6 branches based, at some stage in the past, on bzr.dev
[13:52] <markh> each with their own changes, each less or more important
[13:52] <markh> so each now targetting either .dev or both .dev and 16
[15:04] <Toranin> How do you get a proper log of bzr selftest results?  Piping to tee seems to truncate the test names to 80 characters wide, which is not really useful.
[15:06] <jam> markh: I might be able to add a bit more to the locking discussion if you are around
[15:16] <epsy> hi, i've just filed a bug, and i'm not sure what priority to give it
[15:17] <epsy> it affects storage(dirstate), blocks me from using the repository, but is something that could only happen in a very specific setup
[15:17] <epsy> well, i think it could only happen in a very specific setup, that is
[15:18] <james_w> epsy: I'll give it a priority if I triage it
[15:18] <epsy> ok
[15:18] <james_w> epsy: drop the number here and I can do it now
[15:18] <epsy> https://bugs.launchpad.net/bzr/+bug/257599
[15:18] <epsy> heh, nice
[15:19] <james_w> Toranin: are you sure it's not what you are using to view the log that is truncating?
[15:19] <james_w> epsy: that's a dupe I think, let me find it
[15:20] <Toranin> james_w: fairly sure but I'll try it again -- I'm just doing (more or less) bzr selftest -v | tee testlog
[15:20] <epsy> was the other report resolved?
[15:20] <james_w> epsy: yeah, it will be fixed in 1.6
[15:20] <epsy> is there any way i can fix my repo or should i trash it?
[15:20] <Toranin> output looks like:
[15:20] <Toranin> running 14456 tests...
[15:20] <Toranin> ...hon2.5/site-packages/bzrlib/doc/api/branch.txt)   OK                1294ms
[15:22] <james_w> epsy: there's a way to fix it
[15:22] <epsy> phew :)
[15:23] <james_w> bug 150438
[15:23] <Toranin> "COLUMNS=$COLUMNS bzr selftest -v | tee testlog" <-- this widens it out to my terminal width in the log at least.  218 ought to be enough for most test names, I think
[15:23] <james_w> epsy: I think it's "mkdir dir; bzr add dir; bzr st; bzr rm dir"
[15:24] <james_w> where "dir" is the directory that was removed that it is complaining about
[15:24] <epsy> the way to reproduce it or the way to fix it?
[15:24] <james_w> the way to fix it
[15:24] <epsy> ok
[15:26] <epsy> in my case, it's images/avatars/ that i have to add again, right?
[15:29] <epsy> Great, it works! thank you very much :)
[15:39] <james_w> no problem
[15:58] <jonnydee> lifeless: Just wanted to let you know it seems like you have found a bugfix for https://bugs.launchpad.net/bzr/+bug/255656 :)
[15:58] <jonnydee> Thank you very very much!!!!
[16:29] <jam> beuno: ping
[16:29] <beuno> jam, pong
[16:29] <jam> beuno: were you the one that helped me make deb releases?
[16:31] <jam> markh: ping
[16:31] <beuno> jam, yeap. You ready to release?
[16:31] <jam> Not quite yet, but I just wanted you on hand because it makes my life easier :)
[16:31] <jam> I'll *probably* do a 1.6rc2 today if at all possible
[16:33]  * Peng_ predicts 1.6rc7 will be released on October 24.
[16:33] <jam> Peng_: :) Martin is gone so I have release powers now
[16:33] <jam> And I'm planning on forcing it out the door.
[16:33] <Peng_> I'll believe it when I see it. :P
[16:33] <pickscrape> Wasn't this a long release in order to get something in for the gnome project? Was it successful?
[16:34] <Peng_> Are you sure you don't want to wait for groupcompress to be merged?
[16:34]  * Peng_ hides.
[16:34] <jam> :)
[16:34] <beuno> jam, I'm here for the next 8 hours or so  :)   probably more
[16:34] <cody-somerville> beuno, :-)
[16:34] <jam> anyone know what markh's hours are? He seems to be only online late at night or early morning CST time, which seems a bit odd for someone in the US
[16:35] <Peng_> jam: I'm in the U.S.
[16:35] <Peng_> Maybe he's just crazy like me.
[16:35] <jam> Peng_: you're online late morning :)
[16:35] <Peng_> Yeah, my schedule is slipping.
[16:35] <beuno> jam, isn't he in australia?
[16:36] <james_w> yeah, that's what I thought
[16:36] <jam> Well, according to this: http://www.swfwmd.state.fl.us/about/staff/hammond.html he is in Florida (yes I know that's not him :)
[16:37] <jam> It was never clear to me where he lived, you could be completely right.
[16:38] <jam> great, on non win32 WindowsError isn't defined, so you can't just blindly put it in your exception handler... :(
[16:39] <jam> ah, but WindowsError is a subclass of OSError
[16:40] <beuno> jam, his LP page says australia: https://edge.launchpad.net/~mhammond
[16:51] <LarstiQ> jam: he's in .au
[16:52] <jam> LarstiQ: you know, for how active you are  in #bzr, I'm surprised I don't see you at all on the mailing list :)
[16:54] <LarstiQ> jam: that's scheduled for september
[16:54] <LarstiQ> jam: I have been reading some mail again for starters.
[16:54] <jam> what's in Sept? You start school again ?
[16:54] <LarstiQ> stop school actually.
[17:19] <jam> abentley: ping
[17:19] <abentley> jam: pong
[17:20] <jam> abentley: In the interests of getting 1.6rc2 out today, I want to make sure I've evaluated everything that people want to land
[17:20] <jam> And I'd like a bit more info why your patch is necessary for 1.6
[17:21] <abentley> jam: It fixes readability of "info" for branches in the new formats.
[17:22] <jam> well, I'm getting something even weirder here
[17:22] <jam> using bzr.dev
[17:22] <jam> I get a traceback with
[17:22] <jam> bzrlib.errors.UnknownFormatError: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
[17:23] <jam> though that might be my 'nick' script
[17:24] <abentley> jam: I can't reproduce that with bzr.dev
[17:24] <jam> abentley: And this looks perfectly readable: http://rafb.net/p/Or1iue87.html
[17:25] <jam> The indentation is a little odd, I guess
[17:25] <jam> but not unreadable
[17:27] <abentley> jam: It gets away with it because it comes last.  If both branch and working tree formats were multi-line descriptions, it would be very hard to parse.
[17:27] <abentley> But it's always been a single line in the past, and I believe that's what people want and expect.
[17:27] <jam> true, though arguably info-v should be updated to support multiple lines.
[17:28] <jam> I kind of like the more verbose description
[17:28] <jam> I'm willing to merge what you have
[17:28] <jam> I'm just not sure I agree 100%
[17:28] <abentley> jam: It's a very poor answer to the question "What is my repository format?"
[17:29] <abentley> jam: additionally, the docstring for the RichRoot variant is flat-out wrong.
[17:29] <jam> hmm... I find it a pretty good response
[17:29] <jam> I agree that RichRoot is just wrong.
[17:30] <abentley> jam: Not in my opinion.  It's not the reply I'd want on IRC, or when discussing things in email.
[17:31] <jam> abentley: well *I* would want "RepositoryFormatKnitPack5" as that fully encapsulates it ,and is short for IRC, etc.
[17:31] <jam> I don't think that is suitable for "bzr info" though
[17:31] <jam> so I'm not sure if that is the best test
[17:31] <abentley> It's a fine reply to "What does my repository format support, etc"
[17:32] <abentley> jam: So how can people find out what their repo format is, if not through "info"?
[17:32] <jam> abentley: well plain "bzr info" gives: Shared repository with trees (format: pack-0.92)
[17:32] <jam> If we were going to do it *right*
[17:32] <jam> then we should be using the short names for them.
[17:33] <jam> for some definition of "right" because of the permutation problem
[17:33] <abentley> It shouldn't say pack-0.92
[17:33] <jam> abentley: that was a different repo
[17:33] <jam> Shared repository with trees (format: 1.6)
[17:33] <jam> If you prefer
[17:34] <jam> I'm really tending on the "get 1.6 released" already and postponing everything that isn't an actual regression.
[17:34] <jam> But if you feel strongly, I'll merge it
[17:35] <abentley> Many are unhappy with using the short strings.
[17:35] <abentley> Especially when you're talking about a shared repo or checkout where it could be one of many.
[17:36] <abentley> The current docstrings are unacceptable to me because they don't say "RepositoryFormatKnitPack5" or something like that anywhere, and because they make false statements.
[17:37] <abentley> I don't insist on fixing the multi-line thing for 1.6.
[17:39] <abentley> Though of course, the simplest thing to do would be to apply my patch.
[17:39] <jam> abentley: so you *do* feel like the strings need to be updated for 1.6
[17:39] <jam> I'll probably just merge your patch
[17:40] <jam> you know, I wish Thunderbird wouldn't include BB emails when I search by your name
[17:41] <jam> I think it is because bb's email address includes yourname.com
[17:41] <abentley> Yeah.  Sorry.
[17:41] <jam> If I use your full name with a space, then BB is filtered out
[17:44] <awilkins> jam: Would your proposed consideration of kind == 'file' to kind == None as a content change mean that the deltetion of a file would show up as a revision it participated in, in the log (desirable, IMHO)
[17:45] <jam> awilkins: something else entirely
[17:45] <jam> bzr log -v already does that
[17:45] <jam> Just that bzr log -v file doesn't IIRC
[17:46] <awilkins> Someone was asking about it last week and this reminded me
[17:46] <jam> abentley: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48A307FB.7060905%40arbash-meinel.com%3E
[17:46] <jam> I think it is the last patch which is specifically blocking 1.6rc2
[17:46] <jam> Though you may not be comfortable reviewing it
[17:47] <abentley> jam: I don't think I have time today.
[17:47] <jam> It's rather small
[17:47] <jam> just win32 specific
[17:48] <awilkins> He wanted to know which revision a file(not in present inventory) was deleted in ; it's easy enough to extend bzr log to support --file-id, but then the log alas, doesn't show the deletion :-(
[17:48]  * awilkins would review it if his vote carried any weight
[17:48] <jam> awilkins: I'm well versed in the problem, and know why it is an issue
[17:48] <jam> awilkins: all reviewers carry some weight
[17:48] <awilkins> But if I voite, BB ignoreds me, right ?
[17:48] <jam> BB probably does
[17:48] <jam> That doesn't mean *I* would :)
[17:49] <abentley> jam: I'm not supposed to be working on bzr during paid hours, and I'm in the middle of reviewing other stuff, and I have plans this evening.
[17:49] <jam> I'm surprised you aren't supposed to do any bzr work, given that you are in launchpad-bazaar, but sure
[17:50] <jam> I mean, you *did* just submit a patch because it effected LP :)
[17:50] <jam> We just don't have any other reviewers in this TZ
[17:50] <jam> Unless jelmer is awake ...
[17:50] <awilkins> I can work on it during paid hours (with a clean conscience) as long as it benefits my project
[17:50] <awilkins> I can work on it (with a dirty conscience) anyway :-P
[17:51] <abentley> jam: It doesn't affect LP.  I've already overridden those strings for LP.
[17:52] <jam> awilkins: :)
[17:52] <jam> abentley: so I should make the request in #bzrlp, right ? :)
[17:54] <abentley> jam: I don't think anyone there is awake and in my chain-of-command.
[17:55] <jam> no, I just mean then it appears as a bzrlp request
[17:55] <jam> We've taken longer discussing it than it would have taken you to review it
[17:55] <jam> Don't worry about me, I'll find someone else
[17:57] <awilkins> Pulling patches via URLs is very convenient
[18:00] <jam> awilkins: I agree
[18:00] <awilkins> jam: Well, it makes the test pass ; but I see a few other places where ENOTDIR is used
[18:00] <jam> awilkins: sure, I'm just looking for a *regression* fix
[18:00] <jam> not a full solution to all problems
[18:01] <jam> For a release, I want it to not be worse than it was in the last release.
[18:01] <jam> And we *really* need to get a release out the door
[18:01] <awilkins> I suppose it does lower the footprint
[18:04] <awilkins> jam: I agree about the release, building my own is a PITA (and worrying, if I've patched it off the main line)
[18:04] <awilkins> This will fix my last issue with 1.6 (all my other patches are in)
[18:07] <jam> beuno: ping
[18:08] <jonnydee> jam: hi, regarding the bug https://bugs.launchpad.net/bzr/+bug/255656 -- what do you think? will my nomination for release 1.6 be considered?
[18:08] <beuno> jam, pong
[18:08] <jam> jonnydee: well, the fix robert proposed isn't really an official fix, more of a workaround to see what the bug was
[18:09] <jam> as such, I'm hesitant to make it into 1.6 without a real fix and test (as I'm trying to get 1.6 pushed out the door)
[18:09] <jam> I would be surprised if it didn't land in 1.7, though
[18:09] <jonnydee> so I will have to copy with this bug in release 1.6, too?
[18:09] <jam> jonnydee: 1.5 performs the same, right?
[18:10] <jonnydee> well, I'm not sure...
[18:10] <jonnydee> sorry, I meant "cope"
[18:10] <jam> jonnydee: I'm really trying to keep changes to 1.6 as regressions only
[18:11] <jam> we have slipped 3 months because of delays
[18:11] <jonnydee> yes, I understand...
[18:11] <jam> when we get back into a regular release
[18:11] <jam> 1.7 will come out within a couple weeks
[18:11] <jam> so no big "must get it right now" issues
[18:11] <jam> jonnydee: so... if it is a *regression* you have a chance otherwise, not really
[18:11] <jam> beuno: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48A307FB.7060905%40arbash-meinel.com%3E
[18:12] <jam> I figure 2 non-core people looking over the code for obvious flaws is enough for me to merge it
[18:12] <jam> and then I'll be ready for 1.6rc2
[18:12] <jonnydee> how can I support to get it to a *regression*
[18:13] <jam> jonnydee: If 1.5 *works* and 1.6 *doesn't* that is a regression
[18:13] <beuno> jam, sure, looking
[18:13] <jonnydee> ok, I see
[18:13] <jam> jonnydee: which is why I'm trying to get the "rm" patch merged
[18:14] <jam> and not the 10 other things that are pending review in BB that I've written :)
[18:16] <Toranin> jam: FWIW, the patch looks sane to me, presuming your comments on Python's behavior are correct
[18:16] <Toranin> however, I've not read or worked on the context code at all
[18:17] <jam> Toranin: thanks, we have some strong hints that it is correct because we've been using a variant in workingtree_4.py
[18:18] <Toranin> my only concern would be that you strip the comment explaining WHY the exception is okay in the first use case
[18:18] <awilkins> jam: I't OK on Python25 but for a (related/unrelated?) reason I am running into an error on Python24
[18:19] <jam> awilkins: what specific test are you running?
[18:19] <awilkins> jam: Is pywin32 supposed to be a cast-iron requirement for bzr on windows?
[18:19] <jonnydee> anyway, thanks for your help! :) You do great work!!! :)
[18:19] <awilkins> jam: I'm running test_switch, which is where I found it at first
[18:20] <jam> awilkins: are you python extensions rebuilt?
[18:20] <awilkins> jam: nope, hold on
[18:20] <jam> I get: NotImplementedError: We must have one of fcntl, pywin32, or ctypes available to support OS locking.
[18:20] <awilkins> awilkins: But I think it's because my Python24 lacks pywin32
[18:20] <jam> but that just means I need to install pywin32
[18:20] <jam> which sounds the same as yours :)
[18:20] <beuno> jam, sent my thumbs up to the list
[18:20] <jam> beuno: thanks
[18:22] <awilkins> Does gmane work well for list posting?
[18:22]  * awilkins has just used it to post approval
[18:23] <awilkins> jam: That means that pywin32 is required to run the test suite?
[18:23] <jam> awilkins: We either need ctypes or pywin32
[18:23] <jam> Python2.5 bundles ctypes directly
[18:23] <awilkins> Ah, yes
[18:25] <awilkins> Hey, Python 2.6 !?
[18:25] <jam> beuno: ok, well, I'll merge this patch, and one more to get the version strings to show 1.6rc2
[18:25] <jam> And then I'll be ready for some packaging.
[18:26] <jam> This won't be 1.6 final, so that people can respond to my comments in the 1.6 thread
[18:26] <beuno> sounds good
[18:31] <dato> heh, persona non gratis
[18:31] <awilkins> Bugger, I meant "grata" didn't I....
[18:33] <dato> :)
[18:33] <pickscrape> Interestingly, bzr 1.6_rc1 is already available in the bzr gentoo overlay :)
[18:34] <LarstiQ> jam: unless it's python2.5 on win64 of course, sigh
[18:34] <pickscrape> Gah, ignore me. You're talking about rc2 aren't you. :)
[18:35] <jam> pickscrape: yep
[18:35] <jam> LarstiQ: yeah, but we probably have a raft of issues with p2.5 on win64 anyway
[18:35] <jam> And nobody has stepped up to complain yet :)
[18:35] <pickscrape> Is anyone aware of a problem deleting a symlink that points to a directory that doesn't exist?
[18:36] <awilkins> They tried to get me to buy Vista64 at my friendly retailer
[18:36] <rockstar> beuno, lp:~rockstar/loggerhead/unify-templates
[18:36] <awilkins> I laughed in their face and burned their warehouse down
[18:36] <Peng_> abentley: ping
[18:36] <rockstar> I've moved the search and rss out of the menu
[18:36] <pickscrape> It gives me: bzr: ERROR: Not a branch: "/path/to/symlink/target/".
[18:36] <Peng_> abentley: I just got a mailer daemon error from a message sent to you (just a CC on a mailing list post). time limit exceeded: "procmail -a "$EXTENSION""
[18:37] <jam> awilkins: well, I got your email from gmane, so it seems to work fine
[18:38]  * beuno looks at rockstar's branch
[18:39] <LarstiQ> jam: as does everybody else, yes.
[18:40] <jam> LarstiQ: especially with the Py_ssize_t stuff
[18:49] <beuno> rockstar, all changes look good to me
[18:50] <beuno> I'm happy to merge, unless you want to wait for mwhudson and thumper to re-review
[18:50] <pickscrape> Is it worth me raising a new bug about the fact that bzr rm <dangling_symlink> doesn't work, or it is amply covered by the existing bugs that deal with the same problem with other commands?
[18:52] <beuno> pickscrape, I'd say it's worth it. If it turns out to be covered, it'll just get marked as duplicate
[18:52] <beuno> rockstar, btw, if you ever want to test search, you just need to install the bzr-search plugin, and run 'bzr index' on the branch
[20:15] <rockstar> beuno, I've addressed everything thumper had in the review.  I haven't seen a review from mwhudson yet.
[20:15] <rockstar> Although, sometimes it takes him a few days.
[20:16] <beuno> rockstar, I'll merge. mwhudson can yell at me later.  I think 2 reviews is more than adecuate
[20:16] <TheEric> How does one reconcile without using ssh?
[20:16] <rockstar> beuno, :)
[20:16] <beuno> TheEric, bzr reconcile sftp://...
[20:17] <TheEric> k, I'm going to try that approach to reconcile our current app as the ssh method evidently doesn't work.
[20:18] <beuno> TheEric, good luck  :)
[20:18] <TheEric> fail. Paraminko needs to be installed.. Bah.
[20:19] <beuno> TheEric, it should be installed by default.  You're on windows, right?
[20:19] <Manfre> i had the same problem yesterday, gave up since pycrypto needed vs2003..i only have 2005/2008
[20:19] <Manfre> beuno, it's not installed by default for python 2.5 installer and not for 1.6 bzr iinstaller
[20:20]  * beuno pokes markh 
[20:21] <beuno> I don't know much about windows anymore. Mark may be awake already
[20:23] <TheEric> Gotta love university bandwidth. Downloads around 1000kb/s
[20:24] <beuno> rockstar, merged
[20:24] <rockstar> beuno, great, thanks!
[20:35] <Peng_> Ooh.
[20:38] <Peng_> beuno / rockstar: The feed button on /changes is broken (not the <link> tag, just the regular old <a> next to the search box).
[20:38] <Peng_> <a href="Exception: name 'url' is not defined" title="RSS feed for /my/branch">
[20:38] <rockstar> Peng_, ah, thanks.
[20:38] <rockstar> beuno, I'll fix it in the existing branch, and you can just merge it again.  Sound good?
[20:39] <beuno> rockstar, yeap
[20:39] <beuno> Peng_, as always, you rock  :)
[20:39] <Peng_> :)
[20:53] <jam> beuno: There is a release candidate tarball that has been uploaded.
[20:53] <jam> I'm sending the announcement now
[20:53] <Peng_> Whee.
[20:54] <rockstar> beuno, the fix is ready for merging.
[20:54] <beuno> jam, I'll upload packages then.
[20:54] <beuno> rockstar, cool, I'll merge
[20:54] <rockstar> I also checked to make sure that nothing else is broken.  :)
[21:00] <beuno> rockstar, pushed. Sorry I missed that in the review
[21:00] <rockstar> beuno, yea, I missed it as well.  It happens.
[21:00] <beuno> jam, when do you expect 1.6 final to be out?  this week?
[21:02] <jam> beuno: ASAP, within a week if nobody complains about the release
[21:03] <jam> markh: I would like you to make full-fledged installers if you can. If not, I can put together some bzr-lite ones (I won't be including tbzr, etc.)
[21:03] <beuno> jam, because it may be worth uploading 1.6rc2 hardy to the ~bzr PPA too, since there's no bzr release on it now
[21:03] <jam> beuno: can't we just copy the one from gutsy?
[21:03] <jam> I'm not a big wizard on the ppa side of things
[21:03] <jam> but I thought the gutsy and hardy package were identical
[21:04] <beuno> jam, copying packages breaks stuff. I haven't gotten them to work. Ever.
[21:04] <beuno> there are theories
[21:04] <beuno> I can try it again
[21:04] <beuno> last I heard, copyong gutsy -> hardy should be fine
[21:04] <beuno> but it tends to not work
[21:04] <beuno> oh, and we can't have 1.5
[21:04] <beuno> since we already uploaded 1.6b2 before
[21:04] <jam> "can't have 1.5" ? ouch
[21:05] <beuno> so it's 1.6b3+
[21:05] <beuno> yeah
[21:05] <pickscrape> That seem like quite a limitation to the PPA system.
[21:05] <jam> well, in that case I'd do 1.6rc2, but still crappy
[21:05] <jam> pickscrape: you *can* have old versions, but it won't recommend them
[21:05] <jam> if something newer has been uploaded and then subsequently removed
[21:05] <beuno> pickscrape, it's apt, not ppa
[21:05] <jam> beuno: so I believe you *can* explicitly request 1.5
[21:05] <beuno> jam, ok, cool. I'll upload to both
[21:05] <jam> beuno: only for hardy though on ~bzr
[21:06] <pickscrape> Even if you never installed the previously uploaded version?
[21:06] <jam> beuno: and don't forget the bzr1.6~rc1 :)
[21:06] <beuno> jam, there may be stuff in place on PPA to prevent that
[21:06] <beuno> jam, yes, and yes  :)
[21:06] <beuno> I'll run it by you before uploading
[21:07] <jam> pickscrape: if you use the 'any' filter you can see it: https://edge.launchpad.net/~bzr/+archive?field.name_filter=&field.status_filter=any
[21:07] <jam> there is a bazaar1.5 there
[21:07] <jam> It has status "superseded" though, and it is superseded by the deleted package :(
[21:07] <jam> beuno: are you sure Superseded isn't only a ppa thing?
[21:08] <pickscrape> But isn't that status defined on the PPA side, or would changing it break apt?
[21:08] <beuno> jam, yeah, it works that way everywhere else
[21:08] <james_w> beuno: you can re-upload 1.5
[21:09] <jam> james_w: but isn't it superseded by something newer?
[21:09] <jam> james_w: I mean, the 1.5 package is *still there*
[21:09] <james_w> just give it a version of "1.6b3+really.1.5-1" or similar
[21:09] <jam> james_w: evil
[21:09] <beuno> james_w, right, dato proposed that, but it seemed like too much of a hack
[21:09] <pickscrape> but crafty :)
[21:09] <james_w> there's plenty of precedent
[21:10] <beuno> and, well, 1.6 has been "almost" out for a while now  :)
[21:10] <jam> james_w: with the downside that 1.6b3 will be "upgraded" to 1.5, right?
[21:10] <james_w> yeah, if you had the ~bzr ppa, but not the ~bzr-beta
[21:10] <jam> beuno: well, I'm planning on pushing really hard to see that it does
[21:10] <james_w> that's normally the intention when you do that
[21:11] <jam> There was really only 1 thing that Martin had on his list that I'm skipping
[21:11] <jam> but I have to wait for AU time for everyone to respond to my plans
[21:11] <jam> beuno: are you going to be around in 48 hours? (My friday)
[21:12] <beuno> jam, I can't upload to ~bzr-beta-ppa, I haven't been approved
[21:12] <beuno> jam, yeah, I'll be here friday
[21:12] <TheEric> well, that reconcile failed with the sftp://
[21:13] <TheEric> http://pastebin.com/m65dc1423
[21:13] <jam> beuno: well, we'll have to see if *I've* been approved :)
[21:13] <jam> I think martin added me a while back
[21:13] <jam> if you can put them somewhere, I'll upload
[21:14] <beuno> jam, yeah, you're approved. Once I upload succesfully to ~bzr, I'll place em somewhere so you can upload them to ~beta
[21:17] <TheEric> Here's the .bzr.log file - http://pastebin.com/m13f08af1 to go with that failed reconcile.
[21:18] <jam> beuno: once you upload it, I can actually just copy it directly to ~bzr-beta-ppa using LP's copy package feature
[21:19] <beuno> jam, for hardy you can, not the rest
[21:20] <jam> beuno: can't I copy ~bzr/hardy => ~bzr-beta-ppa/hardy
[21:20] <jam> and then copy /hardy => /gutsy, etc ?
[21:20] <jam> Just not dapper
[21:20] <beuno> jam, nope. It broke every single time we did that with poolie
[21:20] <jam> well, that's pretty crummy
[21:20] <jam> james_w: what's up with that ?
[21:20] <beuno> OTOH, it's rumoured that uploading to, say, feisty, and then copying "upwards", works
[21:21] <jam> beuno: was it just a dependencies thing?
[21:21] <james_w> beuno: what broke?
[21:21] <jam> and does it change if you check the "copy binaries" flag?
[21:21] <james_w> if it's just a source copy and you are re-uploading the same source then I would assume it works, but I am probably missing something
[21:22] <beuno> james_w, dependencies
[21:22] <beuno> if you re-upload, and it re-builds, it's fine
[21:22] <beuno> if you copy, it's not
[21:22] <james_w> yeah, they are generated at build time, so I would have thought that a source copy would cause a rebuild and that would work
[21:24] <jam> james_w: so you think that copying without checking the "copy binary" should work?
[21:25] <james_w> that's what I thought, but it hasn't worked previously
[21:26] <beuno> jam, bzr_1.6~rc2-1~bazaar1~hardy1
[21:26] <jam> beuno: I thought we weren't doing the ~hardy1 thing ?
[21:26] <beuno> jam, I'm not, but poolie kept on doing it
[21:26] <jam> Just plain ~bazaar1
[21:27] <beuno> yeah, I like that more
[21:27] <jam> as long as there is precedence, I guess
[21:27] <james_w> you should to provide an upgrade path
[21:27] <jam> james_w: but then you have to edit it for each one
[21:27] <james_w> jam: yup, it's a pain
[21:27] <jam> to do ~intrepid1, ~gutsy1, etc.
[21:27] <jam> james_w: and how does *that* work with copying?
[21:27] <beuno> jam, it copies ~release1
[21:27] <james_w> don't copy if you are doing that I think
[21:28] <beuno> which is confusing  :)
[21:28] <jam> beuno: so if you copy ~hardy1 => gutsy, it changes that value?
[21:28] <miracle2k> am I crazy or is there now way to link to the latest revision of a file in the launchpad browser?
[21:28] <beuno> jam, nope
[21:28] <awilkins> markh: Are you win32 release builder?
[21:28] <beuno> miracle2k, where are you looking?
[21:29] <miracle2k> beuno: say I want to link to the latest README.txt from: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/files
[21:29] <beuno> jam, I'd say, leave ~hardy1, etc, don't copy, and have a talk with poolie when he gets back from vacation
[21:30] <jam> beuno: um, then I have to re-upload everything
[21:30] <beuno> miracle2k, ah, I don't think we have a direct link for that now
[21:31] <jam> miracle2k: There is a secret revision "HEAD" that you can use, just a sec
[21:31] <beuno> jam, your call. I'll do either
[21:31] <jam> beuno: I'll just upload it, but I worry because I've never *actually* successfully built and uploaded packages
[21:32] <jam> way too much hassle to do the N-way release thing
[21:32] <jam> beuno: this gives me an "internal server error": http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head?file_id=readme.txt-20061211064337-5lpgd5knbgm7jrgz-2
[21:32] <jam> I thought that was the right way
[21:32] <beuno> jam, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head:?file_id=readme.txt-20061211064337-5lpgd5knbgm7jrgz-2
[21:33] <jam> ah 'head:'
[21:33] <jam> the ':'
[21:33] <jam> miracle2k: ^^
[21:33] <miracle2k> jam: thanks a lot!
[21:34] <miracle2k> the extra stuff in the file_id just refers to the branch itself I assume?
[21:34] <beuno> miracle2k, it's the unique ID for that file
[21:35] <beuno> we will probably address that in the next release
[21:35] <jam> beuno: wasn't there a path= that you could use?
[21:35] <jam> miracle2k: so using a file_id, means that if you rename the file, it will follow the rename
[21:35] <beuno> jam, no, I don't think you can use paths ATM
[21:35] <jam> beuno: so, you have the package available, or it has been uploaded?
[21:36] <jam> beuno: hmm.. I was pretty sure it used to work, but not that *I* really care
[21:36] <beuno> jam, uploading hardy to ~bzr
[21:36] <miracle2k> jam: I get that, but I guess I am confused by the fact that the filename itself is included as well. but nvm, I'll have a closer look at the bzr internals at some point
[21:37] <beuno> jam, I've never used the path bit, and I can't think of any part of the code that would do it. That said, Loggerhead still has some unexplored places, so anything's possible
[21:38] <jam> miracle2k: when you 'bzr add' a file, we generate a filename that starts with the path
[21:38] <jam> after renames, etc, it keeps the original id
[21:39] <jam> beuno: I just thought someone posted a link using head: and path= as a "nice" url that wasn't exposed anywhere.
[21:39] <jam> You just had to know it existed.
[21:39] <jam> But I would guess you have as much info about LH as anyone anymore
[21:40] <beuno> I remember the head:, because we use bzr's magic underneath.  path escapes me, but, again, it wouldn't shock me that it's hidden somewhere. mwhudson is good with those things
[21:40] <beuno> jam, [PPA bzr] Accepted: bzr 1.6~rc2-1~bazaar1~hardy1 (source)
[21:41] <jam> beuno: well the obvious "path=README.txt" doesn't work
[21:41] <jam> certainly it is just a "path2id()" away
[21:42] <beuno> jam, maybe we can get a LP admin to approve me in ~beta instead of us uploading/downloading, etc?
[21:43] <Peng_> Yeah, the feed thing is fixed. :)
[21:43] <Peng_> Thanks.
[21:44] <jam> beuno: yeah, poolie added lifeless and I as "Members" but not "Administrators" so we can't approve you.
[21:44] <jam> I started the copy to ~bzr-beta-ppa
[21:44] <jam> Which seems successful and seems to want to build binaries for it
[21:45] <beuno> jam, wanna try copying to intrepid/gutsy/feisty?
[21:45] <jam> james_w: can you mark a package "Needs building" ?
[21:45] <jam> beuno: I can certainly try it, right?
[21:45] <jam> worst case we just upload them directly?
[21:45] <beuno> yeap, with -2 in 'em
[21:45] <james_w> jam: don't think so, it should happen automatically if you didn't copy binaries
[21:46] <jam> james_w: Well, I just tried to copy ~hardy1 => intrepid, and it gave me:
[21:46] <jam> The following source cannot be copied: bzr 1.6~rc2-1~bazaar1~hardy1 in hardy (same version already building in the destination archive for Hardy)
[21:46] <jam> james_w: It seems the "series" field isn't being respected?
[21:46] <jam> Maybe it is being overloaded by the ~hardy1 ?
[21:47] <beuno> hrm
[21:47] <beuno> maybe PPA's don't allow the same package in 2 different places?
[21:47] <jam> beuno: well, that negates the *point* of the copy feature, right?
[21:47] <jam> I mean, if you can't actually copy to another "Destination Series" then you really can't do anything
[21:47] <jam> other than between PPAs
[21:48] <jam> but certainly they are trying to give the option
[21:48] <beuno> jam, unless it's for a different release, but yeah, I can't get my head around copying in PPA
[21:48] <jam> beuno: and, of course, there is "expected behavior" and there is "bugs"
[21:49] <beuno> exactly  :)
[21:49] <jam> That's why I'm trying to poke at james_w to see what category this sort of thing falls under
[21:49] <jam> https://help.launchpad.net/PPA?action=show&redirect=PPAQuickStart#Copying%20packages
[21:49] <jam> Is pretty vague
[21:50] <james_w> I've never done a package copy, I agree with your expectation of this though jam
[21:50] <jam> Really, it just says what you should expect on the page
[21:50] <james_w> it sounds like it's trying hardy->hardy
[21:50] <jam> and not really what you should expect it to actually do
[21:51] <james_w> maybe #launchpad ?
[21:51] <jam> james_w: it does indeed, but I'm definitely changing the "Destination Series"
[21:58] <jam> trying there
[22:02] <[reed]> How do I kill a stuck lock on a bzr repo? Trying to commit to a local repo, and it says there's a lock. The pid it claims the lock belongs to doesn't exist (it did the first time, but it's been killed since then).
[22:03] <awilkins> bzr break-lock
[22:04] <[reed]> thanks!
[22:13] <beuno> OMG, jam names his PC after pokemons!
[22:15] <LarstiQ> beuno: you didn't know? :)
[22:15]  * LarstiQ fondly remembers jigglypuff
[22:16] <beuno> no, I should pay more attention
[22:18] <Peng_> I didn't know. Nice. :)
[22:29] <Stavros> hello
[22:29] <Stavros> is there a bzr repo that has the current version of bzrtools?
[22:30] <Stavros> right now i can install either the latest bzr version or bzrtools :/
[22:30] <lifeless> jam: ^ I think perhaps you uploaded a beta to stalle ppa?
[22:31] <beuno> lifeless, I did. There was no bzr for hardy
[22:31] <beuno> so, I thought, better 1.6rc2 than nothing
[22:31] <beuno> of course, this breaks bzrtools
[22:31] <beuno> *sigh*
[22:32] <beuno> and, good morning lifeless   :)
[22:32] <Stavros> is there a solution for the bzrtools problem?
[22:32] <beuno> Stavros, you can uninstall it, and install from source
[22:32] <Stavros> beuno: but that way it won't be tracked
[22:33] <beuno> Stavros, right. The other option is wait until someone has time to upload bzrtools 1.6  (is that even released?)
[22:34] <Stavros> ah :/
[22:34] <beuno> sorry about that
[22:35] <Peng_> You could install bzrtools from source, and delete it once an update is available.
[22:45] <jam> beuno, LarstiQ: Actually after Super Smash Brothers
[22:45] <jam> Samus == Metroid lady
[22:45] <jam> Jigglypuff was my old mac
[22:46] <jam> lifeless: Kiko on #launchpad determined that you *can't* use the copy feature of LP to copy between distributions within the same archive
[22:46] <jam> because it can't rename the package
[22:46] <beuno> jam, right, right, smash brothers  :)
[22:46] <jam> So it would get naming conflicts.
[22:47] <beuno> jam, btw, uploading for dapper now, that should be the last of it
[22:47] <jam> beuno: SSB with sudden death mode, and all Jigglypuff characters was very entertaining
[22:47] <lifeless> jam: AIUI we shouldn't ever be using copy
[22:47] <jam> lifeless: well, copy is mentioned in the docs
[22:47] <jam> because it would make our lives a lot easier
[22:47] <lifeless> our docs or launchpads?
[22:47] <jam> and you *can* copy the package from ~bzr-beta-ppa => ~bzr
[22:47] <jam> lifeless: ours
[22:47] <jam> and launchpad hints that you can use it
[22:47] <jam> but gives very little as to what to expect.
[22:47] <lifeless> right, but it lies :)
[22:48] <jam> LP will *let* you say that you want to copy X package to the same archive
[22:48] <jam> but that never works
[22:48] <jam> unless maybe you copy the binaries
[22:48] <jam> but then you likely have problems with deps
[22:52] <lifeless> jam: full test run of .bzrrules disabling code is running now
[22:52] <jam> lifeless: well, you also have to convince at least one other person that it is *correct*, as I don't really think it is.
[22:53] <lifeless> jam: I've convinced three others
[22:53] <lifeless> jam: Ian, Jelmer, and Martin
[22:53] <lifeless> though to be pedantic, Jelmer came preconvinced
[22:53] <lifeless> and if I could find this damn email rant from Aaron back in the day I'd have more evidence
[22:55] <strk> bazaar thinks I hold a lock, but I've no bzr process running
[22:55] <strk> any way to further debug the issue ?
[22:55] <lifeless> strk: we don't use oslocks, so thats possible
[22:55] <lifeless> strk: what does bzr break-lock say about the lock ?
[22:55] <jam> lifeless: If you've convinced Ian, I'm okay with it. I think it falls into the "we keep saying this isn't the right way, but we provide no better way so we have nothing".
[22:56] <strk> prompts me to break it, said yes
[22:57] <strk> said it was hold by me (my email)
[22:57] <strk> one hour, 30 mins
[22:57] <strk> it was after a merge from trunk
[22:58] <lifeless> jam: I've just reread Ian's mail to me, I think I had agreement there is an issue.
[22:58] <lifeless> jam: I'm forwarding it to you
[22:59] <lifeless> strk: something must have hard-interrupted bzr
[22:59] <lifeless> strk: e.g. SIGKILL or SIGHUP
[23:00] <strk> possible
[23:01] <lifeless> strk: we can't use OSLocks over the network; so we don't use them for data structures that are network accessible
[23:01] <beuno> jam, all debs uploaded and published
[23:02] <jam> lifeless: I'm also responding with the last post I saw from igc on the mailing list
[23:02] <jam> lifeless: or two SIGINTs at the right time (one while we're cleaning up is sufficient)
[23:02] <jam> beuno: thanks a lot!!
[23:03] <beuno> jam, my pleasure. You should milk this as much as possible, before I actually get a manager assigned and have something specific to do  :)
[23:04] <lifeless> jam: did you have more feedback on the inventory docs? I think I have enough to recast it as a tighter set of needs if you don't
[23:05] <jam> lifeless: I have an email for you I'm finishing, but right now I have to pick up my son from daycare.
[23:05] <lifeless> jam: go then
[23:05] <lifeless> jam: think you'll get it to me today?
[23:06] <thumper> could I get someone who knows about reconcile to take a look at https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/257340 please?
[23:06] <thumper> it is beyond me
[23:07] <lifeless> jam: on the rules stuff
[23:07] <lifeless> jam: I had a conflict of interests in my head back at the start of the yea
[23:07] <lifeless> *year*
[23:07] <lifeless> as a community guy I wanted to flat veto designs involved versioned user files
[23:08] <lifeless> as a canonical guy I wanted to see features land as fast as possible
[23:08] <lifeless> I've wrestled with myself and come to the conclusion that landing the wrong thing isn't right for anyone
[23:08] <lifeless> which is why I'm engaging on this topic again
[23:15] <luks> I wonder how do you want to handle historical data if you don't version .bzrrules
[23:20] <samatwork> does anyone know how to fix a bzr: ERROR: not well-formed (invalid token) error?
[23:20] <samatwork> I've looked all over for an error that explains it and I know that many have had it, but I didn't see any clear-cut solution
[23:21] <james_w> samatwork: hi, I've never seen that before, do you get a full backtrace, or just that?
[23:21] <samatwork> just that
[23:21] <samatwork> I'm getting it on all clients that are referencing a central repository
[23:22] <samatwork> I fibbed it it also gives a line and column number, but I have no idea what this is referencing
[23:23] <samatwork> can't find anything at launchpad either
[23:24] <james_w> could you please run with "-Derror" as an extra command line argument to get a backtrace, and then pastebin that?
[23:24] <james_w> ubottu: paste
[23:27] <samatwork> here you go .... http://paste.ubuntu.com/37261/
[23:27] <james_w> samatwork: what about "bzr -Derror update"?
[23:28] <lifeless> luks: its not about historical data; its about decoupling representation and function
[23:28] <james_w> if it's the same then the problem is on the remote side, I think
[23:28] <lifeless> luks: if you want to to a fix for squid 3.0, on windows, you need EOL translation
[23:28] <lifeless> luks: but the 3.0 revision doesn't have .bzrrules
[23:30] <lifeless> luks: so I think having .bzrrules in the users tree is fine as a presentation layer today
[23:31] <lifeless> luks: but I want us to retain the ability to change representation in the future; without requiring a 'dump and reload' approach
[23:31] <lifeless> luks: think about CVS 'b' flags - they were not per-branch, there was no 'propogation' needed
[23:32] <samatwork> james_w: http://paste.ubuntu.com/37263/
[23:32] <samatwork> looks like it has something to do with an unexpected inventory format
[23:33] <james_w> it looks like corruption of the inventory on disk
[23:34] <samatwork> it must be on the side of the repository though since all clients point to it return the same message
[23:34] <samatwork> any thoughts on how to fix this short of recreating the repository?
[23:34] <james_w> I'm not sure
[23:35] <james_w> lifeless: any hints for samatwork?
[23:36] <jam> lifeless: my response has been emailed
[23:36] <lifeless> james_w: I'd use repository.get_inventory_xml to get the raw xml and look at it
[23:36] <jam> lifeless: I understand your concern, but I also feel you have at least 2 major things on your plate for 1.7
[23:36] <lifeless> samatwork: are you using bzr-svn ?
[23:36] <jam> bringing in a 3rd is not really going to happen
[23:37] <samatwork> lifeless: nope just straight bzr
[23:37] <lifeless> jam: If it needs to happen to avoid a mistake, it needs to happen
[23:37] <lifeless> jam: its a lot less stressful for me to do that than to see .bzrrules go in as-is
[23:37] <jam> I also have to say that the last messages from IGC don't look like agreement
[23:38] <lifeless> it will make nested-trees harder, join-tree and split-tree, it won't solve the usability problems the folk that I know that want EOL stuff on windows have
[23:38] <jam> They pretty much say "we need something, and this is the path of least resistance"
[23:38] <jam> which is where I fall
[23:38] <jam> I fully understand your conflict of interest
[23:38] <jam> And feel the same way
[23:38] <lifeless> if I had resolved it previously, I would have bb:vetoed this code
[23:38] <jam> I probably am more on the "frustrated by not having things like nested trees"
[23:38] <jam> for *years* now
[23:38] <jam> in any form
[23:38] <lifeless> full ack
[23:38] <jam> and taking what, >1 year to get any real in-core tags
[23:38] <jam> and we still have non-optimal ones
[23:39] <lifeless> note that git doesn't version its tags
[23:39] <jam> I guess sort of like the OpenGL 3.0 release... wait a year, and still get only something incrementally better.
[23:39] <lifeless> jam: that is because noone is spending time on these things, not because its a particularly hard problem
[23:40] <jam> lifeless: well, we had several designs that were possible
[23:40] <jam> and it was fundamentally a trade-off
[23:40] <jam> between complexity and handling all cases
[23:40] <jam> In git, moving a tag is a bad deal
[23:40] <jam> which it pretty much is in bzr as well
[23:40] <jam> trying to get it to propagate
[23:40] <jam> and deleting anything doesn't work
[23:42] <jam> (well, it deletes locally, but never propagates, etc)
[23:43] <jam> different topic... With LP, if I upgraded from Knit => pack-0.92 when  I upgrade from pack-0.92 => 1.6 won't that cause a problem with the backup.bzr directory?
[23:43] <jam> Is there a simple way to delete that?
[23:43] <jam> (Other than going in with abentley's hitchiker and doing a sftp deltree)
[23:44] <samatwork> thanks for the help everyone... I have to run
[23:45] <lifeless> jam: they are just refs in git, and their ref management is quite sophisticated
[23:46] <jam> lifeless: specifically, change a tag and pull into the next repo
[23:46] <jam> it won't propagate
[23:46] <jam> well, maybe just merge
[23:46] <jam> I think if you force a pull it will overwrite
[23:46] <jam> And I don't know about delete
[23:46] <lifeless> jam: I think you need hitchhiker
[23:47] <lifeless> jam: I'd file a bug on lp :P
[23:47] <jam> lifeless: I'm not doing it right now, I'm just upgrading a Knit repo
[23:47] <jam> and realizing we'll probably have a problem later
[23:51] <ben__> Hi! I have a question on how to clean up a repository e.g.:
[23:51] <ben__> bzr init-repository foobar
[23:51] <ben__> bzr init foobar/trunk
[23:51] <ben__> bzr branch foobar/trunk/ foobar/feature
[23:51] <ben__> dd if=/dev/urandom of=foobar/feature/random count=10000
[23:51] <ben__> bzr add foobar/feature
[23:51] <ben__> bzr ci foobar/feature
[23:51] <ben__> du -sh foobar/.bzr
[23:51] <ben__> 5,0M  foobar/.bzr/
[23:51] <ben__> how do I delete the branch feature out of the whole project?
[23:51] <Peng_> ben__: You pretty much don't.
[23:52] <ben__> theere
[23:52] <ben__> there is no way?
[23:53] <james_w> ben__: you mean you want to discard the branch, and free up the used disk space?
[23:53] <ben__> yes
[23:53] <ben__> the docu says i just have to rm foobar/feature
[23:54] <james_w> yeah, but that doesn't free up the space
[23:54] <ben__> but then I have the wasted space in .bzr
[23:54] <ben__> yes
[23:54] <james_w> there's no simple command to do this at the moment
[23:54] <ben__> is there already a bugreport (featurerequest) for this?
[23:54] <james_w> what you basically have to do is create a new repo, branch the branches you want in to it, and then delete the old one and move the new one in to place
[23:55] <james_w> I'm not sure
[23:55] <ben__> yes, that solution came into my mind, but it is not very nice…
[23:56] <james_w> no, it's not great
[23:56] <james_w> there's an experimental plugin to do it in one go if you want to test that
[23:56] <ben__> yes, of course ;))
[23:57] <ben__> but i didn't found one doing this at the homepage…