[00:00] <jfroy|work> thrope: sure, probably just use a file:// URL
[00:00] <thrope> got it with the svn+file
[00:04] <thrope> how can I push to a seperate branch with no shared histroy
[00:04] <thrope> I'm trying to push to an empty branch
[00:15] <meoblast001> hi
[00:15] <meoblast001> how do you delete a project in launchpad?
[00:30] <lamalex> meoblast001: you have to request it in launchpad answers
[00:30] <lamalex> there's no way to do it yourself
[00:31] <meoblast001> ok
[00:31] <meoblast001> thanx
[00:31] <lamalex> #launchpad would be the place to ask though
[00:31] <lamalex> ;)
[00:33] <Peng_> beuno: ping
[00:34] <jelmer> jfroy|work, thanks, just replied
[00:34] <jfroy|work> jelmer: and I sadly just spammed you with the same merge bundle...
[00:35] <jfroy|work> Apparently send -r respec doesn't mage a merge bundle for the specified revisions...
[00:35] <jfroy|work> I'm not sure how to send you a separate merge bundle for the foo fix, and another one with the test suite changes.
[00:36] <jelmer> jfroy|work, you probably have to recommit the changes on separate branches
[00:36] <jfroy|work> :sigh:
[00:42] <meoblast001> i always forget this specific bazaar command when i dont commit changes often
[00:42] <meoblast001> i think it's bzr -ci but im getting error
[00:42] <bob2> bzr ci
[00:42] <meoblast001> ah thanx
[00:43] <meoblast001> oops.. how do i register a folder as a branch.. havent done that in a long time
[00:44] <jelmer> meoblast001, bzr init
[00:56] <beuno> Peng_, pong
[00:56] <Peng_> beuno: Hi.
[00:56] <Peng_> Err, wait, I wanted to go watch TV in 3 minutes.
[00:57] <Peng_> beuno: Anyway, I wanted to poke you about the traceback Googlebot likes causing.
[00:59] <Peng_> beuno: Ignoring the part about how Googlebot found a bad link (and if it really should be a bad link), there's a second traceback that looks to me like a bug, but I dunno. http://paste.pocoo.org/show/91709/
[01:00] <Peng_> ...Bye.
[01:00] <beuno> Peng_, thanks, enjoy
[01:00] <Peng_> Thanks.
[01:05] <meoblast001> why am i getting Launchpad user 'braden' doesn't have a registered SSH key
[01:05] <meoblast001> it works on my other projects
[01:06] <meoblast001> this makes no sense
[01:07] <beuno> meoblast001, can you ssh into bazaar.launchpad.net?
[01:07] <meoblast001> ok
[01:07] <meoblast001> wait.. i think i figured it out
[01:07] <meoblast001> i forgot meoblast@
[01:07] <beuno> right
[01:07] <beuno> you can set that up in .ssh/config
[01:08] <beuno> set a rule for the bazaar.launchpad.net host
[01:08] <meoblast001> nah its ok
[01:09] <meoblast001> beuno: would you be interested in helping out with my day old project?
[01:09] <meoblast001> with many bugs
[01:09] <meoblast001> welll... 1 bug
[01:10] <beuno> uhm, I should probably try and keep up to date with my current projects before getting into new ones   ;)
[01:10] <Peng_> With bzr 1.9 you don't need the user in bzr+ssh://bazaar.launchpad.net/ URLs (and in previous versions, you can probably edit authentication.conf to set it up.)
[01:12] <poolie> spiv, hi, are you around?
[01:12] <spiv> I am.
[01:13] <thumper> abentley: I'm having problems with bzrtools with the nightly bzr ppa
[01:13] <thumper> abentley: 'module' object has no attribute 'diff_writer_registry'
[01:14] <poolie> are you busy today? i'd like to talk about the Ideal hpss stuff
[01:14] <abentley> thumper: it sounds like your bzr is too old.
[01:14] <thumper> abentley: it says 1.10 dev
[01:15] <thumper> poolie: I'd like to talk this afternoon about it
[01:15] <thumper> poolie: perhaps in an hour or so?
[01:15] <poolie> thumper, sure, together with the three of us, or pairwise?
[01:16] <thumper> poolie: sorry, I thought you were talking to me :)
[01:16] <spiv> I'd be happy to chat about ideal hpss stuff.
[01:17] <spiv> Although I'm starting to get hungry, so perhaps after lunch?
[01:18] <poolie> ok so the three of us in one hour at 2:00 utc
[01:18] <abentley> thumper: you need revno 3838
[01:18] <thumper> poolie: or 2:30 utc
[01:18] <thumper> abentley: how can I check the revno?
[01:18] <thumper> is the nightly ppa building?
[01:18] <thumper> I haven't seen an update for a few days
[01:19] <abentley> thumper: I see it when I do bzr --version
[01:19] <thumper> abentley: mine just says 1.10dev
[01:20] <spiv> thumper: if you installed from a PPA, I guess look at the version of the package, and/or maybe the changelog in /usr/share/doc/bzr
[01:20] <abentley> thumper: Sorry, I don't use a PPA.  It might be in the description or something.
[01:21] <thumper> abentley: package says 3837
[01:22] <abentley> Yeah, 3838 is from Nov 17
[01:23] <thumper> :(
[01:25] <thumper> abentley: how can I downgrade my bzrtools branch a few revisions?
[01:25] <thumper> abentley: as I use a bzrtools from trunk
[01:26] <abentley> thumper: bzr revert -r 681
[01:27] <thumper> abentley: that leaves me with modifications in the tree
[01:27] <thumper> abentley: then just plain revert?
[01:27] <abentley> thumper: no, if you want to unpull, do bzr pull -r 681 --overwrite .
[01:28]  * thumper tries that
[01:28] <thumper> abentley: dude, you are a walking bzr man page
[01:29] <thumper> abentley: notice I didn't ask "could it be done", I just assumed that it could and I didn't know how
[01:30] <abentley> hehe
[01:35] <jml> what's the complement of 'bzr revert --forget-merges'?
[01:35]  * jml remembers: "bzr revert ."
[01:35] <abentley> jml: right
[03:02] <Peng_> Heh, using "pull --overwrite" like that is a bit of an evil way to avoid "uncommit"s prompts and verbosity.
[03:10] <jam> markh: I wasn't, but I'm around a bit now
[03:12] <markh> hi jam - in bug 298013, the reporter notes "When adding new plugins to the standalone version of the installer many expect certain python modules to be available. Be they are not due to the fact that the standalone ships only a minimal python distribution"  Do you have any thoughts on that?
[03:12] <jam> markh: I believe xmloutput has that "solved"
[03:12] <jam> in that it packages the stdlib it expects to have available
[03:13] <jam> I'm not 100% sure on that, though
[03:13] <jam> I don't *think* we want to include a complete python install
[03:13] <jam> and it doesn't address plugins that go outside the stdlib anyway
[03:13] <jam> (bzr-gtk, for example)
[03:14] <markh> jam: you mean xmloutput nominates the set of the stdlib it includes rather than ones that are strictly needed by it?
[03:14] <jam> markh: no, that the packaging for xmloutput (as a separate installer from bzr-setup.exe) also includes the stdlib it needs
[03:16] <markh> I think the point of that report might be that if you try and add a plugin to the plugins directory in the win32 standalone binary installer, it is likely to fail as some module it uses, but we don't, isn't packages in py2exe
[03:17] <markh> I expect xmloutput finds itself in the same basic situation?
[03:18] <jam> markh: the original point of the bug report was for people that use a plugin by putting it in BZR_PLUGIN_PATH
[03:18] <jam> often  don't find it works
[03:18] <jam> because it doesn't have the necessary stdlib
[03:18] <jam> or even 3rd party
[03:19] <jam> xmloutput, IIRC, needed more of the XML parsing and generating libs
[03:19] <jam> from stdlib
[03:19] <jam> basically, it ends up that if you use the standalone installer
[03:19] <jam> you need to have "proper" installers for the plugins as well
[03:20] <jam> contrast that with when you install things into C:\Python25
[03:20] <jam> then it becomes much more straightforward that a plugin can run
[03:20] <jml> please come up with different ways to say branch(n) and branch(v). kthxbye
[03:20] <jam> and where you need to install any dependencies.
[03:20] <jam> jml: branch'n branch'v ?
[03:21] <markh> jam: I'm a little confused - that bug report doesn't make any reference to BZR_PLUGIN_PATH or xmloutput.  IIUC, our windows installer explicitly leaves plugins on the file-system rather than in the .zip so additional plugins can be plonked there.  Am I misunderstanding?
[03:21] <jml> jml branches a branch to make a new branch branched from the old branch.
[03:21] <jam> markh: they can also plunk them in APPDATA/bazaar/plugins, IIRC
[03:21] <jam> but the point is plonking them somewhere that gets auto-loaded
[03:22] <markh> correct - but if they fail due to some stdlib module not existing, how should they proceed?
[03:22] <jam> APPDATA/bazaar/plugins and $INSTALL/plugins are both on the default BZR_PLUGIN_PATH
[03:22] <jam> markh: if you use a standalone installer for bzr, you need an installer for your plugin
[03:22] <jam> I don't think we can do better than that
[03:22] <jam> We *could* package all of python
[03:22] <jam> we could even just bring in the python .msi file
[03:22] <markh> so what would we recommend that installer do?
[03:23] <jam> I wouldn't necessarily change the bzr installer
[03:23] <jam> aside from helping plugins build their own installers
[03:23] <jam> possibly just documenting how to do it
[03:23] <jam> as it seems that xmloutput "solved" the problem for plugins
[03:23] <markh> but if the "official" answer is "you can't use a plugin on windows unless it ships with bzr, or the author has made a special installer for it", I'll be happy to spread that word.
[03:24] <jam> markh: well, what are our alternatives?
[03:24] <jam> I would rather see a python-based installer, but it is hard to make that slick
[03:24] <markh> I'm still not clear how that plugin installer would install a missing stdlib module - I guess they could ship it - but many plugins shipping copies might be somewhat strange.
[03:25] <jam> and not necessarily better than documenting how plugins can install the stdlib they need
[03:25] <markh> jam: an easy alternative may be to nominate parts of the stdlib we include - possibly even all of it.  What is your concern there?
[03:25] <markh> size?
[03:25] <markh> obviously we sould avoid the subdirs that don't make sense
[03:26] <jam> well, "du -ksh" seems to say that stdlib is approx 22MB
[03:27] <jam> but that includes .py, pyc, and .pyo
[03:27] <jam> It also says my site-packages is 97MB
[03:28] <jam> interesting, bzrlib is 2x the size of PyQt4, but I bet it compresses a lot better
[03:28] <jam> :)
[03:30] <markh> its a cost-benefit tradeoff - istm the benefit of having more plugins work is greater than the cost of including the stdlib - especially given the number of plugin authors who would create a special installer will be approx. zero.
[03:30] <jam> however, the installer is already getting enormous (14MB so far?) what's another 5MB or so
[03:31] <markh> just before you disconnected I said:
[03:31] <markh> its a cost-benefit tradeoff - istm the benefit of having more plugins work is greater than the cost of including the stdlib - especially given the number of plugin authors who would create a special installer will be approx. zero.
[03:31] <markh> and yeah, for 5mb, that cost isn't high at all
[03:31] <jam> (I'd rather see a 5MB installer *total*, but that seems to not be possible.)
[03:32] <markh> yeah, long term there are a few nice things we could do
[07:01] <vila> hi all
[07:04] <igc> hi vila - sorry to hear about your lousy trip home
[07:04] <vila> Hi Ian !
[07:05] <vila> Bah, don't worry that much, it makes for some nice memories and I learned a few lessons :-)
[07:06] <eferraiuolo> I'm looking to understand something about checkouts compared with svn
[07:06] <eferraiuolo> in SVN you can do a checkout of a sub-directory
[07:06] <eferraiuolo> in bzr is seems you can only checkout a branch
[07:06] <eferraiuolo> but what if I just wanted to checkout a sub-folder in a branch?
[07:07] <eferraiuolo> for ex. in my local repo --no-trees I have a /trunk/ branch with two folders /trunk/foo and /trunk/bar
[07:08] <eferraiuolo> I want to bzr co /trunk/foo .
[07:08] <RAOF> eferraiuolo: You can't really right now.  Or at least, last time I checked; this _may_ have changed with bzr 1.9.
[07:09] <Peng_> It may have changed in 1.9?
[07:09] <eferraiuolo> RAOF: anyone using some combination of branching?
[07:09] <eferraiuolo> ...I'm using 1.9 and can't seem to get this work
[07:09] <RAOF> Peng_: I know there's _some_ work on support for subtrees like this, and I haven't followed 1.9 dev...
[07:10] <Peng_> I don't think anything new happened.
[07:11] <RAOF> eferraiuolo: There's the 'bzr split' command, which goes about half way to what I guess you want.
[07:12] <RAOF> That takes a subtree of a branch and converts it to a separate branch.
[07:13] <eferraiuolo> so I would first have to create a new branch outside my shared no-trees repo to run the split cmd on
[07:13] <RAOF> Oh, tell a lie.  As long as you don't mind hitting buttons marked "experimental", a combination of bzr split and bzr join --reference looks like it'll do what you want.
[07:15] <RAOF> You split out trunk/foo and trunk/bar into two separate branches, then join foo & bar into trunk; if the documentation doesn't lie, you'll have a trunk/ with sub-branches foo and bar, and commits on trunk will recurse into foo & bar.
[07:15] <eferraiuolo> hmmm... interesting. I'll give it a try
[07:16] <RAOF> I suspect you'll need to upgrade your branch to the latest-greatest-experimental subtree variant first.
[07:17] <eferraiuolo> it's on --1.9-rich-root already, which seems it should work
[07:18] <eferraiuolo> Looks like I will have to branch my trunk outside my repo since my repo is set to no-trees
[07:18] <RAOF> If it doesn't work first time, I'd guess you'll need to upgrade to whatever the relevant -subtree variant is.  rich-root gets you the ability to 'bzr split'; I think you need -subtree to 'bzr join', though.
[07:19] <Peng_> eferraiuolo: If a branch doesn't have a working tree, you just need to use "bzr co" to create it..
[07:38] <eferraiuolo> It's odd... bzr split is create the sub-branch, but I can't checkout or branch against the newly created sub-branch, it pulls down the whole parent branch (trunk)
[08:08] <hmeland> eferraiuolo: I think it's by design that the sub-branch produced by the split command will include the entire history of the parent branch.
[08:13] <vila> I have a repo with empty inventory sha1s 8-/ Thoughts ?
[08:14] <hmeland> eferraiuolo: That way, if someone commits new stuff to a pre-split version of the parent branch, you stand a reasonable chance of having "bzr merge" just do the right thing.
[08:15]  * hmeland . o O ( Oops, that doesn't sound good. )
[08:21] <eferraiuolo> So I ended up just splitting my repo for that project into to main, but separate branches and dealt with the issue that way.
[08:21] <eferraiuolo> thanks all for the help and insights
[08:21] <igc> poolie: did you want ~mbp/bzr-usertest/277376-strict reviewed & merged?
[08:21] <igc> poolie: it looks ok to me at first glance
[10:54] <Peng_> Oh my god! "bzr check" finally finished!
[10:54] <Peng_> Nothing was wrong. :
[10:54] <Peng_> \
[11:12] <jelmer> you sound disappointed
[11:20] <Peng_> jelmer: Well, it was an anticlimactic ending.
[11:34] <EarthLion> hey how can i ignore specific files. I have added .DS_Store to my .bzrignore file and that shows up under bzr ignored but the other lines e.g. database.php don't get picked up
[11:39] <Peng_> Maybe database.php is already versioned?
[11:43] <EarthLion> yeah it is already versioned
[11:43] <EarthLion> so i have to remove it first?
[11:44] <Peng_> Yes.
[11:44] <Peng_> Ignore rules don't apply to things that are already versioned.
[11:45] <Peng_> You could "bzr rm --keep database.php" to stop versioning it without physically removing the file. (commit too, of course)
[11:59] <EarthLion> Peng: thanks :)
[12:13] <awilkins> jelmer: Who's building the python-flavoured 1.9 windows installers, because it doesn't have the C extensions for bzr-svn  ?
[12:13] <jelmer> awilkins, jam or markh I think
[12:13] <jelmer> or maybe Alexander
[12:14] <awilkins> Hmmph, maybe LP should list who uploaded a given file :-)
[12:25] <arnarl> Is there any way to do something like svn:externals with bazaar? and point to a web address or a subversion repository something similar?
[12:26] <arnarl> googling didn't yield anything obvious and there were a few references to "when the stacked branches" lands
[12:27] <Peng_> That's not what stacked branches are for.
[12:27] <arnarl> there is ConfigManager, but it seems a bit abandoned with no checkins since march 2006
[12:27] <arnarl> ok, then I have searched for the wrong thing :-)
[12:27] <Peng_> That's what, uhh, by-reference subtrees (or by-reference nested trees? I forget the terminology) are for, and they've been in an experimental state for ages.
[12:28] <arnarl> not sure I follow
[12:29] <Peng_> There's work on stuff similar to svn:externals, but I don't think there's been any progress for ages.
[12:29] <arnarl> anyway, what I would like is a way to point to a file in subversion so that it is updated when a user branches or that I can automatically keep it up to date in my own branch.
[12:38] <jelmer> only 2 more failing tests away from bzr-svn 0.5rc1 \o/
[12:41] <Peng_> Congrats :)
[12:44] <awilkins> \o/ \o/ \o/
[12:50] <awilkins> jelmer: Does 0.5 still carry the "eek, metadata may change" warning (esp for branches managed on 0.4 series) ?
[12:52] <jelmer> awilkins_food: yaeh, it does at the moment (though it's pretty stable)
[12:53] <awilkins_food> jelmer: The "pretty stable" part is the best ; I'm more interested in the actual risks rather than the warning message per se  :-)
[12:54] <awilkins_food> jelmer: So can it operate on branches with 0.4 bzr:properties?
[13:02] <jelmer> awilkins_food: still there?
[13:02] <jelmer> awilkins_food: it will fetch 0.4 branch correctly
[13:03] <jelmer> awilkins_food: I would recommend using the v3 (0.4) mappings for now though
[13:03] <jelmer> awilkins_food: by settings the default mapping to 'v3' in mapping.py
[13:09] <awilkins_food> jelmer: Using the v4 mappings presumably is the secrete sauce that makes it work better with truly horrible repository histories and layouts though?
[13:10] <jelmer> awilkins_food: yep
[13:10] <jelmer> awilkins_food: and which allows not using file properties when roundtripping
[13:11] <awilkins> jelmer: I think I'll build it up and try it on my "monster repo" here -this one always kills 0.4 just before it finishes branching trunk
[13:12] <awilkins> KeyError
[13:12] <jelmer> oh, that should never happen, not even with 0.4..
[13:12] <jelmer> is there a bug open about that?
[13:12] <awilkins> yes
[13:12] <awilkins> I've mailed you stack traces in the past
[13:13] <awilkins> Specifically for this one ; opening the repo would not be practical alas, it's about 1.5GB as SVN FSFS I think
[13:18] <awilkins> jelmer: I'm not certain there is a bug for it ; stack trace is in a mail dated 6th September
[13:20] <jelmer> awilkins, any chance you can forward it to me again?
[13:21] <awilkins> Sure, no problem.
[13:24] <awilkins> I'm going to built the tip of 0.4 and try it out on the branch that throws it ; but not necessarily a good test, because the branch might be in a bad state which is causing the error (it has most of the revisions pulled into it by now).
[13:26] <awilkins> For a rigorous test I'll have to pull the branch from scratch I suppose ; but that isn't fast, it takes at least 10 hours. I'll have to dump the repo and unload it at home because the IT drones have imposed a "drop into standby" policy on all desktop machines here unless you push the right button at 1900
[13:26] <awilkins> So I can't leave it going overnight
[13:26] <awilkins> Because I leave at 1700 :-)
[13:27] <jelmer> re
[13:27] <jelmer> it should be a lot faster these days, maybe that helps..
[13:27] <jelmer> how many revisions is it?
[13:28] <awilkins> Around 10,000 revisions and 1.5GB
[13:28] <awilkins> Of revisions
[13:28] <awilkins> Medium to large binary files, enormous number of paths
[13:30] <awilkins> And horrible branch layout ; I tried pulling a branch that should have been a v.small revision size but it turned out to generate a rather large revision (I stopped it before it finished as it was clearly not right)
[13:31] <awilkins> Hence enthusiasm for 0.5
[13:31] <awilkins> The prospect of this repo actually switching to bzr is slim but it would be nice to have options :-)
[13:32] <awilkins> And I like to use it for the other, more reasonably sized, repos that I access. Being able to cope with a horrible monster improves my confidence :-)
[13:32] <jelmer> :-)
[13:32] <awilkins> This repo has upward of 42,000 paths
[13:32] <awilkins> Would split inventories improve it's performance characteristics?
[13:36] <jelmer> awilkins: yeah, that would certainly help I think
[13:36] <jelmer> awilkins: 10k revisions isn't that much for bzr-svn anymore these days
[13:36] <jelmer> especially for local repositories
[13:37] <awilkins> Is split-inventory in --1.9 ?
[13:37]  * awilkins reads release notes
[13:37] <jelmer> awilkins: no, not yet
[14:03] <jelmer> awilkins: with which version of bzr-svn did that KeyError last occur?
[14:08] <awilkins> jelmer: The version in the log is the last version I tried it with
[14:10] <awilkins> jelmer: I'm packing up that repo so I can take it home and test it there.
[14:10] <awilkins> jelmer: I still have the partialluy-pulled branch lying around, do you think a newer version may fix it?
[14:12] <jelmer> awilkins: I would rather just try a new pull
[14:13] <jelmer> awilkins: It may well be significantly faster than two months ago..
[14:13] <awilkins> I'm going to try a new pull tomorrow (via the ra-local layer rather than http or svn)
[14:13] <awilkins> I could try it here as well.
[14:14] <awilkins> I'll try both - a pull on top of that partial pull, and then a new one (I'll trash the branch, and the svn metadata cache first)
[14:16] <balor> Given a diff generated by "bzr diff".  How can I apply that diff to a source tree?
[14:16] <awilkins> balor: gnu patch ?
[14:17] <balor> awilkins: bzr diff is in a different format AFAIK
[14:17] <luks> no, it isn't
[14:17] <balor> ah, ok
[14:17] <awilkins> AFAIK it's udiff
[14:17] <awilkins> If it's a bundle, it's easier to use "pull" or "merge"
[14:18] <awilkins> As long as your target is a bzr branch ( I presume it is not)
[14:18] <balor> awilkins: My target is a bzr branch
[14:18] <luks> why not use bzr send then?
[14:19] <awilkins> Yes, use send or bundle
[14:20] <balor> luks: I should have used bundle.  But I can make do with the diff.  Thanks.
[14:21] <luks> don't use bundle, it's a hidde command not meant to be used anymore
[14:21] <luks> hidden
[14:22] <awilkins> My bad advice ; I hadn't noticed it was hidden
[14:25] <balor> luks: So diff is my only option on a Windows machine with no network connection?
[14:26] <LarstiQ> balor: no, bzr send -o thing.patch
[14:27] <LarstiQ> balor: well, I assume you can get the patch of the machine, if not typing over the diff is probably the least work :)
[14:27] <balor> LarstiQ: thanks
[14:30] <awilkins> jelmer: Upgrading to tip of 0.4 has 2 obvious effects i) It seems to be working, it pulled that revision it got stuck on previously ii) The "determining changes" stage was a lot faster
[14:32] <awilkins> I'll try it fresh and see how it does when it catches up with the tip
[14:32] <awilkins> Does it still repack every revision?
[14:33] <jelmer> no, only every 500
[14:37] <Peng_> Is it just me, or does the "determining changes" step often run twice, the second time much slower than the first?
[14:37] <Peng_> Why is that?
[14:38]  * LarstiQ on occassion sees it running much more than two times
[14:38] <LarstiQ> Peng_: I assumed it was per-file
[14:38] <Peng_> Oh?
[14:39] <awilkins> Meh, I can't use "1.9-rich-root" as a format
[14:40] <Peng_> What? Why not?
[14:40] <awilkins> Ah, that's better
[14:40] <awilkins> I think it may be a "quirk" of my shell
[14:40] <Peng_> Oh.
[14:40] <awilkins> It wasn't taking the parameter
[14:42] <jam> morning vila, how was your night?
[14:43] <vila> jam: hi ! Pretty good, woke up at 5h30 only :)
[14:43] <vila> otherwise, slept like a baby :)
[14:46] <jam> well, my son woke up at... 2130, 0030, 0130, 0530
[14:46] <jam> so I hope you slept better than that :)
[14:46] <jam> but I guess you got up together :)
[14:46] <jam> (and no, that isn't actually UTC)
[14:46] <jam> vila: have you had a chance to look at the merge issue?
[14:47] <vila> jam: ouch, poor daddy :-/
[14:47] <vila> jam: yes, ready to chat about that and also about empty inventory sha1s...
[14:48] <vila> and running the test suite under a solaris VM with my third hand :)
[14:51] <jelmer> 'morning Vincent, John
[14:52] <jelmer> LarstiQ, Peng_: "determining changes" runs once to find the branch history and then once per tag
[14:58] <Peng_> jelmer: Oh, okay.
[15:02] <LarstiQ> jelmer: what tag, svn tags and branches?
[15:02] <LarstiQ> moin vila, jam
[15:02] <jelmer> LarstiQ: yeah
[15:02] <vila> hi LarstiQ !
[15:04] <LarstiQ> jelmer: right, that could explain it. We have more of those than I'm fond of :)
[15:49] <jelmer> ok, with bzr-svn 0.5 importing vala (2319 revisions) over the svn:// protocol takes 258 seconds now
[15:50] <LarstiQ> doesn't seem to bad to me?
[15:51] <jelmer> yeah, that's pretty good
[16:03] <uws> Heya
[16:03] <uws> I'm getting errors when committing to launchpad
[16:03] <uws> bzr: ERROR: Repository KnitRepository('bzr+ssh://uws@bazaar.launchpad.net/%7Euws/winwrangler/winwrangler.uws/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/uws/Computing/Projects/winwrangler.uws/.bzr/repository/')
[16:03] <uws> ...
[16:04] <LarstiQ> uws: rich-root vs non rich-root?
[16:04] <uws> guess so
[16:04] <uws> how do I fix it?
[16:05] <jelmer> uws: upgrade repository that is not yet rich-root to rich-root(-pack)
[16:05] <uws> jelmer: how? I tried
[16:05] <uws> bzr upgrade lp:~uws/winwrangler/winwrangler.uws/   doesn't work
[16:05] <uws> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[16:06] <uws> same for  bzr upgrade --rich-root-pack lp:~uws/winwrangler/winwrangler.uws/  btw
[16:07] <LarstiQ> uws: unfortunately, try sftp:// instead of lp:
[16:10] <uws> LarstiQ: ok, seems to do something
[16:19] <uws> LarstiQ: thanks, worked
[16:32] <awilkins> jelmer: 0.4 isn't exactly slouching
[16:32] <awilkins> It's done 6000 fairly hefty revisions in a couple of hours so far
[16:33] <awilkins> Pretty much CPU limited, I'm sure using the SVN protocol as opposed to HTTP wouldn't help much
[16:35] <jelmer> 0.5 should be better in that regard
[16:35]  * jelmer starts a KDE import
[16:35] <awilkins> I'll be trying it later, barring any nasty surprises trying to build it on win32
[16:35] <awilkins> I'll be interested to see if it passes the "branching a tag should produce a tiny increase in pack size, not 100MB" test
[16:38] <jelmer> awilkins: ? was there anything that didn't pass that test then?
[16:38] <awilkins> jelmer: This repo has a somewhat horrible branch layout and some moves as well
[16:39] <awilkins> jelmer: I tried it with an older version and branching a tag that the repository should already have had the parent revision for made a rather large new pack.
[16:39] <awilkins> A few hundred K for the inventory, yes, over 100MB, no.
[16:40] <jelmer> in that case, it would just end up using a different branching scheme and copying most of the history again
[16:40] <awilkins> I messed about with the branching config a bit but never really got a satisfactory result (again, this repo is horrible)
[16:40] <awilkins> Since 0.5 does not use the same mechanic, I shall see how it works :-)
[16:41] <Kobaz> allrightey... so i'm moving from svn
[16:41] <Kobaz> is there a way to have a svn-esque authentication system on a central bzr server
[16:42] <Kobaz> ie: bob has hsi own password, joe has his own password
[16:42] <Kobaz> rather than a shared ssh account where everyone pushes to
[16:42] <awilkins> Kobaz: You can use HTTP methods of auth if you use the HTTP server
[16:43] <awilkins> Kobaz: Whatever IIS and Apache support at a minimum
[16:43] <Kobaz> ah
[16:43] <Kobaz> it would be apache.. okay, that makes sense
[16:43] <awilkins> Kobaz: No path-based auth like SVN but it's rather silly in a DVCS because everyone can commit to the whole tree if they can commit at all
[16:44] <awilkins> Kobaz: You could probably arrange matters so that distinct ssh accounts could all push to the same repo - after all, Launchpad does this
[16:45] <awilkins> Bazaar itself has no authentication but the transports it uses may do, is the quick answer
[16:46] <Kobaz> k
[16:48] <awilkins> I'd like to see it do client-certificate auth over http, but I can't grok how to get curl to do it.
[16:52] <dobey> Kobaz: the ssh is just a method. you don't have to have a shared account
[17:00] <LarstiQ> Kobaz: in fact, at work we use multiple shared repositories over bzr+ssh, with everyone using their own account.
[17:00] <LarstiQ> Kobaz: and acl (setafcl \o/) to control who has access to which branch.
[17:01] <LarstiQ> Kobaz: (which boils down to: everybody, but it could be more complex :)
[17:02]  * LarstiQ hops off to jitsu
[17:09] <Kobaz> nifty
[17:34] <emmajane> In CVS I can run a diff against the last update... cvs diff -up original.php > filename.patch in bzr I would have to check my revision numbers first to see what "original" was? I read bzr --help diff, but I didn't see a syntax that matched what I use in CVS.
[17:34] <beuno> emmajane, bzr diff -r -2
[17:35] <emmajane> that's "two revisions ago"?
[17:35] <beuno> I don't quite know the rationale for -2 instead of -1
[17:35] <beuno> actually
[17:36] <beuno> I think it's, "show me the difference between the end of 2 revisions ago and now
[17:37] <emmajane> Let's say, for example, I was working on a branch and when I downloaded it was at revision 159... and now I'm at revision 178... I want to send a patch back because politics are weird... james_w suggested bzr send as well.
[17:37] <emmajane> (and the branch is 500M because of images so pushing will not be fun)
[17:38] <james_w> "bzr send --mail-to person@place.com"
[17:38] <beuno> bzr send is *the* tool to send a patch for the differences between branches, yes
[17:38] <james_w> another is "bzr diff -r ancestor:http://server/path/to/branch"
[17:38] <emmajane> james_w, and it's just the diff that gets sent?
[17:39] <james_w> no, it sends the diff + bzr meta-data.
[17:39] <emmajane> james_w, what does bzr diff spit out? is it like the patch file that cvs diff gives?
[17:39] <beuno> emmajane, diff + bzr metadata (commit information)
[17:39]  * emmajane nods
[17:39]  * beuno waves at james_w 
[17:39] <james_w> you can "bzr merge" from the file that "bzr send" produces, much like if you pushed this to a branch
[17:39] <james_w> hey beuno, how are you?
[17:40] <emmajane> that popping noise? that was my brain exploding... just a second. :)
[17:40] <emmajane> ok. I'm back.
[17:40] <beuno> james_w, pretty good, how are you?
[17:40] <james_w> beuno: good thanks.
[17:40] <beuno> emmajane, bzr send generates a file which is the diff plus bzr data, so you can "merge" in the file with all its commits
[17:41] <emmajane> *nod*
[17:42] <beuno> so it's different than a plain diff, because you can send them around, and you'll get branches with the same revisions in them (sort of, but let's say yes)
[17:42] <beuno> james_w, will I see you at UDS?
[17:42] <james_w> beuno: of course :-)
[17:42] <emmajane> it's a diff on bzr steroids. :)
[17:42] <beuno> james_w, fantastic, looking forward to it. I want to talk to you about package branches over beer!
[17:42] <beuno> emmajane, you got it!
[17:42] <emmajane> gotcha.
[17:43] <james_w> beuno: of course :-)
[17:45] <emmajane> How are the email addresses configured?
[17:45] <emmajane> i.e. if the mailing list is subscriber posting only...
[17:45] <emmajane> do I have to change my whoami?
[17:45] <beuno> well, that's kinda out of bzr's realm
[17:45] <emmajane> i.e. what email address is announced when you use send?
[17:46] <beuno> so, you can send it to any email address
[17:46] <beuno> the whoami is used for the "from" IIRC
[17:46] <emmajane> heh. so I can fake someone's email? :)
[17:47] <beuno> well, you know how email works...
[17:48] <emmajane> :)
[18:00] <fullermd> I always just have send output to a file, then write the email and attach it manually.
[18:01] <fullermd> The work isn't ever where the mail client is anyway.
[18:02] <beuno> me too
[18:03] <emmajane> fullermd, as in bzr send > file_to_send_later.txt ?
[18:03] <vila> fullermd: It really depends on your mail client and your workflow, I generally prefer to have send spawns my mail client with the patch already attached, a subject roughly correct and To already set
[18:03] <emmajane> vila, that sounds clever... will it work with thunderbird?
[18:03] <vila> But I also had workflows where *sending* the mail directly was even better suited
[18:04] <vila> emmajane: I'm pretty sure yes, you have to find the the right mail_client setting in bazaar.conf
[18:04] <emmajane> ahh, ok.
[18:05] <vila> bzr help send
[18:05] <vila> mentions thunderbird :)
[18:05] <fullermd> Well, when my branch is on this machine here, and my mail client is on that machine there, it's out of the question anyway   ;)
[18:05] <emmajane>   Mail is sent using your preferred mail program.  This should be transparent
[18:05] <emmajane>   on Windows (it uses MAPI).  On Linux, it requires the xdg-email utility.
[18:06] <vila> fullermd: bah, my branch is always there or one  mounted file system away :-)
[18:07] <beuno> vila, you use emacs, it's a different universe all together  ;)
[18:07]  * vila discovered the joy of auto_master recently when configuring a new OS X.5 laptop :)
[18:07] <vila> beuno: hehe, true, but not relevant here :)
[18:07] <beuno> whenever I see "email" and you in the same phrase, it becomes relevant!
[18:08] <vila> lol
[18:08] <emmajane> hmmm.
[18:08] <beuno> you're the only person I know who uses non-standard way of replying to emails
[18:08] <beuno> which I blame on emacs, of course
[18:08] <emmajane> apt-cache search xdg-email
[18:08] <emmajane> xdg-utils - desktop integration utilities from freedesktop.org
[18:09]  * emmajane contemplates wondering if the documentation should say that or if it's just an Ubuntu thing...
[18:09] <vila> beuno: what do you mean by non-standard ?
[18:09] <vila> citations ?
[18:09] <beuno> vila, yes
[18:09] <beuno> emmajane, is there anything else?  :)
[18:10] <emmajane> beuno, well...
[18:10] <emmajane> beuno, I don't thinks so....
[18:10] <vila> well, the supercite engine is... older than me I guess, so I'd be surprised to be the only one using it...
[18:10] <emmajane> beuno, I had a friend tell me about this "VSD" thing once? Or was it BSD? ;)
[18:11] <beuno> emmajane, they do all kinds of odd experiments with operating systems
[18:11] <emmajane> beuno, crazy! :)
[18:11] <beuno> emmajane, so, FWIW, the documentation is in the bzr tree  ;)
[18:11] <emmajane> yeah, yeah.... ;)
[18:12] <beuno> not that I'm implying anything, of course...
[18:12] <emmajane> nono, of course you're not.
[18:12] <emmajane> but this is me resisting the urge to screen cast instead of eating before a meeting.
[18:12] <vila> beuno, emmajane : You should try opensolaris (just to be reminded on the huge work made by distros....)
[18:13] <emmajane> vila, I read about solaris in the documentation for GNOME accessibility.
[18:13] <emmajane> vila, I can't remember if it was all things they COULD do, or could NOT do. :)
[18:14] <vila> opensolaris: 1465 packages and counting !!! All prefixed nu SUNW to make them easier for you to understand what they contain ! SUNWman : the man pages ! ulimit.1 contains sorry guy, we didn't provide the man page in that release, try again later :-(
[18:15]  * emmajane chuckles.
[18:16] <fullermd> It's a pathetic attempt to regain the heights Solaris once held, when they installed a compiler that told you they wouldn't give you a compiler without more $$$$.
[18:16] <vila> I mean, I respect Solaris (a bit less than SunOS, but that's not the point), after all, that was the first house for most of the GNU utilities
[18:16] <vila> fullermd: full agreement
[18:17] <vila> But bashing aside, opensolaris 08.11 is better than os08.05, at least there *is* a package manager now
[18:17] <emmajane> heh
[18:18] <vila> fullermd: and the day they stop providing the compiler is the one I consider the worst day in Sun history
[18:18] <vila> they obviously didn't realize how they shot themselves in both feet
[18:19]  * emmajane quietly tiptoes out for lunch while y'all discuss Solaris compilers. :)
[18:19] <vila> emmajane: enjoy your lunch :)
[18:19] <emmajane> vila,  thanks :)
[19:10] <verterok> hi!
[19:19] <sinelaw> does bzr have default ignore rules?
[19:20] <sinelaw> and where can i see them
[19:20] <beuno> sinelaw, yes, pyc files and other common generally unwanted ones
[19:20] <sinelaw> where can i see the full list
[19:20] <beuno> that's a good questions
[19:20] <sinelaw> bzr ignore has only "--old-default-rules"
[19:20] <sinelaw> ah
[19:21] <luks> any launchpad people here? can you please check why is https://code.launchpad.net/~luks/bzr-pager/pager "Disabled"?
[19:21] <sven_> hi! bzr log crashed for me when selecting a specific revision in mysql 6.0, using --forward : http://pastebin.com/m7b7b1659
[19:22] <sinelaw> nope,
[19:22] <fullermd> You can see them in the ignore file bzr creates if it doesn't already exist.
[19:22] <sven_> is this a known bug? it doesn't crash for arbitrary revisions, so i don't know how to reproduce it with a smaller tree
[19:23] <beuno> luks, mwhudson would know
[19:23] <sven_> would be very good to know if this is a bug in bzr's algorithm or something corrupt in mysql's revision history
[19:23] <beuno> but I'm not sure if he's around yet
[19:23] <beuno> if not, open up a question in answers.launchpad.net/launchpad
[19:24] <sinelaw> fullermd, there bzrignore file doens't list the built-in ignores
[19:24] <mwhudson> luks: "a bug"
[19:24] <sinelaw> there doesn't seem to be a bzr command for viewing them
[19:24] <luks> thanks, at long as it's not an error on my side, I'm fine :)
[19:24] <luks> or can I do something to enable it?
[19:25] <fullermd> sinelaw: ~/.bazaar/ignore
[19:25] <sinelaw> fullermd, thanks. that should be documented in the bzr command somewhere though :)
[19:25] <mwhudson> luks: specifically https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/297448
[19:26] <mwhudson> luks: i'd recommend deleting it, reregistering it, waiting until it's mirrored once, then making it the dev focus
[19:26] <luks> mwhudson: thanks, will do
[19:26] <mwhudson> np
[19:30] <beuno> Peng, any ideas on how google got to the URL http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/files/1185.1.29?file_id=http-20060113083522-fa806bfc2aca663c
[19:30] <beuno> ?
[19:48] <mathrick> hi, what gives? http://pastebin.com/m64d5e87d
[19:48] <mathrick> I thought that's was the point of mv --after
[19:48] <luks> event.list is removed
[19:48] <luks> er
[19:48] <vila> sven_: sounds more like a bug in index manipulation than in revision history to me
[19:49] <vila> sven_: can you retry the command without --forward (that will  clearly draw the line)
[19:49] <sven_> vila, ok, good to know. i reported https://bugs.launchpad.net/bzr/+bug/300055
[19:49] <mathrick> luks: no, I moved it
[19:49] <mathrick> I just didn't use bzr mv
[19:49] <sven_> vila, without --forward i don't see any crash
[19:49] <luks> I *think* it would work if src/event.lisp wasn't "bzr add"ed
[19:49] <mathrick> luks: it complained about that before, too, that's why I added it
[19:49] <sven_> vila, also, without the file argument, i don't see any crash
[19:49] <mathrick> but lemme try
[19:50] <vila> sven_: ok, shouldn't be hard to fix then, I'll look into it tomorrow
[19:50] <sven_> vila, thanks!
[19:50] <mathrick> luks: nope, no cigar
[19:52] <luks> mathrick: are the files also changed or only renamed?
[19:53] <mathrick> luks: at least event.lisp is changed because of a merge
[19:53] <mathrick> hmm
[19:53] <luks> well, if it's not manually edited I'd suggest to revert and start over
[19:54] <luks> and if it is, backup the files, revert, move, put the backups back in place
[19:54] <hydrapheetz> :3
[19:54] <hydrapheetz> oops
[19:54]  * hydrapheetz shouldn't switch channels at high speeds D:
[20:01] <mathrick> luks: http://pastebin.com/m29a5bf0d <-- huh?
[20:01] <mathrick> I don't get it
[20:02] <mathrick> I reverted that, and now it says that event.lisp is both removed and unknown
[20:03] <luks> mathrick: that is after running "bzr revert"?
[20:04] <luks> no extra arguments?
[20:04] <luks> it can't be, because "src/" is still added
[20:04] <mathrick> luks: with arguments
[20:04] <mathrick> I moved it back from src/ to ./
[20:05] <mathrick> I reverted event.lisp, and now it's all confused again, albeit differently
[20:06] <luks> well, I can't help other than to suggest to do "bzr revert" (not selectively, but the whole tree) do the renames and put the original files back
[20:06] <mathrick> ooh, because I did bzr pull instead of merge
[20:07] <mathrick> I get it now
[20:26] <abentley> poolie: ping
[20:29] <mib_aevfas> how do I publish a branch to an FTP server that requires identification (user: foo, pass: bar)?
[20:29] <beuno> mib_aevfas, bzr push ftp://user@host:/path/to/repo
[20:29] <beuno> and bzr will ask you for a pass
[20:42] <mib_aevfas> beuno: thanks!
[20:42] <beuno> mib_aevfas, you're very welcome
[21:31] <philsf> I'm having a little trouble with bzr: 'No handlers could be found for logger "bzr"'
[21:31] <beuno> philsf, are you running 1.9 and bzrtools?
[21:31] <philsf> From what I gather, this is a fixed bug, so I must have done something wrong that left a lock file. How can I debug this?
[21:32] <philsf> bzr 1.3.1-1ubuntu0, from ubuntu 8.04
[21:32] <beuno> philsf, can you pastebin the output of "bzr plugins"?
[21:32] <beuno> also
[21:32] <beuno> take a peak in ~/.bzr.log
[21:33] <philsf> this is a local-only branch. I usually develop in the laptop, and rsync the full dir to my desktop. I only see the warning in the desktop. Is the rsync of the full dir the probable cause?
[21:34] <philsf> http://paste.ubuntu.com/74493/
[21:34] <beuno> that seems like a problem with bzr, not the branch
[21:34] <philsf> http://paste.ubuntu.com/74495/
[21:35] <philsf> beuno: that's what I thought, since the warning appears in whatever dir I call bzr from
[21:35] <beuno> philsf, is .bzr.log writable by you?
[21:36] <philsf> well, no... it has root ownership, dunno why
[21:36] <beuno> that's probably it
[21:37] <beuno> change the permissions, the error should go away
[21:37] <philsf> cool, it was!
[21:37] <beuno> :)
[21:37] <philsf> thanks, beuno!
[21:37] <beuno> philsf, you're welcome
[21:37] <philsf> beuno++
[21:38] <beuno> w00t!  I've been increased!
[21:38] <w00t> huh?
[21:38] <w00t> ack
[21:38] <beuno> ah
[21:38] <beuno> uhm
[21:38] <fullermd> Great, now there's two of them.
[21:39] <beuno> what are the chances someone would have "w00t" as their nick...
[21:39] <w00t> beuno: if i'm around - fairly high! i've been using it for the past ~10 years now :) </offtopic>
[21:40]  * jdong wonders if stdin has even more problems with his nick :)
[21:42] <beuno> good, now I have autocomplete for w00t
[21:42] <beuno> we should get more people with words in their nicks in here
[21:42] <beuno> just having "revision", "branch" and "push" would save a lot of typing
[21:48] <LarstiQ> beuno: you do know irssi can do completion from dictionaries? :)
[21:48] <beuno> LarstiQ, really????
[21:48]  * beuno googles
[21:49] <fullermd> And if we got people choosing dirstate-tags and pack-0.92 and rich-root and rich-root-pack and 1.6 and 1.6.1-rich-root, we could have some good arguments about whether some of them should be kicked off the channel!
[21:50] <poolie> abentley: pong
[21:51] <abentley> poolie: I've done some work on your branch, to try getting pack to heal these repo-spanning-deltas.
[21:52] <poolie> oh thanks
[21:52] <poolie> as i said in the bug, i found out yesterday evening it doesn't handle all cases in fetch
[21:52] <abentley> poolie: Mainly what I've got so far is a failing test.
[21:53] <poolie> so unless something more important comes up in our standup, i was going to keep working on that today
[21:53] <poolie> ah :) that's still useful
[21:53] <abentley> poolie: I'll push the work-in-progress, and you can keep going on it.
[21:56] <abentley> poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas
[21:57] <abentley> poolie: As you can see, I was going to try inserting missing records.  But I'm thinking fulltexts is probably saner.
[21:59] <abentley> poolie: Inserting the records could mean making an Inventory referenceable without making the corresponding files referenceable.  Which violates our longstanding policy.
[22:05] <jam> poolie: call?
[22:28] <Kobaz> what's the recommended method for setting up a series of central bzr repos
[22:28] <Kobaz> i've been trying to get the webdav stuff going without success
[22:29] <Kobaz> i tried the mod_python method too
[22:29] <Kobaz> that doesn't work either
[22:30] <Kobaz> or should i just run bzrserv and shove all the projects in one repo
[22:30] <awilkins> Kobaz: I've suceeded on IIS using the WSGI application, so that method should work on Apache also. What problems are you having?
[22:31] <Kobaz> with webdav, i get...
[22:31] <Kobaz> bzr init-repo https://bzr.local/newrepo
[22:31] <Kobaz> bzr: ERROR: Transport operation not possible: http does not support mkdir()
[22:31] <Kobaz> i have the webdav plugin
[22:32] <Kobaz> but it's not being used
[22:32] <Kobaz> and there's no docs
[22:32] <awilkins> Kobaz: Try bzr+http:// instead and see if that works
[22:32] <Kobaz> if i try the mod_python approach, everything is a 404
[22:32] <awilkins> I'm not sure you can initialise a repo over HPSS though
[22:32] <Kobaz> yeah
[22:32] <Kobaz> i've tried that too
[22:32] <Kobaz> zr: ERROR: Generic bzr smart protocol error: Invalid http response for https://bzr.local/newrepo/.bzr/smart: Unable to handle http code 404: Not Found
[22:32] <awilkins> Have you seen http://doc.bazaar-vcs.org/bzr-0.15/http_smart_server.htm
[22:33] <Kobaz> ah okay
[22:33] <awilkins> It looks like it's not catching /smart URLs and redirecting them to the application
[22:33] <Kobaz> yeah
[22:33] <Kobaz> i was using the mod_python spot in there
[22:33] <Kobaz> lemme uncomment the python stuff
[22:34] <awilkins> I think your RewriteRule is absent or fubar
[22:35] <Kobaz> RewriteRule ^(.*/|)\.bzr/smart$ /home/web/bzr.local/scripts/bzr-smart.py
[22:38] <Kobaz> i think the rewrite rules aren't kicking in at all
[22:38] <Kobaz> i tried a simple rewrite, and it doesn't do anything
[22:38] <Kobaz> hmm
[22:40] <Kobaz> ah
[22:40] <Kobaz>     RewriteEngine on
[22:40] <Kobaz> had to add that
[22:41] <Kobaz> should have looked into that before
[22:48] <Kobaz> okay, now that rewrite is working
[22:48] <Kobaz> where do i get bzr-smart.py
[22:48] <Kobaz> it's not in the source, and i can't find any download links at all
[22:50] <lifeless> jml: see the code :P. It's not a TSP solution, its what I postulated would work way back and hadn't had time to code
[22:50] <jml> lifeless: ahh ok
[22:50] <lifeless> jml: I don't think the problem is actually NPC though, because it has no shortcuts
[22:51] <lifeless> given ABC A->B is never more expensive than A->C->B
[22:51] <Kobaz> do de do
[22:51] <Kobaz> so would anyone know where one would get bzr-smart.py
[22:51] <poolie> hi lifeless
[22:52] <lifeless> hi poolie
[22:52] <Kobaz> is it a plugin?
[22:52] <lifeless> Kobaz: there is no such file, its just what is described in the docs
[22:52] <jml> lifeless: I'll need to refresh my graph traversal knowledge to make the connection between that and NPC
[22:53] <Kobaz> lifeless: what would i use then?
[22:53] <lifeless> Kobaz: what is described in the docs, it gives the code as I recall
[22:53] <Kobaz> hmm
[22:53] <lifeless> spiv: ^ kobaz could do with a hand, I think
[22:53] <Kobaz> i didn't see any code
[22:53] <Kobaz> there was a download of the fastcgi code
[22:54] <Kobaz> but not the bzr-smart
[22:54] <Kobaz> and there's some wsgi code
[22:55] <Kobaz> oooh
[22:55] <Kobaz> there is some code
[22:55] <Kobaz> hmm
[22:55] <Kobaz> wow, that's not obvious at all :P
[22:55] <lifeless> jml: well Travelling salesman is np-complete, as its got no known solution that isn't polynomial; because there is no way to be sure that AB is better than ACB in the above example, without calculating both
[22:56] <lifeless> jml: it is possible that the solution I have is actually polynomial overall because of the setup
[22:56] <lifeless> jml: but anyhow; it works for all the tests we have today. So I'm happy.
[22:57] <Kobaz> ImportError: No module named modpywsgi
[22:57] <Kobaz> mmm
[22:57] <jml> lifeless: so, like I said, I want to refresh my graph traversal knowledge to make the connection between the shortcut thing and NPC :)
[22:57] <lifeless> jml: :>
[22:58]  * jml suspends and resumes, to see if that fixes a thing.
[22:59] <beuno> things usualy break when I do that
[23:00] <beuno> *never* fixes them
[23:03] <epper> Hi all
[23:04] <Kobaz> so now i need the modpywsgi module... the link is a 404 and the site is really really slow
[23:04] <epper> I'm a svn user and, looking ad distributed VCS I come to Bazaar
[23:05] <epper> I don't really understand the real difference between the "Decentralized with shared mainline" and "centralized with local commits" workflows
[23:05] <epper> Could someone tell me?
[23:06] <epper> (here's where i found that names: http://bazaar-vcs.org/Workflows)
[23:06] <Kobaz> epper: i've trying to move to bazaar from svn too... it's been a bit of a pain so far, but hopefully it will be worth it
[23:07] <epper> Really we don't need to make a switch, we have to choose a VCS for a new project ;)
[23:07] <epper> So... It will be hopefully easy... both ways :)
[23:07] <Kobaz> ditto
[23:07] <Kobaz> heh
[23:08] <Kobaz> all i'm trying to do, is set up a webdav style repo so it can be accessed from anywhere with a password
[23:08] <Kobaz> been fighting it all day
[23:08] <Kobaz> with svn it took all of 5 minutes
[23:08] <epper> right
[23:08] <epper> Hope one single day will be enough for Bazaar :)
[23:09] <Kobaz> okay, i found a copy of the modpywsgi somewhere else, the script isn't barfing anymore at least
[23:11] <Kobaz> bzr init-repo bzr+https://bzr.local/bzr/newrepo
[23:11] <Kobaz> bzr: ERROR: Transport operation not possible: readonly transport
[23:11] <Kobaz> now what?
[23:11] <Spaz> you shouldn't be using https to do that.
[23:11] <Spaz> use bzr+ssh
[23:11] <Kobaz> i thought you were supposed to be able to have write access with the mod_python setup?
[23:11] <Kobaz> hmm
[23:11] <Kobaz> for creating the repo?
[23:11] <Spaz> using the bzr_access script (it's easy to set up)
[23:12] <Kobaz> or for all write operations?
[23:12] <Kobaz> k
[23:12] <Spaz> for all write operations
[23:12] <Kobaz> hmm
[23:13] <Kobaz> so i should use ssh for everything then?
[23:13] <Kobaz> i don't really want to use one for reading and one for writing
[23:13] <epper> "Centralized with local commits" and "Decentralized with shared mainline" workflow aren't in fact two different ways to get the same result?
[23:14] <Kobaz> no idea... sounds the same to me
[23:14] <epper> so: developers working alone on their tasks and commiting to the main repository when ready?
[23:14] <Kobaz> yeah
[23:15] <bob2> they're all different ways to get the same result, more or less
[23:15] <Kobaz> that's the advantage of a decentralized vcs
[23:15] <bob2> Kobaz: you can just use ssh for everything, and it is a lot easier to get going than webdav + mod_python + ...
[23:15] <Kobaz> subversion: commit new feature... commit fix for new feature... commit fit for the fix... commit documentation
[23:15] <fullermd> All the smart server protocols are capable of writing, if writing is enabled.
[23:15] <bob2> assuming you have the infrastructure to easily manage accounts etc
[23:16] <epper> Yes, I agree... It's a huge advantage... even with the ability to commit to someone else working copy without touching directly the main trunk
[23:16] <Kobaz> distributed: checkout repo, commit commit commit commit (to local)... and then when you finish all your work... commit that batch to the central repo
[23:16] <Kobaz> fullermd: oh, that's good
[23:16] <Kobaz> fullermd: how would i enable writing?
[23:17] <Kobaz> bob2: i dont really want to have to give out ssh accounts for each developer
[23:17] <fullermd> Kobaz: The examples given in the docs all set things to read-only.  Just flip the boolean value of the readonly setting, and it should work.
[23:18] <fullermd> (this is educated guesswork, since I've never used the HTTP smart server variants, but I'd expect it to Just Work)
[23:18] <Kobaz> oh, i didn't notice the readonly setting
[23:18] <fullermd> "Centralized with local commits" involves treating checkouts as half-checkouts, either via commit --local or unbind, which I consider to be an all-around Bad Idea.  IMO.
[23:20] <epper> fullermd: I'm really new to bazaar (but i use svn)... Why are they a Bad idea?
[23:20] <Kobaz> bzr init-repo bzr+https://bzr.local/bzr/newrepo
[23:20] <Kobaz> bzr: ERROR: No such file: None
[23:22] <Kobaz> oooo
[23:22] <Kobaz> i did a mkdir newrepo on the server
[23:22] <Kobaz> and that worked
[23:22] <Kobaz> heh, the error reporting isn't very good
[23:22] <epper> fullermd: Seem to me that the other way get the same result... Is it better? why?
[23:22] <fullermd> That's a long question.  The short version is that they mean treating a checkout (which isn't an independent branch) as an independent branch.  It's a basic impedence mismatch.  It's aggravated by some suboptimal tool behavior in certain of the cases, but even with those fixed, it's riding Roman.
[23:24] <fullermd> Basically, the purpose of checkouts is to work in lockstep on a single branch from multiple working trees (e.g., the _only_ way CVS/SVN/etc work).
[23:25] <fullermd> Whereas making independent branches via 'branch', and then moving changes back from them via 'merge', is operating more in the distributed mold.
[23:25] <fullermd> Local commits in checkouts (either via ci --local, or via unbind/bind hoops) is using the former tool to achieve basically the latter behavior.
[23:26] <Kobaz> okay so now that i have a remote shared repo
[23:26] <fullermd> I mean, it _works_, and it's there intentionally.  And there are people who are perfectly happy with it.
[23:26] <Kobaz> how do i add to it, or do a checkout from it
[23:27] <Kobaz> bzr branch bzr+https://bzr.local/bzr/newrepo
[23:27] <Kobaz> bzr: ERROR: Not a branch: "bzr+https://bzr.local/bzr/newrepo/".
[23:28] <fullermd> But it's kinda skating on the edge in a way.  And it's double evil, since the behavior can end up being really confusing if you're not already familiar with using bzr in both types of workflows, so considering it when you're in an "intro" mode is particularly egregious.
[23:28] <fullermd> Kobaz: You don't checkout or branch or work in repositories in bzr; the main unit is the branch.
[23:28] <fullermd> So you'd have to `bzr init bzr+https://bzr.local/bzr/newrepo/trunk` (or whatever you want to call it) before you can work on it.
[23:28] <Kobaz> k
[23:30] <epper> fullermd: So you suggest to take the second approach
[23:30] <epper> "Decentralized with shared mainline"?
[23:31] <Kobaz> okay, i think i have it working now
[23:31] <fullermd> Roughly, yah.  I think it's less confusing, because it means you always _know_ whether you're dealing with the [shared] trunk, or a [non-shared] local branch.
[23:31] <Kobaz> what's a good way to do a live backup of a bzr repo
[23:31] <Kobaz> i know svn has svnsync
[23:31] <epper> fullermd: Understood, thanks very much ;)
[23:33] <epper> And... Other options for a free Bazaar hosted repositories than launchpad?
[23:33] <fullermd> There's nothing in bzr that copies around repositories.  You could "pull" all the individual branches in it.  You could grab up the repo with FS-level tools (tar, rsync, etc).
[23:34] <fullermd> There are things like bzrtools' "multi-pull" that can help with automating the former choice.
[23:34] <Kobaz> but with using rsync, is there any issue of copying over a half written file
[23:35] <Kobaz> there are issues with svn (and others) about just backing up the raw files
[23:35] <Kobaz> when you do a pull, does it pull down just the latest data, or does it pull all history
[23:36] <bob2> former, such that you end up with all
[23:36] <Kobaz> k
[23:36] <Kobaz> so if you wanted to back up the repo with history
[23:36] <Kobaz> you would need to rsync
[23:36] <Kobaz> or would the multi-pull accomplish that?
[23:37] <Kobaz> $ bzr st
[23:37] <Kobaz> modified: a
[23:37] <Kobaz> $ bzr push
[23:37] <Kobaz> Using saved push location: ...
[23:37] <bob2> multi-pull should do
[23:37] <Kobaz> No new revisions to push.
[23:37] <fullermd> You can certainly copy over a half-written file, but it wouldn't be in a place bzr would look for it, so it doesn't much matter.
[23:37] <bob2> sure, pull only gets /history/ ie things that are commited
[23:37] <fullermd> multi-pull pulls a set of branches.  Nothing pulls a _repository_ as such.
[23:38] <Kobaz> k, that was the question
[23:38] <Kobaz> and umm... so i modified a file, and the push isn't sending it up
[23:38] <fullermd> You didn't commit it.
[23:38] <fullermd> push/pull only deal with commits.  Uncommitted changes never go anywhere.
[23:39] <Kobaz> ooooh
[23:39] <bob2> just like in svn, y our uncommited changes exist only in the working tree
[23:39]  * Kobaz initiats an svn excersisim
[23:39] <Kobaz> s/initiats/initiates/
[23:39] <Kobaz> yeah
[23:40] <Kobaz> i was thinking push would auto commit, because with svn there is no differentiation
[23:40] <fullermd> One way of thinking about it (which is subtly incorrect, but can be a useful mental crutch) is the differentiation between recording and publishing.
[23:40] <fullermd> In SVN, there isn't any; commit is both for recording what you're doing, and publishing it to the world.
[23:40] <Kobaz> yeah, i know what it means
[23:40] <fullermd> With a distributed system, they're different; commit records it, and push publishes what's recorded.
[23:40] <Kobaz> yeah
[23:41] <fullermd> (it's technically wrong of course because it all depends on what branches are where and what branches you're committing to.  But it's close enough for a rule of thumb)
[23:42] <Kobaz> yeah, if someone is working off your branch directly
[23:42] <Kobaz> then you don't need to push
[23:43] <Kobaz> the use of only one .bzr directory is pretty awesome
[23:43] <fullermd> Or if you'd done a "bzr checkout bzr+https://wherever/newrepo/trunk", then the branch you put things into when you commit actually is the bzr+http://... one (since you have a checkout, rather than an independent branch)
[23:44] <Kobaz> yeah
[23:44] <Kobaz> bzr push
[23:44] <Kobaz> bzr: ERROR: No push location known or specified.
[23:44] <Kobaz> bzr lost my push location
[23:44] <Kobaz> it just had it
[23:45] <fullermd> What's bzr info say?
[23:46] <Kobaz> it has it now, i specified a specific push path
[23:46] <bob2> bzr push doesn't default to the place you bzr branch/pulled from
[23:46] <Kobaz> lemme do what i dod again
[23:46] <bob2> once you specify a push location once, though, it will be remembered
[23:46] <Kobaz> s/dod/did/
[23:46] <fullermd> There are automatic aliases for the various saved locations too, so if you wanted to push to where you pull'd from, you could "bzr push :pull"
[23:46] <Kobaz> it was working
[23:47] <Kobaz> and then it lost it
[23:47] <nevans> fullermd, I didn't know you could do that... what "bzr help" topic didn't I read?  :)
[23:47] <fullermd> nevans: Well, lots of them probably   :p
[23:48] <Kobaz> hmm, can't seem to reproduce it
[23:48] <nevans> which one is the ":pull" -- "branch location meta names" in?  :)
[23:48] <fullermd> nevans: But I don't think it's particularly documented anywhere...
[23:48] <Kobaz> i definitly did a push earlier from that directory
[23:49] <fullermd> Oh, I guess it's :parent actually, not :pull
[23:49] <nevans> fullermd, I would have expected that to be in urlspec.
[23:50] <Kobaz> hehe
[23:50] <Kobaz> any time i want to do a bzr command, i keep typeing svn
[23:50] <fullermd> Mmm.  Not really, since they're not URL types.  They'd deserve their own topic.
[23:51] <fullermd> AFAIK, the only place you'd actually see them referenced is in NEWS, and you end up having to check the source for the list of what choices there actually are.
[23:51] <nevans> hmmm...
[23:51] <fullermd> Kobaz: That's nothing.  Use bzr for a year or so, and you'll be totally unable to type 'bzr'.
[23:51] <fullermd> Aarg!.  'bar'!
[23:51] <fullermd> See?
[23:51] <Kobaz> heh
[23:52] <Kobaz> bzr bzr bzr bar
[23:52] <Kobaz> mmm
[23:52] <fullermd> A guy walks into a bzr...
[23:52] <Kobaz> two guys walk into a bzr
[23:53] <Kobaz> you would think the second one would have noticed
[23:55] <Kobaz> okay, so next question...
[23:55] <Kobaz> what's a good windows client
[23:55] <Kobaz> for those other people
[23:57] <fullermd> markh would be the guy to talk to about that, I think.
[23:58] <markh> a good bzr windows client?  There is only 1 available for each version, so take your pick :)
[23:58] <markh> iow, there's not alot of choice really