[00:00] <igc> morning
[00:02] <cjwatson> igc: fast-import is awesome
[00:03] <mwhudson> hello igc
[00:03] <cjwatson> igc: I'm importing an svn archive at the moment with a vendor-branch-like arrangement for upstream, and trying to arrange that the resulting bzr branch has native merge commits for each upstream merge. It's working amazingly well
[00:03] <cjwatson> (james_w gave me the last necessary clue in the form of import-marks)
[00:04] <james_w> cjwatson: I'm glad it's working for you
[00:11] <igc> thanks cjwatson
[00:20] <lifeless> jelmer: ping
[00:20] <jelmer> lifeless, ponggg
[00:20] <lifeless> bug 250480
[00:20] <lifeless> I agree with john that this is critical
[00:20] <lifeless> I don't understand quite where the issue is re non-lhs parents and the error
[00:21] <lifeless> from my analysis I thought that there were two inventories with different values and the same revid
[00:21] <lifeless> which is also known as 'corrupt distributed DB'
[00:21] <lifeless> but you seem to think its something else
[00:21] <lifeless> ?
[00:22] <jelmer> No, I agree with that analysis (for values == "file parent ids")
[00:22] <lifeless> parent ids are not stored in the inventory
[00:23] <lifeless> so I don't understand what you mean when you say you agree :)
[00:24] <jelmer> The actual error suggests that bzr can't find the revision of a file text
[00:24] <jelmer> however, that file text is a ghost in the branch fetched by bzr-svn
[00:25] <lifeless> so there are three revisions bzr will look for
[00:25] <lifeless> (and need)
[00:25] <lifeless> and some N that it will need when fetching IFF the revision is also present
[00:25] <lifeless> the three it needs are left/right/base
[00:26] <lifeless> but another possibility is that the change rev in the inventory in the target repo is actually bogus; its a change that the repository does have and can't get hold of
[00:26] <lifeless> or something along those lines
[00:27] <lifeless> back in 30, got to do some stuff here
[00:27] <lifeless> I guess I'm really saying: lets pin down *exactly* why bzr is asking for that revision, and whether there are *any* differences in data between the repositories
[00:27] <lifeless> *other* than ghosts. Ghosts are ok, different xml-inventories or revision-xml's etc are not.
[00:30] <jelmer> as far as I can tell, the particular revision it was asking for doesn't occur in svn or the svn-based branched *anywhere*
[00:51] <markh> I thought I heard that bzrtools has been incorporated into 1.6 - is that true, or only some parts have been incorporated?
[00:52] <markh> ultimately I'm trying to work out if the windows binary should package it?
[00:53] <Peng_> Um, it hasn't been.
[01:00] <spiv> markh: it hasn't been incorporated, no.  So please do package it.
[01:03] <markh> spiv: ok, thanks
[01:04] <igc> jam: wrt export masking, do you think plugins should use another pattern if they want their magic stuff exported?
[01:05] <igc> jam: I could put the rule in a function that plugins could monkeypatch over to tune it *but* that feels pretty fragile myself
[01:05] <lifeless> I think there are two use cases
[01:06] <lifeless> one is adding arbitrary data (e.g. version-info output) during export
[01:06] <lifeless> the other is masking data that shouldn't be in the user tree (e.g. .bzrignore)
[01:06] <lifeless> I'd *prefer* we fix the latter by just not putting in the users tree
[01:06] <lifeless> the former seems genuinely useful though
[01:07] <igc> lifeless: I'm not changing the former, just generalising the latter so that anything starting with .bzr is not exported
[01:08] <lifeless> igc: yes, I saw the patch.
[01:09] <jelmer> spiv: --rich-root is not an alias at the moment, were you assuming it was?
[01:10] <spiv> jelmer:
[01:10] <spiv> $ bzr init --help | grep -A1 -- "--rich-root "
[01:10] <spiv>     --rich-root         New in 1.0.  Better handling of tree roots.
[01:10] <spiv>                         Incompatible with bzr < 1.0
[01:11] <mwhudson> beuno: awake?
[01:11] <spiv> jelmer: so I wasn't just assuming, I checked :)
[01:12] <jelmer> spiv: that's not an alias, it's a knits-based format
[01:12] <spiv> Ah :(
[01:14] <jelmer> it may be a good idea to get rid of it though, in favour of an alias...
[01:17] <spiv> jelmer: thanks for noticing my mistake
[01:26] <beuno> mwhudson, yeap, evening'
[01:27] <beuno> just got home
[01:27] <lifeless> hi
[01:27] <mwhudson> beuno: hi, thanks for fixing loggerhead :)
[01:28] <beuno> mwhudson, I felt a bit responsible  :)
[01:28] <mwhudson> beuno: so i am a little confused though
[01:29] <mwhudson> beuno: will the loggerhead we're running break with current bzr.dev ?
[01:31] <beuno> mwhudson, no, it works with bzr.dev
[01:32] <beuno> a few commits after b2
[01:32] <mwhudson> beuno: good
[01:32] <beuno> when lifeless's enourmous patch landed it broke
[01:32] <mwhudson> so why did this method change?
[01:32] <mwhudson> oh right
[01:32] <mwhudson> then bzr.dev became more compatible again?
[01:32] <beuno> "versioned files" and the likes
[01:33] <beuno> compatible relative to what?  :)
[01:33] <mwhudson> well
[01:33] <beuno> one of the things I was thinking of, is having that part patched in LH for a few versions, where it tried both methods
[01:33] <mwhudson> wasn't the patch you gave kiko reverting the change that was made to this method?
[01:34]  * mwhudson attempts to make sense
[01:34] <mwhudson> the loggerhead we're running does this:
[01:34] <mwhudson> w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction())
[01:34] <mwhudson> rather than existing_keys = self._branch.repository.texts.get_parent_map(possible_keys)
[01:34] <beuno> mwhudson, yes, because you're running b2 in code host
[01:35] <lifeless> mwhudson: the former won't work in b3 and abot
[01:35] <mwhudson> because .texts doesn't work with b2
[01:35] <beuno> and it works from b3+
 beuno: will the loggerhead we're running break with current bzr.dev ?
 mwhudson, no, it works with bzr.dev
[01:35] <beuno> mwhudson, ah, my mistake
[01:35] <beuno> it will
[01:35] <mwhudson> is this actually what you meant to say?
[01:35] <beuno> I warned matsubara
[01:35] <beuno> that it would
[01:35] <mwhudson> ah, ok
[01:35] <beuno> I misunderstood
[01:36] <beuno> I just bought a Wii and got distracted   :)
[01:36] <mwhudson> ok, so this isn't ideal but at least i understand what's going on now :)
[01:37] <beuno> yeah, I offered to put together a patch that would probe one, and go to the other if it failed
[01:37] <beuno> but they chose reverting
[01:37] <mwhudson> okidoke
[01:38] <beuno> I still think it makes sense to do that for trunk
[01:38] <beuno> so we can be compatible with older bzr versions
[01:40] <mwhudson> yeah i guess so
[01:43]  * beuno is off to dinner
[02:00] <tsculpt> anybody have trouble saving commit message with emacs as editor?
[02:01] <tsculpt> I get: vc-bzr-registered: IO error reading c:/bzrfun/home/main/.bzr/checkout/dirstate: Permission Denied, when tring to save
[02:02] <tsculpt> bzr 1.5
[02:04] <lifeless> tsculpt: bzr will have an exlusive lock on the dirstate file
[02:04] <lifeless> tsculpt: sounds like some emacs thing is trying to read that file directly (not such a great idea btw :P)
[02:05] <tsculpt> well, just trying to use emacs as commit editor
[02:05] <tsculpt> bzr commit
[02:06] <tsculpt> emacs comes up with the modified listing
[02:06] <tsculpt> I write my message, and try to save, and I get the error.
[02:07] <tsculpt> The vc-bzr-registered part makes me think emacs is doing something with it's built in vcs stuff?
[02:10] <tsculpt> ah, I notice it loads vc-bzr
[02:36] <markh> hrmph - "bzr help commands" will list 94 commands by default on Windows!!
[02:50]  * igc lunch
[05:20] <lifeless> igc: ping
[05:20] <igc> hi lifeless
[05:20] <lifeless> I'd like to chat about .bzrrules some
[05:20] <igc> fire away
[05:20] <lifeless> if you're up for it I could give you a ring
[05:21] <lifeless> or else drop you a mail
[05:21] <lifeless> or IRC works for me too
[05:21] <igc> email might be best today
[05:21] <lifeless> k
[05:22] <lifeless> I will drop some thoughts to you directly
[05:22] <igc> sure
[07:01] <gambler> I read that limbo post from http://bazaar-vcs.org/BzrVsGit and I realised thats a big problem for me
[07:01] <gambler> has anything been done about it in bzr?
[07:02] <luks> what is a big problem for you?
[07:03] <bob2> which part?
[07:03] <bob2> you can alias 'commit' to 'commit --strict' if you don't want to forget to commit new files
[07:03] <gambler> the files that remain in limbo...those in a directory that aren't explicitly added to the repo to track
[07:03] <gambler> bob2, yeah but i prefer to automate alot of that
[07:04] <bob2> as in you want bzr to run 'bzr add .' before every commit?
[07:04] <gambler> i suppose
[07:05] <gambler> would that work?
[07:05] <gambler> <-- not a current bzrer
[07:11] <RAOF> gambler: That would work, but is probably not a good idea.
[07:11] <RAOF> gambler:
[07:12] <RAOF> gambler: In particular it would mean that you wouldn't want to build in your working tree, since subsequent commits would then add the results of the build (plus random autotools files, etc).
[07:12] <luks> you can `bzr ignore` those
[07:12] <bob2> well, you would ignore that .o configure.ac etc
[07:13] <RAOF> bzr doesn't do globbing in .bzrignore, right?
[07:13] <bob2> it does
[07:14] <luks> it supports full filenames, globbing and regexes
[07:14] <bob2> it optionally does res
[07:14] <RAOF> Of course; my shell's being too smart for its own good.
[07:14] <gambler> so bzr add . bzr ignore *.class for my android project and I get automatic adds?
[07:15] <bob2> no
[07:15] <luks> gambler: commit --strict is really a better idea
[07:16] <luks> automating things is nice and all that, but some things are better to review
[07:16] <bob2> hey, you'll get a chance to review in the commit editor ;)
[07:17] <luks> that's way too late, IMO :)
[07:17] <gambler> luks: thats how it starts...then why dont I write some unit tests, and X and Y and Z....and my productivity drops like a rock
[07:17] <spiv> If you do bzr alias commit="commit --strict" then bzr will automatically tell you if there are new files you haven't added or ignored yet.
[07:18] <gambler> ok..maybe ill try that
[07:18] <spiv> At which point you can decide what to do about them, and get on with work.  That satisfies the criterion for "automated" pretty well for me :)
[07:19] <gambler> meh, the problem with all VCS is that it would be nice if all their interfaces were pure method calls, then I could design my workflow around them instead of the other way
[07:19] <gambler> I could script but then you run into problems making it robust
[07:19] <gambler> i script now
[07:19] <spiv> More automatic would probably mean automatically guessing what to do with individual files, which wouldn't make me comfortable.  I can imagine that working fine for some people, though.
[07:20] <spiv> Well, bzr is completely scriptable in Python.
[07:20] <gambler> hmmm good point
[07:20] <spiv> It's even pretty easy to write a plugin to add new commands or extend existing ones.
[07:25] <gambler> im looking at bzrlib now...but im not really a python dude
[07:35] <Ryan52> Is there any way to go through a projects history and change my name everywhere? Right now it's just <email>, but I want it to be 'Name <email>'.
[07:36] <Jc2k> beuno: i hit a bug so i reverted
[07:36] <Jc2k> beuno: its not finding css/imagery again..
[07:37] <luks> Ryan52: no, revisions are immutable
[07:38] <luks> Ryan52: something like that would need to create a completely new branch with different revision IDs
[07:38]  * Ryan52 thinks he would get in trouble for doing that :)
[07:38] <Ryan52> okay, thanks.
[07:42] <gambler> meh too much work
[07:42] <gambler> what is the status of the bzr plugin for eclipse...anyone here using it?
[07:42] <lifeless> it works quite well
[07:43] <lifeless> Verterok: is the main developer
[07:43] <Verterok> gambler: I'm about to release a new build (with bunch of improvements)
[07:44] <gambler> Verterok, will it mind my adding and deleting of files?
[07:45] <Verterok> gambler: it handle moves/deletes/renames
[07:46] <Verterok> gambler: but the delete is equivalent to 'bzr rm --keep' (to avoid removing non-recoverable files)
[07:47] <luks> (all files deleted by `bzr rm` are recoverable)
[07:49] <lifeless> yay firefoxfail
[07:49] <gambler> if you could add in auto-adding of files that would be pure sex
[07:51] <Verterok> luks: but if you have added (not yet committed) bzr rm --force delete them in a non-recoberable way :)
[07:51] <luks> ugh
[07:52] <luks> but why --force?
[07:52] <lifeless> I'm not entirely happy with rm today
[07:53] <lifeless> the basic tension is that unversion and rm are different operations
[07:53] <lifeless> but we only have one command, because people usually want both operations to be undertaken
[07:53] <Verterok> gambler: I don't fully understands the "auto-adding" thing :P
[07:53] <luks> I don't think rm should be handled by a VCS
[07:54] <luks> the old behavior (rm --keep) was my favorite
[07:54] <gambler> Verterok, auto-add any newly created files in the root directory, unless they are in the bzr ignore list.
[07:55] <gambler> Verterok, for renames....improvise :)
[07:55]  * fullermd has rm aliased to rm --keep.
[07:55] <gambler> Verterok, actually you can tie into Eclipse->Refactor-Rename
[07:55] <luks> yeah, me too
[07:56] <Verterok> gambler: mmm, there was a bug/feature request some time ago (java specific), about auto-adding newly reated classes.
[07:56] <gambler> and?
[07:56] <Verterok> gambler: if I can provide an option so it can be enabled/disable, I'll be glad to add this feature
[07:57] <Verterok> but I don't want that behaviour as default
[07:57] <Verterok> gambler: renames are handled by the plugin
[07:57] <Verterok> :)
[07:57] <gambler> i will love you forever
[07:58] <gambler> cant wait to try it. i am an insane refactorer and I need that
[08:00] <Verterok> Verterok: if you find any glitches (or missing feature), please fill a bug so I can track and plan the features for the next milestone :)
[08:00] <Verterok> s/Verterok/gambler/ :P
[08:02] <gambler> np..when will you release your next version
[08:03] <Verterok> gambler: if all keep going as planned, in ~ 20hs :)
[08:03]  * Verterok need to sleep a few hours
[08:04] <gambler> ok...no rush. i've written myself a note to download it
[08:04] <Verterok> I just finished a build from trunk, and testing it ATM
[08:15] <Verterok> all for today, seeya later
[08:15]  * Verterok heads to bed
[08:16] <gambler> c u
[08:31]  * igc dinner
[10:25] <cjwatson> igc: hmm, so having said that I had a really good import (an svn branch for a Debian package which I'm gluing onto the side of the existing bzr branch for upstream) with bzr-fastimport, I realised that all my file-ids are screwed
[10:26] <cjwatson> igc: is there any way to get fast-import to say "this commit has 'from' or 'merge', therefore all files added in this revision should take their file-ids from that other branch"?
[10:35] <igc> cjwatson: hi, I can't stay and chat sorry but a few things ...
[10:36] <igc> how did you generate the stream? By hand?
[10:36] <cjwatson> igc: slightly hacked version of svn-fast-export.py
[10:36] <igc> See the spec. You can certainly say 'get the file-ids' from another branch *assuminh* that branch is also in the stream already
[10:36] <cjwatson> (I stuck in a dictionary of commit identifiers to marks that I wanted to be merged)
[10:37] <cjwatson> hmm, did I miss it? I thought I looked
[10:37] <cjwatson> the other branch is not in the import stream; I'm referencing it by means of import-marks
[10:38] <james_w> fast-import won't look at the those revisions, it will just add the extra parents you request.
[10:38] <james_w> I believe we could extend fast-import to optionally look for them and import the file-ids.
[10:38] <igc> cjwatson: spec is http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html
[10:39] <cjwatson> yeah, I'm reading that
[10:39] <james_w> hi igc
[10:39] <igc> hi james_w
[10:39] <cjwatson> it seems to have a way to reference existing content from elsewhere, but not existing file-ids
[10:40] <igc> cjwatson: so I won't be around but james_w knows the fastimport code pretty well and it's pretty hackable imo
[10:40] <cjwatson> yeah, I certainly don't mind hacking it (and already have done), but wanted to know if this was in place already
[10:40] <cjwatson> if it's not, I can always beat it up until it is
[10:41] <cjwatson> it does seem like it's what you'd want to be the default behaviour when 'merge' commands are present in the stream though
[10:42] <james_w> cjwatson: for a quick hack, around line 513 of processors/generic_processor.py could be extended to also look at all the revision ids listed in the marks
[10:43] <james_w> _gen_file_ids_cache
[10:44] <cjwatson> hmm, right, might have to do something interesting in the case where you have file added in svn branch, then deleted and copied-over-the-top
[10:44] <cjwatson> since then there'll be multiple file-ids to choose from for a given path
[10:44] <james_w> yeah, the cache should actually be replaced with something else as I understand it
[10:45] <lifeless> personally; I'd just let bzr do all the heavy lifting
[10:45] <james_w> however, I think the replacement would actually be harder for you to hack to get what you want
[10:45] <james_w> hey lifeless
[10:45] <lifeless> but apparently there were performance implications in doing that
[10:45] <cjwatson> I have the feeling I want to special-case it at the cache user end, since I only want this check in the cases of certain commits
[10:46] <james_w> bzr_file_id_and_new
[10:46] <cjwatson> like bzr_file_id_and_new(self, path, sourcerev=None)
[10:46] <cjwatson> snap :)
[10:49] <nazgjunk> hi, do ignore files stack? I seem to have a global ignore file somewhere, can I assume that it'll still be checked when I add one to the branch I'm working in?
[10:49] <james_w> nazgjunk: ~/.bazaar/ignore, and yes
[10:50] <nazgjunk> thanks
[10:57] <lifeless> right
[10:57] <lifeless> bug fixed
[10:57] <lifeless> -> off
[10:59] <Jc2k> ahh that reminds me
[10:59]  * Jc2k goes to read gnome-bzr log
[12:46] <lifeless> igc: got busy on a bug; I'll try to mail you tomorrow; or perhaps voice would work better then; something
[12:46] <lifeless> gnight all
[12:46] <igc> sure lifeless; night
[15:47] <pfctdayelise> hi, I'm trying to use bzr on a shared webhost. 'python' -> 2.3.4, which has the bz2 module, but there is also 'python2.4' which does not.
[15:47] <pfctdayelise> can I get bzr to use python 2.3? or should i try to install the bz2 module?
[15:48] <dennda> Hi. How can I fix this? http://paste.pocoo.org/show/80707/
[15:48] <dennda> Doesn't work with bzr push lp:~dennda/memaker/experimental either
[15:48] <dato> pfctdayelise: bzr will definitely not work with python 2.3
[15:49] <andrea-bs> dennda: bzr launchpad-login "your-launchpad-id"
[15:49] <luks> dennda: bzr launchpad-login <your-username>
[15:50] <luks> or just use a ssh+bzr url directly
[15:50] <luks> bzr+ssh I mean
[15:53] <mlh> I suppose people have read http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation
[15:53] <mlh> ?  haskell is moving away from darcs  - interesting discussion of git vs hg vs bzr
[15:55] <jelmer> mlh, that page only lists git and mercurial as serious contenders
[15:56] <jelmer> do you know why that is?
[15:57] <luks> weird how 'Cherry-picking isn't very "native" to the data model' is a disadvantage of bzr, but not hg and git
[16:04] <mlh> jelmer: that's what one line says, but the rest of the page seems to contradict it
[16:04] <mlh> so .. not clear
[16:05]  * mlh sleeps
[16:10] <gour> have you seen  http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation  ?
[16:11] <gour> new potential customer...
[16:12] <james_w> heh :-)
[16:14] <gour> ghc is not so small project and has (potential) influence on the whole haskell community
[16:15] <arnarl> what are the commands for resetting/changing related branches (as listed in bzr info)
[16:17] <arnarl> is it only available in locations.conf?
[16:17] <james_w> arnarl: you can either edit ~/.bazaar/locations.conf, or you can use --remember on the appropriate commands
[16:18] <james_w> so "pull --remember" will change the parent branch, "merge --remember" will change the submit branch
[16:18] <arnarl> james_w: thnx! :-)
[17:21] <jam> chadmiller: Ping, would you like to discuss the new issue privately?
[17:21] <chadmiller> Sure.
[18:59] <beuno> jelmer, around?
[19:27] <evanton> hello, how can one force bzr to make a file executable?
[19:28] <luks> chmod a+x file
[19:28] <evanton> luks: let me explain
[19:28] <evanton> I have to assume somebody submits a text file containing a python script from windows
[19:29] <evanton> when I check out the branch, that file has 644 permission
[19:30] <evanton> I would like it to have 755 instead, so there must be probably a way to tell bzr that it shall set certain permissions during a commit
[19:30] <luks> evanton: on windows it's more complicated, since bzr itself doesn't support it
[19:30] <luks> there is a plugin that can be used to swith the executable flag on windows
[19:31] <luks> https://launchpad.net/bzr-x-bit
[19:31] <evanton> do you think that chmodding the file in linux and commiting it into the branch from there instead would work?
[19:31] <luks> evanton: of course
[19:32] <evanton> thank you
[19:51] <rexbron> hey would any of the bzr-svn guys be able to look at bug 253376
[19:57] <jelmer> rexbron: just replied
[19:59] <rexbron> jelmer: As I mentioned, if you remove the dir your checking into and re-run the command, it will pick up where it left off. So it's not that serious. Perhaps it is worth a mention on the bzr-svn known issues section
[20:06] <jelmer> rexbron, I think it's worth mentioning, but rather in the bzr docs than in bzr-svn since neither the bug nor the workaround are specific to bzr-svn.
[20:06] <rexbron> ok
[20:32] <beuno> jelmer, I'm working on a branch to fix loggerhead's setup, can you take a look at it and see if you need anything changed for Debian?
[20:33] <beuno> lp:~beuno/loggerhead/fix_setup
[20:34] <jelmer> beuno, sure, give me a few minutes
[20:34] <beuno> jelmer, thanks  :)
[21:29] <theuiguy> Is there any kind of plugin for bzr that allows you to modify history? Specifically, to change email/names of committers?
[21:29] <theuiguy> Or perhaps some way to modify check in dates?
[21:30] <NfNitLoop> theuiguy: not to my knowledge...  modifying history is not really possible in a distributed system.
[21:30] <NfNitLoop> You could modify *your* history, but then you don't sync up w/ everyone else.
[21:30] <NfNitLoop> which could cause problems.
[21:30] <theuiguy> NfNitLoop: I see your point... in this particular case, there's only one branch right now
[21:31] <NfNitLoop> ah.  Well then you could in theory do it, but my guess is that nobody has bothered to write/distribute code to do so for the above reasons.
[21:32] <james_w> theuiguy: there's nothing specifically for it
[21:32] <james_w> there's two things which could, but don't yet, bzr-rebase and fast-export/fast-import
[21:32] <theuiguy> How about a plugin to merge commits?
[21:33] <james_w> that would probably be the same tool
[21:33] <theuiguy> james_w: I was thinking bzr-rebase might do something like it, but I thought you needed to do it before your commit
[21:34] <james_w> interactive rebase can do the latter, I don't know if that's available yet though
[21:36] <theuiguy> Perhaps you could give me an alternative solution -- I'm told I can open source some code, but need to scrub email addresses that expose internal server names.
[21:36] <theuiguy> It already in bzr, with a relatively short revision history -- I think around 25 revisions.
[21:37] <theuiguy> I suppose I could just create a new branch with the latest code and go from there, but it's a shame to lose the history
[21:39] <james_w> theuiguy: ok, to change that I would suggest bzr-fast-export and bzr-fastimport.
[21:39] <james_w> you can export to a text file, sed the file to clean up the names as you wish, and then import again
[21:39] <james_w> it should work nicely
[21:40] <james_w> but the new branch will have absolutely no relation to the old one in bzr's eyes
[21:40] <james_w> it sounds like that shouldn't be a problem for you though
[21:41] <theuiguy> james_w:  no, that sounds like it would work... just cleaning up the email addresses would be great.
[21:41] <theuiguy> Thanks!
[21:54] <mathiaz> Hi - I'm using the loom plugin to manage one my packaging branch. The HOWTO outlines how-to combine a thread (case where the code has been merged upstream), but I don't get how to delete a thread (the code is no longer relevant because upstream fixed it differently). How do I delete a thread ?
[21:55] <james_w> hey mathiaz
[21:55] <mathiaz> If I try to combine a thread, it still shows up in the thread above
[21:55] <mathiaz> james_w: Hi ! :)
[21:55] <james_w> I believe that's the same thing
[21:56] <james_w> you mean the code that you want to get rid of is still in the thread above?
[21:56] <mathiaz> james_w: I'm working on an openldap merge and the debian maintainer fixed a bug using a different patch
[21:56] <mathiaz> james_w: yes
[21:56] <lifeless> mathiaz: you un merge it
[21:56] <lifeless> mathiaz: go to the thread above and do bzr merge -r -1..thread:
[21:56] <lifeless> erm no
[21:56] <lifeless> go to the thread you want to cancel
[21:56] <lifeless> then do that
[21:57] <mathiaz> lifeless: ok - good to know for the next time. As of now, I've already combine the thread
[21:57] <mathiaz> lifeless: so I guess I'll have to fix it manually
[21:58] <james_w> you can resurrect the thread I assume
[21:58] <james_w> hey lifeless
[21:58] <mathiaz> also pushing the branch to LP doesn't work
[21:59] <mathiaz> I get the following message: http://paste.ubuntu.com/32335/
[21:59] <lifeless> hi james_w
[22:00] <james_w> mathiaz: I think that's fixed if you update your loom plugin to a newer version
[22:00] <mathiaz> james_w: I just did that
[22:00] <mathiaz> james_w: that's when I started to see that message
[22:02] <mathiaz> I'm at revision 86 for the loom pluging
[22:05] <chadmiller> Hi all.  A bzr user in my group complains that "annotate" is much slower in 1.6b4 than in 1.5.  For his example file it goes from 19 sec to 645 sec.
[22:05] <AmanicA> which branch format?
[22:05] <AmanicA>  (bzr info)
[22:10] <lifeless> ah damn I knew I'd forgotten something; get_matching_blocks acceleration
[22:10] <lifeless> chadmiller: I'll whip up a patch today
[22:10] <chadmiller> lifeless: Cool.  Thanks!
[22:11] <rexbron> hey jelmer, I have a new problem related to the bug you looked at earlier
[22:11] <lifeless> chadmiller: make sure he is running with the C extensions though
[22:12] <lifeless> chadmiller: that will still matter even after my patch
[22:12] <chadmiller> Okay.  I will.
[22:14] <mwhudson> mornings
[22:14] <beuno> goooooooood mornin' mwhudson
[22:15] <thumper> beuno: morning
[22:15] <thumper> beuno: I've been trying to marry the gnome-loggerhead with the new trunk
[22:15] <beuno> hey thumper
[22:15] <beuno> oh, cool, I was going to ping you about that
[22:15] <thumper> beuno: with limited success
[22:16] <cszikszoy> does anyone know what this error means: bzr: ERROR: Invalid url supplied to transport: "Host empty in: http://:8080/"
[22:16] <beuno> thumper, that's odd
[22:16] <thumper> beuno: I might push what I have and get you to look where it's screwing up
[22:16] <thumper> beuno: we have mixed css
[22:16] <cszikszoy> or possibly how to fix it?
[22:16] <beuno> thumper, have you changes anything to it, or is it what I originally pushed?
[22:17] <thumper> beuno: and I was trying to fit some loggerhead tabs into the gnome tab area
[22:17] <james_w> cszikszoy: hi, what command did you run to get that error?
[22:17] <thumper> beuno: there are changes
[22:17] <thumper> beuno: but fairly limited
[22:17] <beuno> thumper, ah, ok. If you can push or give me access to, I can resolve and re-push
[22:17] <cszikszoy> bzr branch lp:do-plugins
[22:18] <james_w> mathiaz: how are you finding using loom for packaging?
[22:18] <thumper> beuno: I'll actually spend some time writing up what has changed as ISTR there was some heading hackery
[22:18] <james_w> cszikszoy: oh, that's odd
[22:18] <thumper> beuno: so you might get something in the next 8 hours
[22:18] <thumper> beuno: but not too soon
[22:19] <lifeless> cszikszoy: thats very strange
[22:19] <mathiaz> james_w: well - up to now, I think it's ok - I classify it as yet-another-patch-system - but I like the merge help
[22:19] <cszikszoy> i thought so too :)
[22:19] <lifeless> cszikszoy: it means there is no hosy
[22:19] <lifeless> *host*
[22:19] <mathiaz> james_w: there are still some rough edges (such as unable to push to lp)
[22:19] <beuno> thumper, cool.  Another thing you may want to try, is start from the gnome branch I pushed with the new theme, and merge into that one
[22:19] <mathiaz> james_w: and I've just figured out how to delete a patch rather than combine it
[22:20] <james_w> mathiaz: that's true, I guess it is another patch system, but hopefully a better one.
[22:20] <mathiaz> james_w: hopefully there will such a command added to the loom plugin soon
[22:20]  * thumper nods to what beuno says
[22:20] <frej> hmm, i'm having problems with converting a cvs repo (cvsps) with filenames in latin1 encoding :/
[22:20] <james_w> mathiaz: would you file a bug for that command?
[22:20] <mathiaz> james_w: it seems that the difference comes with the merging support
[22:20] <frej> is this supported in any wya?
[22:20] <james_w> mathiaz: also, "bzr -Derror push" would be useful to find out why you can't push.
[22:20] <lifeless> cszikszoy: cszikszoy it works for me
[22:21] <lifeless> cszikszoy: could you file a bug please, with a transcript? file it on launchpad-bazaar
[22:21] <mathiaz> james_w: there aren't many patch system that come with a proper merge support
[22:22] <beuno> sounds like a proxy tweaking things, doesn't it?  8080 port seems fishy
[22:22] <cszikszoy> i'm not behind any proxy that I know of
[22:22] <cszikszoy> unless my isp blocks it
[22:22] <cszikszoy> i'm in Germany, if it somehow matters
[22:22] <cszikszoy> but i didn't think that it would
[22:23] <james_w> mathiaz: yeah, hopefully it's a killer feature
[22:26] <cszikszoy> i'll file a bug report, as for a transcript, what would be helpful to include?
[22:27] <beuno> cszikszoy, can you re-run the command, and add  -Dhpss
[22:27] <beuno> then, file the bug, attaching your  ~/.bzr.log   file
[22:30] <cszikszoy> will do, thanks
[22:40] <cszikszoy> n
[22:42] <lifeless> I swear
[22:42] <lifeless> time to update my fail filters
[22:45] <jelmer> lifeless: 'morning
[22:46] <lifeless> hi jelmer
[22:46] <jelmer> lifeless: wrt backslashes - bzr will error out when trying to add a file with a backslash in the name
[22:46] <lifeless> yes
[22:46] <lifeless> this is deliberate
[22:46] <lifeless> we also error on 0x01
[22:47] <lifeless> and many other characters
[22:47] <jelmer> you mention encoding - what sort of encoding?
[22:47] <jelmer> (bug 81844)
[22:47] <lifeless> you could urlescape it
[22:47] <lifeless> (for instance)
[22:48] <jelmer> lifeless: that means an opportunity for paths to clash
[22:49] <jelmer> also, it means having to determine which paths were meant to be escaped when pushing back into svn
[22:49] <jelmer> bzr-svn currently just checks for backslashes and raises an exception if it encounters them
[22:49] <jelmer> which works pretty well, except that there are a few rare repositories out there that contain backslashes (the lintian one, for example)
[22:54] <jelmer> lifeless: is there any reason to not support \ other than the fact it means it won't be possible to create a working tree on Windows?
[22:55] <lifeless> so there are two groups of characters that we don't support: Those easy to support but undesirable; and those hard to support
[22:55] <lifeless> things that won't go into xml cleanly, or are separate characters for our disk formats makeup thelatter group
[22:56] <lifeless> For the former group, its mainly that they aren't really consistent with bring a sccs
[22:56] <lifeless> they're more 'be a unix file system'
[22:57] <lifeless> dunno
[22:57] <lifeless> I don't really have a strong opinion
[22:59] <james_w> http://technomancy.us/113
[23:01] <lifeless> cool
[23:05] <lifeless> jelmer: does the file id limit matter to you as well ( the \\ is banned in ids because it would break on windows with early stores)
[23:07] <jelmer> lifeless: no, file ids are generated using a checksum if they contain certain characters or exceed a certain limit
[23:08] <lifeless> ok
[23:09] <jelmer> lifeless: the only two characters in filenames I'm aware of that are problematic when importing from svn are \ and newline
[23:54] <lifeless> jml: bit strange to close 124570 if I can't actually use it yet...