[00:01] <pooliex> spiv, jam, lifeless, call in a bit?
[00:02] <pooliex> abentley, do you want to join too?
[00:02] <spiv> Sure.
[00:03] <jam> pooliex: I'm on linux tonight, but I'll listen in
[00:04] <pooliex> i don't see you online yet
[00:04] <jam> pooliex: check now
[00:10] <abentley> pooliex: Sure.
[01:32] <abentley> jam: I understand your frustration re: path-LCA.  But I have planned my evening around reviewing it.  And the pokes just make me irritable.
[02:54] <jam> abentley: point taken, I'll try not to get in your face about it. It was meant more playfully anyway.
[03:33] <jml> lifeless: hi
[03:34] <jml> lifeless: I've figured out how to change the branch format for testing, but the repo format is giving me more problems.
[03:36] <jml> lifeless: it looks like the default repo fmt for metadir is derived from the bzrdir format registry
[03:59] <lifeless> oh
[04:20] <zbrown> Anyone have a good resource or example for writing hooks in bzr? Most of what I've come across seems somewhat vague
[04:28] <lifeless> zbrown: what sort of hooks?
[04:28] <lifeless> [much of the code base is hookable; its a pretty broad question]
[04:28] <zbrown> lifeless: would like to write a pre-commit hook for running a syntax checker and test suite
[04:28] <zbrown> lifeless: so "make syntax-check" and "make check"
[04:29] <lifeless> I believe spiv did work on this most recently
[04:29] <lifeless> spiv: ^ your public awaits
[04:29]  * zbrown awaits spiv eagerly
[04:29] <lifeless> zbrown: I'm grabbing lunch, I'll give you a hand if spiv hasn't when I return
[04:30] <zbrown> lifeless: ok, thanks
[04:30] <spiv> I did start writing some docs on this, let me refresh my memory.
[04:31] <spiv> zbrown: so you've already seen http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks ?
[04:33] <spiv> Actually, I need to go grab some lunch now too.
[04:33] <spiv> I'll be back in a while.
[04:37] <zbrown> spiv: I saw it, I guess I was a bit confused when I was trying to figure out how to do the pre-commit hook
[04:44] <jml> lifeless: any idea what to do about that?
[04:44] <jml> (when you get back from lunch)
[05:08] <zbrown> spiv: I might have figured it out :)
[05:13] <zbrown> hrm
[05:16] <lifeless> jml: hmm
[05:22] <zbrown> lifeless: any idea if its possible to make a hook that can be distributed with a project? That is a hook that a user doesn't have to add to his/her ~/.bazaar/plugins
[05:22] <zbrown> ?
[05:23] <lifeless> zbrown: hooks are arbitrary code, so there is a clear security issue there
[05:24] <lifeless> zbrown: generic hooks -  like the email one - allow them to be configured by a branch/proejct
[05:26] <lifeless> zbrown: there is also the shell-hooks plugin jelmer wrote, which as a generic plugin can be configured per-branch [though it runs arbitrary code, again security concerns apply]
[05:26] <zbrown> hmmm
[05:27] <zbrown> Guess my dream of minimal developer intervention is a bust, thats okay, just means copying a file to a directory ;)
[05:27] <zbrown> Thanks much :)
[05:27]  * zbrown is off to bed
[05:27] <lifeless> gnight
[05:28] <splodge> Can anybody tell me the best way of splitting a branch in two? If I have a 'trunk' branch and have want to split it so that some files are in branch 1 (b1) and the rest are in branch 2 (b2).
[05:28] <splodge> Is the preferred method (keeping the history and everything) to bzr branch it push it to a different place (on Launchpad) and then delete files in each branch that aren't required for it?
[05:30] <lifeless> splodge: that works well
[05:30] <splodge> This is actually part of a larger problem I'm solving: I have a project where some there are three parts - two separate and one shared. We figured that we would split the code across three branches and pull each one separately. Does anyone have any suggestions from experience on this or another layout to accomplish this?
[05:31] <splodge> Thanks lifeless
[05:32] <splodge> Sounds logical enough but thought it better to check ;)
[05:46] <splodge> actually, can someone help me with a layout. i'm struggling to come up with something that will meet my needs. i need three branches, each containing a number of modules (each module consisting several individual files). branches b1 and b2 don't share code but both use the modules in the shared branch 'core'. i then want to allow releases to be made by taking a snapshot of all three branches and placing the in another location.
[05:47] <AfC> Sounds like you just need a shell script
[05:47] <splodge> i want to be able to group them, i guess then. so perhaps trunk/b1, trunk/b2 and trunk/core? with releases like r1/b1, r2/b2 and r2/core? hmm...
[05:49] <splodge> AfC: can you elaborate?
[05:49] <splodge> i suspect i'm overthinking this :(
[05:50] <lifeless> splodge: why not, three branches; A, B, C
[05:50] <lifeless> A has whatever including core
[05:50] <lifeless> B has whatever including core
[05:50] <lifeless> C is just core
[05:50] <lifeless> and you merge from C to A and/or B as needed
[05:50] <splodge> oh i see. that could work.
[05:51] <splodge> there is duplication there though isn't there
[05:52] <lifeless> how so ?
[05:52] <splodge> with C's code being duplicated into both A and B's and relying on the devs remembering to merge in.
[05:53] <splodge> we also only want one copy of C when checked out
[05:53] <lifeless> well
[05:53] <lifeless> either you have three projects
[05:54] <lifeless> which are independent
[05:54] <lifeless> or you have < 3.
[05:54] <lifeless> decide :)
[05:54] <splodge> ummm... :)
[05:54] <lifeless> how big is C? GB's? TB's ?
[05:55] <splodge> oh they're only small at the moment and we don't expect them to grow into GBs
[05:56] <splodge> at the moment it's paltry: <100MB :)
[05:57] <lifeless> so
[05:57] <splodge> if it helps clarify a little: they are parts of the same project. it uses drupal and we have two sites (supplied by code in branches A and B) and a common lot of modules (C).
[05:57] <splodge> so A is checked out to sites/site1/modules/A and B to sites/site2/modules/B, and C to sites/all/modules/C
[05:57] <lifeless> what you want might strictly be nested trees, but that feature isn't finished yet.
[05:58] <lifeless> what I describe is probably the cheapest and most robust thing available today.
[05:58] <splodge> ok
[05:59] <splodge> thanks
[06:08] <AfC> splodge: if you can be flexible enough to maintain the different branches lifeless describes, I'd encourage you to follow that idea. It will work well if you keep it simple.
[06:09] <splodge> thanks. i'm just doing more reading up on this and then i'll make a decision, but it looks like that's the way i'll probably go.
[06:09]  * splodge still has a bit to learn :)
[06:15] <AfC> It is indeed easy to overthink these things. Actually, that's a common problem in most software development and related activities.
[06:21]  * fullermd thinks about that for a week or two.
[06:46] <jml> lifeless: ok, now *I'm* back from lunch
[06:49] <jml> lifeless: are we still stuck for ideas?
[06:49] <lifeless> is it too broad to say 'we should fix it' ?
[06:49] <lifeless> I mean, if someone asks for 'default' as a format, they get a fully specified BzrDirMeta format
[06:50] <lifeless> if they do BzrDirMetaFormat(), does that need to be == ? I think not, which is why changing the branch was snesible
[06:50] <lifeless> Repository can probably just stop asking for 'default' and ask for BzrDirMetaFormat9), IFF it has lost its old explicit default information
[07:24] <jml> lifeless: can I call you about this stuff?
[07:46] <lifeless> jml: yes
[07:47] <jml> lifeless: skype ok?
[07:47] <lifeless> yes
[07:52] <Peng_> lifeless: bzrlib/readdir.h is copyright 2006?
[07:53] <lifeless> Peng_: yes
[07:53] <lifeless> Peng_: annotate it :P
[07:54] <Peng_> Hmm, _ReadDirFeature.feature_name returns 'bzrlib._btree_serializer_c'?
[07:54] <lifeless> heh, good catch
[07:54] <lifeless> I'll fix in a minute
[07:55] <Peng_> :)
[07:55] <pooliex> lifeless, that book is pretty entertaining/interesting
[07:56] <lifeless> good
[08:39] <techtonik> About that "rebase" plugin..
[08:49] <pooliex> vila, hi, are you up?
[08:49] <vila> pooliex: sure, for nearly 2 hours
[08:54] <pooliex> how's it going?
[08:58] <techtonik> So, about that rebase plugin.. It would be good extremely helpfult to remove references to git from "rebase" documentation, because it fails to clearly explain any usage examples without sending adepts to enlightning by smoking git man.
[08:59] <guilhembi> pooliex: hi! there? time of our phone call?
[08:59] <pooliex> guilhembi, hi!
[09:00] <vila> pooliex: summarizing how we show revisions in various commands to see how to fix bug #233817
[09:00] <pooliex> techtonik, good point
[09:00] <pooliex> vila, that sounds like a good place to start
[09:02] <vila> I think the simplest way to fix it is to implement --show-merged or something first and then we can look at bringing more consistency between the various commands
[09:03] <vila> I'll mail the list about that
[10:17] <jelmer> hmm, the bzr-svn testsuite is now running out of file descriptors :-(
[10:17] <jelmer> is there any way to force selftest to do garbage collection more often?
[10:21] <uws> jelmer: import gc; gc.collect() ? ;)
[10:25] <techtonik> from "rebase" documetation at http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html (well, bzr doesn't have such examples)
[10:25] <techtonik> Home come that for the following branch     E---F---G---H---I---J  topicA
[10:25] <techtonik> given the command    git rebase --onto topicA~5 topicA~3 topicA
[10:26] <techtonik> the removed revisions are F and G ???
[10:40] <Odd_Bloke> techtonik: It's saying rebase the revisions from revision 'HEAD minus 3' to the HEAD revision onto 'HEAD minus 5'.
[11:02] <markh> jelmer: why do you ask about the gc?  ie, what symptoms you see without it?
[11:06] <markh> I've a patch in the queue that adds a few try/finally blocks to ensure a few files etc are closed upon error, which avoids most problems that a gc.collect() happens to solve
[11:07] <markh> on windows anyway ;)
[11:14] <jelmer> ah, ok
[11:14] <jelmer> could be that it helps then
[11:15] <markh> jelmer:         ico_map = dict(map_items)
[11:15] <markh> bugger :)
[11:16] <markh> oh, why can't I copy/paste from my vm!
[11:17] <markh> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C019a01c8fe73%2427a26f30%2476e74d90%24%40com.au%3E
[11:25] <techtonik> Odd_Bloke: thanks, the idea of relative revisions is something I could not even imagine before =)
[11:25] <Odd_Bloke> techtonik: No worries.
[11:26] <techtonik> Just for interest I've run testcase with 1.6 standalone on Windows 2000
[11:26] <techtonik> FAILED (failures=120, errors=267, known_failure_count=11)
[11:26] <techtonik> 969 tests skipped
[11:26] <techtonik> Is it really ok?
[11:28] <awilkins> techtonik: It's not perceived as "OK" but it is the status quo
[11:28] <awilkins> techtonik: Efforts are being made to reduce and eventually (?) eliminate windows failures
[11:29] <techtonik> Cool. Seems like an interesting stuff to do.
[11:30] <awilkins> techtonik: As a fairly heavy user on windows I can tell you that I only enounter one or two issues in daily use, and my usage pattern is pushing the envelope as far as the average user goes
[11:30] <awilkins> Most of my frustration is with the IIS server support but that seems to be reasonably functional now, esp. from IIS 7
[11:30] <markh> techtonik: yeah, its really OK
[11:31] <awilkins> (and it's mostly the fault of IIS for being a rather inflexble webserver)
[11:31] <markh> awilkins: I've done alot with IIS and ISAPI actually
[11:31] <awilkins> markh: I've got HPSS working out of IIS with PyISAPIe
[11:31] <markh> what problems did you have with iis6?
[11:32] <awilkins> markh: https://bugs.launchpad.net/bzr/+bug/262366
[11:32] <markh> right - I've got to catch up on pyISAPI - IIUC, it leans in pywin32's isapi support, which I've only used "natively"
[11:32] <markh> actually just released a 64bit isapi proxy server written in python :)
[11:32] <techtonik> it seems to work here too, but i have to keep some settings in batch files and run local proxies and tunnels, which is complicated for other people in a team, esp. testers
[11:34] <techtonik> i would say that bzr is extremely complicated in setup, but once it works it's a pleasure
[11:34] <awilkins> techtonik: !
[11:34] <awilkins> techtonik: The server infrastructure can be complex, but basic use is very simple once you understand a couple of things
[11:34] <lifeless> awilkins: skips are not a problem
[11:35] <techtonik> awilkins: so far I am using only client with launchpad
[11:35] <awilkins> lifeless: skips?
[11:35] <lifeless> awilkins: skips are normal - they relflect that not all things implement all interfaces; and other such status; this is what I alluded too recently on-list
[11:35] <awilkins> Oh, yes, skipped tests
[11:35] <lifeless> oh. I missed the lines before skipped :)
[11:35] <lifeless> obviously the failures are status quo :P
[11:36]  * awilkins thought briefly about KP Skips
[11:37] <markh> awilkins: right - I think you need to trick IIS6.
[11:37] <awilkins> markh: http://bazaar-vcs.org/ServerGuide/IIS
[11:37] <markh> approach we took was to use a filter to "rewrite" the request to a virtual folder we own.  That virtual folder has an extension that maps to '*' - it 'unrewrites' the URL, then does what it does
[11:37] <markh> that way it gets everything
[11:37] <awilkins> markh: What I think needs to happen is that PyISAPIe needs to support a particular call to the ServerSupportFunction API
[11:38] <markh> awilkins: which call is missing?
[11:38] <markh> most are there
[11:38] <awilkins> The one that "passes" the request to the next handler in the chain (in this case, IIS itself)
[11:38] <markh> that is there...
[11:38]  * markh looks
[11:38] <Jc2k> .wg 16
[11:38] <Jc2k> ;_;
[11:39] <awilkins> markh: If you can tell me how to do it from the Python API, I'll fix my server script and IIS 6 will be golden
[11:39] <markh> the filter just returns isapicon.SF_STATUS_REQ_NEXT_NOTIFICATION
[11:39] <markh> I'm not sure pyISAPI supports filters
[11:40] <markh> they are quite different than extensions
[11:40] <awilkins> No, it's an extension
[11:40] <awilkins> But if you use extensions as wildcard extensions in IIS6 you can apparently get them to pass on a particular request
[11:40] <markh> yes - to do what I said you need a filter *and* an extension
[11:41] <markh> see the 'redirector.py' sample in pywin32's isapi/samples directory
[11:41] <markh> right
[11:41] <awilkins> markh: I have it working through just the extension
[11:41] <markh> yes, that avoids the need for a filter at all with iis7
[11:41] <markh> I mean to get iis6 working
[11:41] <awilkins> markh: It just breaks if you use plain http://
[11:42] <markh> so - I can't recall exactly what is missing to do what you refer to for iis7 - but I do recall looking at it in the past :)
[11:42] <awilkins> markh: David Wangs blog refers to this
[11:43] <awilkins> http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_IIS_6_Request_Pro
[11:43] <awilkins> cessing_Basics_Part_1.aspx
[11:44] <awilkins> http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_IIS_6_Request_Processing_Basics_Part_1.aspx
[11:44] <awilkins> sorry
[11:45] <awilkins> It's not exactly clear about how you say "I'm handling this" or "I'm not"
[11:46] <techtonik> "rebase" doesn't work as in git.
[11:47] <techtonik> I would like to remove revision 5 from history using rebase using the command     bzr rebase --onto=5 -r 6 . --dry-run
[11:48] <techtonik> It says No revisions to rebase.
[11:48] <markh> awilkins: yeah - iis6 sucks that way - and the filter can be used to work around it (ie, to make it easier to say what you handle).  iis7 does add something new iirc to make the filter unnecessary.
[11:49] <awilkins> markh: Yes, you can use proper wildcards to choose handlers, not that "file extension" crap
[11:50]  * markh starts having inklings about SF_NOTIFY_PREPROC_HEADERS..
[11:50] <markh> so - IIRC, the fact only filters can do what SF_NOTIFY_PREPROC_HEADERS does is the main "problem" that forces us to use a filter
[11:51] <markh> and that later IIS versions allow extensions to perform that role
[11:51] <awilkins> markh: The discussion in the posted blog would seem to indicate that you can get a wildcard extension to pass a request to the next handler though ; I just wish it was more explicit as to how
[11:52] <markh> yeah - and SF_NOTIFY_PREPROC_HEADERS is where you can modify the URL variable to *force* the request to your extension
[11:52] <markh> regardless of extension etc
[11:55] <awilkins> markh: My working theory was that you call ServerSupportFunction with HDS_REQ_EXEC_URL
[11:55] <awilkins> Meh. So you have a filter that remaps /.bzr/smart to a different virtual dir with the smart server on it?
[11:55] <markh> iis7 can do that without a filter iiuc - but I can't recall if can yet ;)
[11:55] <markh> if pywin32
[11:56] <awilkins> markh: My working theory was that you call ServerSupportFunction with HDS_REQ_EXEC_URL
[11:56] <awilkins> But I'm a little in the dark really - the documentation is a bit murky
[11:59] <markh> awilkins: yes!  that's the one :)
[11:59] <awilkins> http://msdn.microsoft.com/en-us/library/ms525758.aspx
[12:00] <awilkins> So what I was wanting was a facility in PyISAPIe to call that and pass the request down the chain to the normal IIS handler
[12:00] <markh> so yeah, I should add that to pywin32 and that redirector sample.  However, that doesn't help iis6 :(
[12:00] <awilkins> That is an IIS6 function
[12:01] <markh> oh right - 5 :(
[12:01] <markh> I'm a version behind - no good in win2k
[12:01] <markh> but we can ignore that these days ;)
[12:02] <awilkins> It's not like it's hard, but my C is bad.
[12:02] <markh> I think the idea is you call that function that the current request "restarts" using the new URL
[12:03] <markh> anyway - dinner and g/f have arrived :)
[12:03] <awilkins> Go smell the sweet scents of food and female, see you later :-)
[13:26] <palango> do anybody have ever used the bzr-rebase plugin?
[13:27] <jelmer> palango, yes :-)
[13:28] <palango> great :)
[13:28] <palango> I 've some problems using it
[13:28] <jelmer> techtonik, rebase is evil, one of the main reasons bzr-rebase exists is for git refugees
[13:28] <F_R_A_N_K> Hi All
[13:28] <jelmer> hi F_R_A_N_K
[13:28] <palango> please have a look at: http://paste.ubuntu.com/43043/
[13:29] <palango> I'm creating a parent branch and and child branch
[13:29] <palango> adding some revisions to the child
[13:29] <palango> and as far as I understood the rebase command it will make one revision out of these two
[13:30] <F_R_A_N_K> I have a quick simple question (I guess). If I upgrade a branch (bzr upgrade). Is there a risk that someone else with an older version of bzr can't work with this branch anymore/is getting problems?
[13:30] <jelmer> F_R_A_N_K, Yes - users with older bzrs can't use an upgraded branch
[13:31] <jelmer> F_R_A_N_K, see "bzr upgrade --help" for the list of minimum versions required
[13:31] <techtonik> jelmer: when what is the true way of taking revision out of history? or better replacing it with somthing else?
[13:31] <jelmer> palango, bzr rebase doesn't combine revisions
[13:32] <F_R_A_N_K> Jelmer: What  will happen then, are they getting warned that they need to upgrade? Or do tthey get a weird error message?
[13:32] <jelmer> F_R_A_N_K, They'll get a one-line error message like "Unknown branch format: Rich Root Pack (needs bzr 1.0)"
[13:32] <F_R_A_N_K> ok
[13:33] <palango> jelmer: what does it do then?
[13:33] <jelmer> palango: it replays revisions on top of a different parent
[13:34] <jelmer> techtonik, why would you want to take a revision out of history?
[13:35] <F_R_A_N_K> Jelmer, as I read it you need minimum V0.92 of bazaar. Correct?
[13:36] <jelmer> F_R_A_N_K, depends on what format you upgade to
[13:36] <jelmer> packs-0.92 needs bzr 0.92
[13:37] <techtonik> jelmer: well, because I've submitted wrong comment under wrong commit and I need either replace commit or edit comment
[13:37] <palango> jelmer: I read http://www.gnome.org/~federico/news-2008-08.html#12 and thought bzr-rebase does the same!?
[13:38] <jelmer> techtonik: Any reason for not uncommitting?
[13:38] <jelmer> palango, bzr-rebase doesn't have --interactive
[13:38] <F_R_A_N_K> I am facing reall speed problems. I also opened a ticket for it. Still having these repositoryFormatKnit1 formats. It was suggested to upgrade (bzr also gives this advice). So what version would be best to get much better performance?
[13:38] <techtonik> jelmer: well, only one - history log afterwards
[13:39] <palango> jelmer: is this planned?
[13:39] <jelmer> F_R_A_N_K, pack-0.92 (the default) would be the best choice
[13:40] <jelmer> techtonik, ah, ok
[13:40] <jelmer> techtonik, in that case, rebase probably would be the best choice indeed
[13:40] <F_R_A_N_K> Jelmer, thanks. I will. So everyone who has a newer version then 0.92 of bzr woundn't face any problems.
[13:40] <jelmer> F_R_A_N_K, correct
[13:41] <jelmer> 0.92 is almost a year old atm
[13:41] <F_R_A_N_K> we started our project 7mnths ago
[13:41] <F_R_A_N_K> most users started 5 mnths ago
[13:42] <F_R_A_N_K> AFAIK all versions are >V1.2
[13:42] <techtonik> jelmer: but it doesn't work. for example if I want to omit revision 5    bzr rebase --onto=5 -r 6 . --dry-run
[13:42] <techtonik> It says No revisions to rebase.
[13:43] <jelmer> techtonik: That command doesn't make sense, r6 already has r5 as parent
[13:43] <F_R_A_N_K> Jelmer: bzr: ERROR: Revision {('arjan@iceshop.nl-20080422081505-59su2hfkrs8eguwc',)} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x8776fcc>".
[13:43] <spiv> F_R_A_N_K: with 1.6?  I think that's fixed in 1.6.1rc1.
[13:43] <jelmer> F_R_A_N_K, You may have to run "bzr reconcile" before upgrading
[13:44] <F_R_A_N_K> yes with 1.6
[13:44] <spiv> (Or I could be misremembering)
[13:44]  * spiv -> bed
[13:45] <F_R_A_N_K> reconcile I already tried yesterday, it takes more then 5 hours to run........... So I aborted it.
[13:46] <techtonik> jelmer: Ok.   bzr rebase --onto=5 -r 7 . --dry-run   works the same
[13:47] <jelmer> F_R_A_N_K, please try 1.6.1rc1 like spiv is suggesting
[13:47] <jelmer> F_R_A_N_K, reconcile should be faster with packs, but that's a bit of a chicken/egg problem :-(
[13:47] <F_R_A_N_K> Now it runs in 1 sec.
[13:47] <F_R_A_N_K> all okay it says
[13:49] <F_R_A_N_K> How do I do this? V1.6 is the latest if I upgrade.
[13:50] <uws> may I suggest a less annoying nickname for F_R_A_N_K?
[13:51] <pasky> I'm somewhat confused about the currently used merge methods in Bazaar - does Bazaar currently use the classic three-way merge or something else?
[13:51] <pasky> wiki describes various things like knit merge but it's not clear what are the currently available methods and which one is the default
[13:55] <uws> pasky: see "bzr help merge"
[13:55] <uws> Frenzel: (thanks)
[13:55] <Frenzel> uws: This better? :-)
[13:55] <Frenzel> Jelmer: how do I check if all is okay now?
[13:56] <pasky> uws: can i view that documentation somewhere online?
[13:56] <luks> pasky: standard 3-way merge by default
[13:56] <jelmer> Freaky: Sorry, what runs in one second now?
[13:56] <uws> pasky: dunno, but it's included in your bzr installation
[13:56] <luks> and it has two other optional merge modes
[13:56] <pasky> i don't currently have any bzr installation handy :)
[13:57] <luks> pasky: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#merge
[13:57] <uws> pasky: http://pastebin.com/m6a5eacd  ;)
[13:57] <pasky> thanks both! :)
[13:57] <Frenzel> jelmer: bzr reconcile
[13:57] <uws> though luks' suggestion is probably better
[13:58] <jelmer> Frenzel, ah,ok
[13:58] <jelmer> Frenzel, in orderto be ableto run upgrade correctly, I think you'll haveto downgradeto 1.5 or upgradeto 1.6.1rc1
[13:59] <Frenzel>  bzr reconcile
[13:59] <Frenzel> Reconciling branch file:///var/bzr/batavi/
[13:59] <Frenzel> revision_history ok.
[13:59] <Frenzel> Reconciling repository file:///var/bzr/batavi/
[13:59] <Frenzel> Reconciliation complete.
[14:00] <pasky> hmm, are the non-default merge algorithms used commonly?
[14:01] <Frenzel> pasky: only normal merges are done
[14:01] <Peng_> pasky: The LCA and weave merge algorithms handle criss-crossing better, so I use them sometimes.
[14:01] <pasky> so the default is merge3? how does it handle multiple lcas?
[14:01] <pasky> ah
[14:02] <Frenzel> Jelmer: what to do now? Upgrade again?
[14:03] <Frenzel> I have now version V1.6.1RC1 installed
[14:03] <jelmer> Frenzel, yep
[14:03] <Frenzel> Is there a risk that this goes wrong? becuase then I like to go back to the old version and test it before doing this live again.
[14:06] <Frenzel>  bzr upgrade --default
[14:06] <Frenzel> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[14:07] <Frenzel> a checkout now gives:bzr: ERROR: Could not install revisions:
[14:07] <Frenzel> dimitry@iceshop.nl-20080902143335-49g8v32pi88v1v14
[14:08] <Frenzel> Jelmer: any ideas?
[14:09] <jelmer> Frenzel, that's with 1.6.1rc1 ?
[14:09] <jelmer> Frenzel, if so, I have no idea :-( Perhaps jam can comment when he wakes up
[14:09] <Frenzel> local I have V1.6
[14:09] <Frenzel> remote is V1.6.1RC1
[14:10] <Frenzel> Jelmer, can we revert this upgrade? If I am correct the upgrade make a backup right?
[14:11] <jelmer> Frenzel, yes, it keeps a copy of .bzr in backup.bzr
[14:11] <Frenzel> how to revert it?
[14:11] <Frenzel> is there a command for it?
[14:13] <Peng_> Frenzel: Just rename the directories
[14:18] <Frenzel> Peng_: tnx, it worked
[14:18] <Frenzel> back to old version
[14:20] <Frenzel> Will retry tonight again, when I have more time.
[14:20] <Frenzel> Bye guys!
[14:45] <strk> I found gnulog.py to generate ChangeLog , but doesn't work with bzr 1.6 looks like, can you confirm ?
[14:46] <LarstiQ> strk: possibly.
[14:46] <strk> http://telecom.inescporto.pt/%7Egjc/gnulog.py
[14:46] <strk> is there a more up-to-date place for distribution of such plugins ?
[14:46] <LarstiQ> strk: http://bazaar-vcs.org/BzrPlugins
[14:46] <LarstiQ> but that url seems to be the current known location
[14:46] <strk> yep, same url
[14:47]  * LarstiQ downloads the plugin
[14:47] <LarstiQ> strk: it shouldn't be too difficult to bring it up to date.
[14:48] <strk> just sent a mail to the author
[14:49] <LarstiQ> strk: what part of it doesn't work for you?
[14:49] <LarstiQ> oh wait, I tried it with 1.5
[14:49] <strk> bzr log -v --log-format 'gnu'
[14:49] <strk> bzr: ERROR: Bad value "gnu" for option "log-format".
[14:50]  * LarstiQ did bzr log --gnu
[14:50] <strk> don't even know if the plugin is loaded actually
[14:50] <strk> bzr: ERROR: no such option: --gnu
[14:50] <strk> how can I tell if it's been loaded ?
[14:50] <LarstiQ> strk: where did you leave the plugin? And see `bzr plugins` for a list of loaded ones
[14:50] <strk> in ~/.bazaar/plugins
[14:50] <strk> ops, indeed 'bzr plugins' doesn't find it
[14:51] <LarstiQ> strk: correct location
[14:51] <LarstiQ> strk: check ~/.bzr.log to see why it fails to load.
[14:51] <strk> correct extension too ? *.py ?
[14:52] <strk> there's no trace of it in .bzr.log
[14:52] <strk> other plugin seems to be loaded from /usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py
[14:52] <LarstiQ> strk: yup, that's fine.
[14:52] <strk> um
[14:52] <strk> 0.049  looking for plugins in /home/strk/.bazaar/plugins
[14:52] <strk> 0.049  looking for plugins in /usr/lib/python2.5/site-packages/bzrlib/plugins
[14:53] <LarstiQ> strk: although the recommended way to do plugins is to have them in a dir
[14:53] <strk> there's an ignore file under ~/.bazaar/plugins
[14:53] <strk> containing a line: *.py[co]
[14:53] <strk> shouldn't match .py though
[14:54] <LarstiQ> I'm not aware of plugin loading using ignore files.
[14:54] <strk> ah, I didn't have the 'plugins' subdir
[14:54] <strk> seems to be working now
[14:54] <LarstiQ> you had ~/.bazaar/gnulog.py instead of ~/.bazaar/plugins/gnulog.py?
[15:07] <strk> yep
[15:10] <LarstiQ> strk: ah :)
[15:20] <strk> did anyone think about adding more verbosity to it ?
[15:20] <strk> we mostly commit in branches, then merge, then commit to trunk
[15:20] <strk> gnulog.py does NOT include commit logs from branches, which are the more interesting usually
[15:29] <LarstiQ> strk: you'll have to find other users of it :)
[15:49] <jam1> abentley: ping, I need a bit better understanding of the InterKnit1And2 definitions for bug #264321
[15:49] <jam1> I thought it was about subtree support
[15:49] <jam1> but it seems to actually be about rich-root support
[15:52] <abentley> jam: well, RepositoryFormatKnitPack5RichRoot uses a serializer that supports subtrees, even though it's only supposed to support rich roots.
[15:53] <abentley> Your diff doesn't apply to bzr.dev
[15:58] <abentley> jam: It's not about subtree support.  It's about rich-root support.
[15:59] <abentley> jam: There's no fancy footwork needed to convert from rich-root to subtree.  You just deserialize and reserialize.
[16:02] <jam> abentley: ok, so the basic patch is correct? That the variable names were wrong
[16:02] <jam> so the ones in the "yes" column should support rich-root
[16:02] <jam> and the ones in the "no" column should not
[16:03] <abentley> jam: I guess.  It's hard to tell-- you've removed all lines and then added them again.
[16:05] <jam> abentley: ah, the conflict is that robert got rid of "development0" in bzr.dev
[16:05] <jam> so it needs to be "development1" in the various places
[16:06] <abentley> jam: I thought development1 was in 1.6 also.
[16:06] <jam> abentley: it wasn't expose to this location
[16:06] <jam> people have really *not* been keeping this up-to-date
[16:06] <jam> for 1.6.1 I added a bunch of them
[16:06] <jam> but thought it was about subtree support
[16:06] <jam> and obviously was wrong
[16:07] <abentley> It's because we introduced rich-root formats after this.
[16:07] <jam> abentley: http://rafb.net/p/3EoJiR97.html
[16:07] <jam> That is the diff
[16:07] <jam> without the extra comments
[16:08] <jam> KnitPack4 is a subtree format
[16:08] <jam> wait, it is rich-root-pack
[16:08] <jam> Hence why I thought it should go in "nosubtrees"
[16:09] <abentley> jam: It looks fine to me.
[16:19] <jam> abentley: would it be better to just use:
[16:19] <jam> if not source_format.rich_root_data and target_format.rich_root_data:
[16:19] <jam> instead of manually tracking them a second time?
[16:19] <abentley> jam: You also have to ensure that they are knit formats.
[16:20] <jam> abentley: so (atm) everything > weave, right?
[16:21] <jam> I guess I'll leave it alone for right now
[16:21] <jam> But I know it was getting out-of-date before *I* touched it for 1.6.1rc1
[16:21] <jam> I don't remember specifically what was missing, but new formats weren't in the lists
[16:22] <abentley> jam: correct, everything since weaves.
[16:38] <jam> abentley: I think this is a requirement to go into a possible 1.6.1, but I'm wondering at this point if we should just punt for 1.7rc1 which will be available on Monday
[16:38] <jam> I suppose for people who care, 1.6.1 will be a smaller update than 1.7
[16:39] <jam> james_w: what is the Intrepid status/policy ?
[16:39] <abentley> jam: I thought Intrepid was a reason for 1.6.1
[16:39] <abentley> jam: :-)
[16:39] <jam> abentley: *severe* performance problems with 1.6 and not realizing 1.7 was just around the corner was 1.6.1
[16:40] <james_w> jam: I was going to put 1.6.1 in, as it fixes an important bug, and then look at 1.7 when it comes out
[16:40] <abentley> jam: I don't want 1.6 in Intrepid, but otherwise, I'm cool with just getting 1.7 out.
[16:40] <jam> james_w: so what you are saying, is that if I "fail" to get this important bug-fix in for 1.6.1, then you'll be forced to include 1.7?
[16:41] <jam> :)
[16:41] <james_w> that could be one way to do it
[16:42] <james_w> though if they don't want to risk 1.7 they'll just ask for patches to be backported to 1.6
[16:43] <jam> james_w: I'll just make sure the patches won't apply to 1.6
[16:43] <jam> O:-)
[16:44] <jam> Eventually I think you just have to cut a release, though. And 1.6.1 seems to be pushed back farther and farther...
[16:54] <Lea> Does anyone know how I can version control files that include timestamps, i.e. <entry name="idle_delay" mtime="1207992864" type="int" value="120"> - i don't want files which only differ in mtime to show up in diff/status, or be commited etc.
[16:55] <EarthLion> hey how do you commit with a . number e.g. 9.56 ?
[17:26] <CardinalFang> Lea, I don't think you can ignore changes to files based on very specific content changes.  It sounds like you're saving the wrong thing, or misusing version control.
[17:30] <CardinalFang> Lea, Perhaps you should process the file into something new, and save that.
[17:31]  * Lea is attempting to version his home directory. however some programs have very annoying config file formats, such as everything using gconf.
[17:45] <CardinalFang> Lea, yep.  This shows a fundamental flaw in home-dir tracking.  Some files are often and automatically changed with opaque data.
[17:56] <vila> gnight all
[18:00] <LarstiQ> Lea: a more succesful approach might be to have a seperate directory under your homedir you track, with a facility to build symlinks to the files under that.
[18:01] <Lea> LarstiQ, that is in fact what i have
[18:02] <LarstiQ> Lea: ah, and there are files you _do_ want to track, but they get touched too often?
[18:02] <Lea> yup. problem is the data in the file isn't changing - however gconf is deciding to rewrite said files and changes the timestamps *inside* the file
[18:03] <LarstiQ> great.
[18:03] <LarstiQ> Lea: can you tell gconf to not do that?
[18:04] <Lea> i've been looking but i can't find anything about it. it seems to be the app rewriting all the settings back into gconf, even when they haven't changed
[18:05] <LarstiQ> ok.
[18:05] <LarstiQ> Lea: there isn't anything that immediately comes to mind, but it should be possible with some plugin work I guess.
[18:08] <Lea> k. thanks
[18:55] <fattymattyo> how do I specify the port when using bzr?
[18:56] <luks> fattymattyo: hostname:port
[18:56] <fattymattyo> simple enough :-)
[18:57] <tacone> luks: how to do that with the lp: syntax ?
[18:57] <luks> tacone: why would you want to?
[18:58] <luks> you can't use launchpad on different ports
[18:58] <tacone> luks: guess it's me that misunderstood the issue fattymattyo was having.
[18:59] <fattymattyo> the issue I'm having is that my ssh_config has my port set to something other than 22 so it tries to connect on a different port
[19:00] <fattymattyo> and obviously doesn't work.
[19:00] <tacone> here's the command he used: bzr push lp:~fattymattyo/rapache/newguy_branch
[19:00] <fattymattyo> so I get this error...
[19:00] <fattymattyo> ssh: connect to host bazaar.launchpad.net port 1031: Connection timed out
[19:00] <fattymattyo> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[19:00] <LarstiQ> fattymattyo: I'd suggest an entry for launchpad.net in ~/.ssh/config
[19:02] <luks> oh, so you have globally set the SSH port to 1031 for all clients?
[19:02] <fattymattyo> yes
[19:02] <luks> I've never seen such configuration
[19:02] <fattymattyo> apparently most people haven't
[19:04] <fattymattyo> 90% of my servers are set up on the same port so it was easier for me
[19:05] <fattymattyo> looking up the .ssh/config file I've never played with that before.
[19:08] <fattymattyo> luks that seems to have worked, thanks for the help guys
[20:04] <guilhembi> jam: hello! one good thing:
[20:04] <guilhembi> I tested
[20:04] <guilhembi> https://bugs.launchpad.net/bzr/+bug/238895
[20:05] <guilhembi> with --weave of your merge_lca_multi,
[20:05] <guilhembi> and it outpus a conflict as desired.
[20:05] <guilhembi> outputs
[20:06] <guilhembi> and same with bzr.dev
[20:06] <jam> guilhembi: yeah, that should probably be marked as fixed in 1.6
[20:07] <jam> the new --weave format fixes it.
[20:07] <jam> "--weave code"
[20:07] <jam> but I guess --lca still has the issue
[20:08] <guilhembi> jam: to confirm what you wrote, I just tested with --weave of bzr 1.3 --weave and it didn't see a conflict.
[20:09] <guilhembi> jam: yes, --lca still has the issue. Though for MySQL, we'll use --weave.
[20:09] <jam> guilhembi: yeah, in <1.6 'bzr merge --weave' was still an "annotation" merge not a real --weave merge.
[20:09] <jam> well, until you go back to 0.8 or so :)
[20:21] <jelmer> spiv, do you have any experience with coroutines in Python?
[20:23] <LarstiQ> jelmer: didn't stackless allow you to make those with generators?
[20:23] <jelmer> 2.5 also has something
[20:24] <radix> python doesn't have coroutines
[20:24] <radix> (unless you're talking about greenlet, the crazy C extension module)
[20:26]  * LarstiQ reads http://www.weightless.io/coroutines
[20:27] <Jc2k> jelmer: are you thinking of yield..
[20:27] <jelmer> radix, http://docs.python.org/whatsnew/pep-342.html claims it does
[20:28] <radix> jelmer: yes, and it's lying
[20:29] <radix> jelmer: the fundamental difference between 2.5 generators and coroutines is that you can't context switch multiple stack frames at a time
[20:34] <jelmer> radix, ah, ok
[20:34] <jelmer> radix, Do you have any experience with greenlet?
[20:34] <LarstiQ> jelmer: actually, I think the people behind http://www.weightless.io/weightless wanted to give a talk about it at one of the PUN meetings
[20:34] <radix> jelmer: yes
[20:34] <jelmer> radix, Is it worth a shot?
[20:35] <radix> jelmer: I also wrote a bunch of concurrency stuff with generators
[20:35] <radix> jelmer: it is unclear whether greenlet is not horribly buggy
[20:35] <radix> the author doesn't really maintain it
[20:35] <jelmer> oh :-(
[20:36] <LarstiQ> radix: any comments on weightless?
[20:36] <jelmer> lua does this really well, I'm trying to get close to that with Python
[20:36] <radix> jelmer: what are you trying to do?
[20:36] <radix> LarstiQ: never heard of it
[20:36] <radix> LarstiQ: URL?
[20:36] <LarstiQ> radix: http://www.weightless.io/weightless
[20:37] <radix> LarstiQ: is this a python thing?
[20:37] <radix> I guess it doe
[20:38] <jelmer> radix: Trying to see if there's some way winbind can be reimplemented in Python (basically a server handling fancy database queries for multiple clients, preferably using coroutines
[20:38] <LarstiQ> radix: yes, it is
[20:38] <LarstiQ> jelmer: http://mail.python.org/pipermail/python-nl/2008-July/000826.html
[20:38] <radix> LarstiQ: you may be interested to know that I am a Twisted developer, before I start offering my opinions: )
[20:39] <radix> I'm also the author of Corotwine, which is a twisted/greenlet integration library
[20:39] <jelmer> LarstiQ, thanks!
[20:39] <LarstiQ> radix: yes, I know that :)
[20:39] <radix> LarstiQ: the first thing I notice about weightless is that it's not Twisted :)
[20:39]  * LarstiQ nods at radix 
[20:40] <radix> it does seem to have more advanced integration with generators
[20:40] <LarstiQ> jelmer: oh, and the post Erik refers to: http://mail.python.org/pipermail/python-nl/2008-June/000791.html
[20:40] <radix> Twisted has inlineCallbacks, which is a way to use generators to deal with Deferreds using serial code
[20:47] <jelmer> radix: what do you mean by "it is not unclear whether it is not horribly buggy" ? It's unreliable/unstable or simply?
[20:47] <radix> jelmer: I think there is some debate about whether it integrates with garbage collection in a fundamentally broken way
[20:47] <radix> jelmer: it seems that it may be easy to have uncollectable objects live forever
[20:48] <radix> I haven't done much research into it myself, but I think arigo has acknowledged the problem
[20:48] <jelmer> ok, I guess I'll stay away from it for now then
[20:48] <radix> also, practically nobody uses it in production, as far as I've seen
[20:48] <radix> so that's probably enough evidence to stay away from it for serious projects :)
[21:17] <guilhembi> jam: I'm going through all issues I had noticed (scanning support issues 2412 and 2413), they are all gone with your custom bzr.
[21:17] <jam> guilhembi: good to hear
[21:17] <jam> Let's hope it gets landed :)
[21:20] <jam> spiv:  when you get a chance, I'm just poking at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080714010508.GG9654%40steerpike.home.puzzling.org%3E
[21:20] <jam> It is mostly approved, and just needs a couple more tests and merged.
[21:21] <jam> and lifeless, you semi-approved this on IRC the other day, but I submitted an update:
[21:21] <jam> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48B708ED.6020703%40arbash-meinel.com%3E
[21:21] <jam> Can you look it over and approve it?
[21:21] <jam> (you original voted resubmit, but then said approve-ish on IRC)
[23:44] <uws> bzr 1.6.1~rc1-1 is in debian unstable/experimental
[23:45] <uws> eh, sorry, wrong channel
[23:55] <igc> morning all
[23:55] <poolie> hello igc!
[23:55] <igc> hi poolie!
[23:56] <poolie> spiv, lifeless, jam, igc, abentley, call in 5m if you want
[23:57] <spiv> poolie: Just sent mail (to a valid address this time...), I'm sick today.
[23:58] <mwhudson> spiv, poolie, etc: are you bazaar guys coming to london for this launchpad thingy?
[23:58] <poolie> the jamboree in october?
[23:58] <poolie> i was thinking about whether it would be worth the travel
[23:58] <poolie> are you going?
[23:59] <mwhudson> i don't have a choice, i think :)