[00:18] <garyvdm> igc: I would like to recommend that you reuse the error handling infrastructure from qbzr in bzr-explorer.
[00:19] <garyvdm> I'll put the details in a mail.
[00:19] <igc> garyvdm: do you mean something more than the try/except at the app level?
[00:19] <igc> garyvdm: thanks
[00:20] <garyvdm> Yes - you need a sys.excepthook to catch everything.
[00:20] <jml> lalala, releasing bazaar
[00:28] <garyvdm> igc: No mailing list for bzr-explorer :-(
[00:28] <garyvdm> Can I create one?
[00:30] <igc> garyvdm: sure. Another option is the bzr-desktop mailing list I proposed a few weeks back (but I don't recall getting feedback on)
[00:30] <garyvdm> Ok
[00:40] <garyvdm> igc: is it ok to import from qbzr in bzr-explorer?
[00:42] <igc> garyvdm: absolutely. explorer reuses lots of stuff from qbzr including i18n support
[00:42] <garyvdm> igc: cool
[00:50] <garyvdm> igc: Did you go on vacation? How was it?
[00:51] <igc> garyvdm: restful thanks
[00:51] <garyvdm> Thats good!
[00:51] <igc> garyvdm: being the middle of Winter here, we had the beach pretty much to ourselves :-)
[00:51] <jml> Installed Bazaar version 1.16.1 is too old to be used with plugin
[00:51] <jml> "Bzrtools" 1.17.0.
[00:51] <jml> :(
[00:52] <jml> I guess I'd better get releasing
[00:52] <jml> igc, welcome back!
[00:52] <igc> hi jml - thanks!
[00:55] <fullermd> Seems like everybody makes that mistake on their vacation...   it's all going so well, and then they end it.
[01:03] <igc> fullermd: indeed
[01:04] <jml> I don't see anything in the NEWS file about fixing 2a bugs.
[01:04] <jml> there are quite a few nice performance things though.
[01:04] <fullermd> igc: Quick!  Uncommit leaving the beach before you get more revs on top of it!
[01:14] <jml> HPSS calls: 45 (17 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
[01:14] <jml>  :\
[01:14] <spiv> jml: which operation?
[01:14] <jml> spiv, pushing a new, stacked 2a branch
[01:15] <spiv> Ah ok.
[01:15] <lifeless> with tags?
[01:16] <jml> yeah, one tag.
[01:16] <jml> without (new) tags is HPSS calls: 43 (17 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
[01:17] <lifeless> whats the backtrace of the vfs trigger?
[01:17] <lifeless> or, have we landed the patch that disables that :(
[01:18] <jml> there are two of them.
[01:18] <lifeless> (I really think folk should either not care about hpss calls, or care about vfs triggers)
[01:18] <igc> hi lifeless, spiv
[01:18] <spiv> igc: good morning!
[01:19] <jml> http://paste.ubuntu.com/216536/
[01:19] <spiv> Yeah.  tags causing vfs calls is pretty high on my hit list.
[01:19] <lifeless> spiv: are you open to being convinced to keep vfs triggers tied to -Dhpss?
[01:20] <spiv> lifeless: no, not really
[01:20] <spiv> lifeless: they irritate *me* :)
[01:20] <spiv> lifeless: but more importantly, it means that other people have started turning off -Dhpss
[01:20] <jml> why are they displayed, rather than logged?
[01:21] <RenatoSilva> how to list the remebered locations?
[01:21] <spiv> So if someone on the launchpad-dev team gets unexpected bad performance, and I ask for the -Dhpss log, they'll have to re-run the slow, painful operation before they can give me an answer.
[01:22] <spiv> Which is I think is a net loss compared to making the vfs triggers in-your-face.
[01:22] <lifeless> spiv: are they still logged to ~/.bzr.log with the patch that stopped showing them?
[01:23] <lifeless> spiv: because I think its still a net loss if we don't get the trigger
[01:23] <spiv> lifeless: I'm not sure, poolie did that patch.  I'm fine with them still being logged.
[01:23] <spiv> (even though that makes debugging test failures more irritating, that only really affects me)
[01:27] <jml> RenatoSilva, 'bzr info'
[01:27] <RenatoSilva> jml: thanks
[01:27] <ircleuser> Hi I just installed Bazaar and in the $HOME/.bazaar directory the only file is "ignore"
[01:27] <lifeless> jml:  please file two bugs
[01:27] <jml> spiv, lifeless: anyway, I only mention it because it's something of a regression from the glory days of 8 or 9 hpss calls & no vfs ops.
[01:28] <lifeless> jml: a) your scenario writes tags twice
[01:28] <lifeless> jml: b) writing tags causes _ensure_real
[01:28] <spiv> jml: yeah.  life was better when bzr.dev had no tags ;)
[01:28] <jml> lifeless, the pasted stack traces were from pushing a branch that has no new tags.
[01:28] <ircleuser> I was expecting bazaar.conf - any ideas what causes this?
[01:28] <spiv> jml: no new tags != no tags, unfortunately.
[01:29] <jml> (and the branch was launchpad)
[01:29] <garyvdm> ircleuser: If you do bzr whoami "User Name <user@tld.com>" it will create it.
[01:30] <jml> spiv, wow, that sucks.
[01:30] <garyvdm> Ebro ^^^
[01:30] <mwhudson> jml: pushing a new launchpad branch has never had no vfs ops
[01:30] <jml> mwhudson, really? maybe it was only 1 or 2 then
[01:30] <Ebro> sweet! Thanks!
[01:30] <mwhudson> jml: pushes between existing branches are still 0 vfs
[01:31] <mwhudson> (i think, anyway)
[01:31] <jml> mwhudson, nope
[01:31] <mwhudson> oh
[01:31] <jml> $ bzr push lp:~jml/launchpad/test-branch-47-2
[01:31] <jml> No new revisions to push.
[01:31] <jml> HPSS calls: 14 (2 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
[01:31] <lifeless> jml: please file the bugs ;)
[01:32] <jml> lifeless, yeah, that's what I'm doing.
[01:32] <jml> although they'll probably be crappy bugs.
[01:33] <mwhudson> jml: pull is 0 vfs at least, it seems
[01:33] <mwhudson> anyway, i'm not here right now
[01:36] <spiv> jml: there's a cheap optimisation in push atm where if you have 0 local tags it doesn't even need to read the remote tags, let alone write any tags.  But as soon as there are any tags that obviously doesn't work...
[01:40] <jml> spiv, makes sense
[01:56] <poolie> hello
[01:58] <lifeless> hai
[02:00] <poolie> karmic is booting again, yay :)
[02:10] <lifeless> poolie: your patch to mute -Dhpss on vfs events
[02:10] <lifeless> poolie: does it make the trace get logged to ~/.bzr.log?
[02:11] <poolie> it moves the existing code to a different debug flag
[02:11] <poolie> so if it was not unconditionally logging them before, it's not doing it now
[02:11] <lifeless> poolie: I would like, and I think spiv would do, if someone has -Dhpss, those events should get captured *somewhere*
[02:12] <poolie> why not just set the other flag?
[02:12] <lifeless> poolie: because otherwise they have to reproduce the event
[02:12] <poolie> who?
[02:12] <lifeless> the person reporting
[02:12] <lifeless> the reason we added that flag was to get more data in bug reports
[02:12] <poolie> so we're talking about people who do have hpss set in their config options?
[02:12] <lifeless> yes
[02:12] <poolie> but they can't be told to set the other flag?
[02:13] <poolie> well, ok
[02:13] <lifeless> setting the other flag means they have to reproduce it again
[02:13] <lifeless> rather than grabbing their log and attaching
[02:13] <poolie> i can see a lot of lp people probably do have Dhpss set, and it would be annoying to do it all over again
[02:13] <poolie> i don't really object, please yourself
[02:14] <lifeless> ok
[02:14] <poolie> it's just that spewing it to stderr was way too much
[02:14] <lifeless> I did that on the basis that noone would have Dhpss set unless they were working on the network stack
[02:14] <poolie> yeah
[02:14] <lifeless> however it seems we have a bunch of voyuers ;)
[02:14] <poolie> a reasonable assumption but not actually true :)
[02:14] <poolie> i like having it on for background awareness
[02:15] <poolie> 'care about networking' is not precisely 'working on networking right now'
[02:15] <lifeless> its kind of like the big display in  windows defrag programs
[02:16] <poolie> hm
[02:16] <spiv> Perhaps we have voyuers, but also we frequently ask bug reporters and psuedo beta testers (like people on the lp team) to use it.
[02:16] <poolie> maybe a bit more useful than that
[02:16] <poolie> like i did actually use the trace while testing stacking against launchpad to see what it was doing
[02:17] <lifeless> spiv: sure, the point is that if they have it set by default rather than on-request.
[02:17] <poolie> but that's not the same as looking for new things to fix
[02:17] <lifeless> spiv: I'm not arguing against the change thats been made; I'm arguing for capturing sufficient data in a reasonable place.
[02:17] <spiv> lifeless: right.
[02:17] <poolie> actually maybe that's the difference, are you looking for trouble in the sense of open to being told about new things to improve
[02:17] <poolie> anyhow by all means capture it
[02:17] <poolie> even capture it unconditionally if you like
[02:18] <poolie> two other ideas re bug reporting:
[02:18] <poolie> one is, maybe we should record the reason why plugins failed to load and show it from 'bzr plugins'
[02:18] <poolie> at least the actual error message
[02:18] <poolie> i think at the moment failed ones are not shown at all
[02:18] <lifeless> I think of the VFS trace as being the same as the HPSS trace; they are both showing whats going on. I appreciate that the noise was too much
[02:19] <poolie> and as a further step maybe don't show anything to stderr, just put it in there
[02:19] <poolie> and the second was, maybe have a global weak dict of open repositories etc
[02:19] <poolie> and show it in the error reporting tb
[02:19] <poolie> so we don't need to go back and ask for bzr info
[02:19] <poolie> hm
[02:19] <poolie> possibly that could be subsumed by just getting a full traceback through something like apport
[02:20] <lifeless> I'm not keen on the word global there
[02:21] <lifeless> I like the idea about plugins
[02:22] <poolie> i guess rather than being global we could look for things on the relevant stack
[02:24] <poolie> i might file a bug for that at least then
[02:24] <poolie> spiv, how's your stuff today?
[02:47] <poolie> thanks for the knockon errors review
[02:47] <RenatoSilva> what was that prefix you put in bzr selftest <?>:plugin ?
[02:47] <RenatoSilva> bzr selftest -s <prefix>:plugin
[02:54] <lifeless> foodink
[03:03] <lifeless> back
[03:04] <jelmer> mwhudson: hi
[03:04] <mwhudson> jelmer: hi
[03:04] <mwhudson> jelmer: i was going to ask about the python2.4 subvertpy bug
[03:11] <poolie> hello jelmer
[03:13] <igc> hi poolie, jelmer
[03:16] <jelmer> 'moin mwhudson, poolie, igc
[03:16] <jml> g'day jelmer
[03:17] <jelmer> hey jml
[03:17] <lifeless> hi jelmer
[03:17] <jelmer> lifeless: hi
[03:17] <jelmer> mwhudson: Not much news yet, but I'm pretty sure I'll have it fixed before the end of the week
[03:19] <jml> I've made this diff after merging the 1.17 branch into trunk: http://paste.ubuntu.com/216582/
[03:19] <jml> can someone quickly sanity check that for me
[03:19] <jml> please
[03:19] <lifeless> .
[03:19] <lifeless> .
[03:20] <lifeless> looks good to me
[03:20] <jml> thanks.
[03:20]  * jml pqm-submits
[03:21] <spiv> poolie: good, I have literally only two issues left on my todo list for the inventory-deltas streaming branch.
[03:21] <poolie> cool
[03:23] <spiv> poolie: 1) two tests failing with pack already exists error when an autopack happens on a 2a repo (maybe bug 382463 ?), 2) making a new get_stream verb so that old clients won't receive inventory-delta records they can't handle (and arrange for deltas not to be streamed via the old verb, of course).
[03:24] <spiv> Oh, and I'd like to do a bunch of manual testing, but that can happen concurrently with the code being reviewed.  Once I fix 2) I'll make the merge proposal.
[03:25]  * igc lunch
[03:50] <lifeless> spiv: 382463 occurs on fully packed repos
[03:50] <lifeless> spiv: it shouldn't ever happen on autopack
[03:51] <lifeless> spiv: do you perhaps have an empty pack?
[03:51] <lifeless> thats unlikely as we have guards for it
[03:51] <lifeless> spiv: also we want to push verbs
[03:52] <lifeless> spiv: sorry rephrasing. Could you add 3) a new insert_stream verb, please.
[03:53] <spiv> I don't think the pack is empty, as the name changes from test run to test run, which implies content.
[03:53] <lifeless> ack
[03:53] <spiv> It's triggered by the self.target_repo.pack call in _locked_insert_stream
[03:53] <lifeless> oh
[03:53] <lifeless> I bet I know
[03:54] <lifeless> you've one stream right?
[03:54] <lifeless> and a new repo?
[03:54] <spiv> If you grab lp:~spiv/bzr/inventory-delta and selftest test_fetch_parent_inventories_at_stacking_boundary_smart you'll see it.
[03:54] <lifeless> spiv: I'll give you a couple of hints now. If they don't help ping me later and I'll push stack and look at it with you
[03:55] <lifeless> I suspect the following conditions are occuring:
[03:55] <lifeless>  - you upload a single pack
[03:55] <spiv> Off the top of my head, I think one stream + new repo is true.
[03:55] <lifeless>  - the pack is sufficiently simple that the sort order for its contents are the same as the upload order happened to generate
[03:56] <lifeless>  - the group splitting heuristics happen to line up at the same boundaries
[03:56] <spiv> It's also likely that this is a code path that wasn't being hit before (because InterDifferingSerializer was covering this case).
[03:56] <lifeless> -> collision, with the same content.
[03:56] <lifeless> so this is natural.
[03:56] <spiv> Yeah.
[03:56] <lifeless> some possibilities to avoid id:
[03:56] <spiv> FWIW, if I replace the raise with a return the offending tests are happy.
[03:57] <spiv> (unsurprisingly)
[03:57] <lifeless>  - deliberately send in a slightly different order, to force the pack to do it in a different order
[03:57] <lifeless>   (ugh)
[03:57] <spiv> Yeah, I don't like the sound of that one.
[03:57] <lifeless>  - fix the long standing 'genuine collisions error rather than checking the content is the same' bug
[03:58] <lifeless>    (note that this needs to also check the indices are the same, I *think* the bug notes that)
[03:58] <spiv> That sounds like the right fix, but I'd be happy for someone else to do it ;)
[03:59] <lifeless>  - make the pack(hints...) method pass a flag down that means the repo can recognise that it just repacked pack FOO and got FOO and back it out rather than actually replacing at all.
[03:59] <lifeless> I think the third will perform best
[03:59] <spiv> Hmm.
[04:00] <spiv> Can you elaborate on that third option?
[04:00] <spiv> I'm not really sure what the hint does (I haven't dug very deeply into this yet).
[04:00] <lifeless> the hint says 'repack these specific packs'
[04:01] <spiv> I think it's just a "hey I just added this new data, so just focus on packing that bit" arg?
[04:01] <lifeless> its allowed to be ignored if the repo can't do partial packs or whatever.
[04:02] <spiv> Ok, thanks.
[04:03] <lifeless> Doing that pack-with-hints is what stops a delta inserted into a 2a repo from being GB's in size ;)
[04:15] <spiv> lifeless: btw, the branch already adds a new insert_stream verb.
[04:15] <lifeless> spiv: cool
[04:15] <lifeless> spiv: scratch 3) then :P
[04:29] <poolie> hey spiv
[04:29] <poolie> thanks for the update
[04:31] <mwhudson> jelmer: cool
[04:32] <mwhudson> jelmer: it looks like launchpad on 2.5 is going to take a little longer than we would like, so fixing the bug would be really nice :)
[04:32] <lifeless> \o/ 24/27 inventories fail to error when the path is mismatched with the parent id
[04:56] <GungaDin1> How can I check what revision I'm on in a branch?
[04:57] <lifeless> bzr revno
[04:57] <GungaDin1> thx
[05:19] <igc> bbiab
[05:45] <igc> jml: when adding the empty sections to NEWS at the start of a release, ...
[05:45] <igc> I think "Internals" belongs later, e.g. after "API Changes"
[05:46] <jml> igc, I think you're right.
[05:46] <igc> jml: I'm about to tweak and land the Upgrade Guide
[05:46] <igc> jml: so I'll tweak that while I'm at it
[05:46] <jml> igc, thanks.
[05:46] <jml> the 'releasing' guide should be updated to say 'add empty sections to the NEWS file' and probably should include a template for doing so.
[05:46] <jml> I'll file a bug for that.
[06:14] <poolie> hello igc, welcome back!
[06:14] <poolie> well done on the release jono
[06:14] <poolie> and welcome back too
[06:14] <igc> hi poolie!
[06:15] <poolie> lifeless: intercepting http proxies are not the answer, 'no' is the answer :)
[06:20] <jml> lifeless, where's your whitepaper on interface testing?
[06:20] <jml> poolie, thanks.
[06:27] <jml> pygi, g'day
[06:28] <pygi> good morning jml :)
[06:34] <lifeless> jml: I should update. Its on people.ubuntu.com.
[06:34] <lifeless> poolie: they may be the cause though :P
[06:35] <jml> lifeless, I find myself having to describe the concept increasingly often. An updated version would be nice.
[06:36] <lifeless> jml: its time has come!
[06:36] <lifeless> I want to add prose about balancing costs and fragility
[07:09] <lifeless> ok, EOD for me, a bit late (don't ask when I started :P)
[07:10] <lifeless> currently fixing tree.apply_inventory_delta to not corrupt dirstate with duplicate file ids.
[07:18] <vila> hi all
[07:23] <poolie> hello vila
[07:23] <poolie> writing a post about 2.0 and beyond
[07:23] <vila> great
[08:39]  * igc dinner
[09:21] <anywho> is it possible to do a diff against the previous revision without knowing the revision number? like something like bzr diff -r -1 ?
[09:22] <mwhudson> yes
[09:22] <mwhudson> but -r -1 means the most recent revision
[09:22] <mwhudson> anywho: you probably want diff -r -2
[09:22] <mwhudson> (that'll be the difference between the most recent but 1 commit and the tree as it is now)
[09:24] <anywho> that works but so what is the purpose of -1 in this case? it would never work, right?
[09:36] <vila> anywho: It will show you the difference between the last committed revision and your working tree, i.e. the changes that are not yet committed
[09:38] <Kinnison> anywho: Basically -1 == HEAD
[09:38] <anywho> got it
[09:39] <anywho> thanks
[09:48] <poolie> good night all
[10:21] <sabdfl> night poolie
[13:27] <awmcclain> Anyone know why branch we create on our remote repository are created without group write? I have umask 022 in my /etc/profile, am I missing something?
[13:27] <awmcclain> *branches
[13:32] <AfC> awmcclain: 1) maybe you meant umask 0002 and 2) you probably want sticky group bit on the remote repo directory?
[13:32] <awmcclain> AfC: Yeah, I _just_ realize that about the umask, and the sticky bit is set.
[13:33] <awmcclain> Thank you.l
[13:33] <awmcclain> realized.
[13:33] <awmcclain> Ug, one of those typing days.
[13:34] <awmcclain> Hrm... do I need to restart a daemon for that /etc/profile change to happen?
[13:38] <awmcclain> Hrm... no, i have umask set to 0002 now, and I'm still getting the same permissions problems.
[13:46] <awmcclain> Does bzr not use /etc/profile?
[13:58] <maxb> awmcclain: It is not bzr's job to use or not use /etc/profile. That is up to the shell
[13:59] <awmcclain> maxb: Ubiquitous!
[13:59] <maxb> :-)
[14:00] <awmcclain> maxb: So, PAM is...what, a kernal module? My linux-fu is quite poor, I'm unfamiliar.
[14:01] <Kamping_Kaiser> pam came from solaris ;)
[14:04] <awmcclain> maxb: So, if I'm reading the man page correctly, I'm going to add a line to my /etc/pam.d/login to alter the umask?
[14:27] <maxb> awmcclain: Doubtful that "login" has anything to do with ssh-based connections
[14:35] <LeoNerd> login  is for the 'login' binary.. which is used by getty et.al. for virtual consoles
[14:38] <Kinnison> If you're using ssh+bzr or bzr+ssh or whatever it's called, then surely it's up to your shell's non-interactive startup to set umask?
[14:50] <jam> morning all
[14:57] <homy> Hi! With which bzr command can I find out which files in the Working tree are version-controlled?
[15:02] <Tak> homy: bzr ls --versioned ‽
[15:05] <maxb> wow, it's not often you see an interrobang used in conversation :-)
[15:06] <homy> Talk: thanks.I didn't find that in the Bazaar User Guide http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html.
[15:07] <Tak> maxb: it is when I'm around :-P
[15:10] <abeaumont_> i want to create a branch from a repo that includes all but some intermediate revisions, e.g., r1..100 and r105..200, which is the best way to do it?
[15:10] <abeaumont_> s/best/proper/
[15:51] <Tak> abeaumont_: branch in the normal way, then merge out those revisions?
[15:51] <Tak> or maybe branch the first revision group, then merge in each successive group
[17:29] <Adys> Hi all. Is there a mailing list where I can post a feature proposal (and possibly work on it)?
[17:32] <Milo-> Any launchpad staff here at the moment? I have a question that regards launchpad ignoring my mail address during registration
[17:39] <amanica_> Adys: there is just the main development mailinglist: https://lists.ubuntu.com/mailman/listinfo/bazaar
[17:40] <Adys> amanica_: is it better to write a blueprint about it, or an email first?
[17:40] <amanica_> Adys: maybe mail first
[17:40] <Adys> Ok
[17:41] <amanica_> Adys: sometimes feature requests are submitted as wishlist bugs, but blueprints sounds better
[17:41] <amanica_> Adays: btw. put [RFC] as the start of your mail
[17:41] <amanica_> subject
[17:41] <Adys> Ok, thanks a lot :) Ill send it tonight
[17:41] <amanica_> cool
[17:50] <SamB> jelmer: you have an interesting definition of "four"
[18:00] <jelmer> SamB: hmm?
[18:09] <SamB> jelmer: bzr-svn also adds four new commands to Bazaar:
[18:09] <SamB>  - bzr svn-import
[18:09] <SamB>  - bzr svn-layout
[18:09] <SamB> For more information about bzr-svn, see the bzr-svn FAQ.
[18:09] <jelmer> oh, right
[18:09] <jelmer> two were integrated into bzr
[18:10] <jelmer> SamB: fixed, thanks
[18:11] <SamB> hmm, you might want to mention those on that page because they're probably particularly useful for SVN repositories?
[18:12] <LarstiQ> jelmer: I'm trying to narrow an exception down in bzr-svn that occurs on our repo if you start without a cache
[18:13] <LarstiQ> jelmer: I think it is because layout.get_tags(self, from_revnum, project) returns []
[18:13]  * LarstiQ files bug with traceback
[18:15] <Adys> amanica_: Ok. sent the mail. I gotta run for a couple of hours now. thanks again :)
[18:17] <LarstiQ> jelmer: bug 398908
[18:19]  * LarstiQ prepares to go home
[18:20] <jelmer> LarstiQ: is this also with current bzr-svn ?
[18:21] <jelmer> LarstiQ: since I fixed an issue like that recently
[18:21] <jelmer> LarstiQ: yeah, I'm pretty sure this one is fixed
[18:22]  * LarstiQ checks
[18:22] <kfogel> What's ETA for 1.17, or is that an annoying FAQ that does not have an answer?
[18:23] <jelmer> kfogel: Usually the release manager posts a timeline for the release cycle before it starts, not sure if that happened for 1.17
[18:23] <LarstiQ> jelmer: timemachien yay :)
[18:23] <jelmer> kfogel: I can't find anything, but usually it's about a week or so after the rc
[18:24] <jelmer> kfogel: barring any release critical bugs that would require a new rc
[18:24] <jelmer> SamB: They just happened to be commands that were hard to integrate into Bazaar, I don't think that's a valid reason for listing them there.
[18:25] <kfogel> jelmer: right
[18:25] <jelmer> SamB: for the record, these two commands were svn-push and svn-set-revprops (now: push and reconcile)
[18:25] <SamB> jelmer: ah.
[18:26] <SamB> svn push doesn't really need listing there, true
[18:26] <LarstiQ> jelmer: was that revno 3097?
[18:26] <SamB> and I guess reconcile neither
[18:27] <SamB> though I'd never have guessed that it altered revprops in the SVN repository -- you do have that in the FAQ somewhere?
[18:27] <SamB> and I'm also not sure how svn push works when you've a complicated tangle of Bzr revisions to push -- what branches do they all get pushed on?
[18:30] <LarstiQ> jelmer: applying 3097 to 0.6.2 fixes it for me, cheers!
[18:55] <jelmer> SamB: it does a similar thing to what reconcile does in bazaar repositories - fix revision metadata; in this case that revision metadata happens to be stored in revisin properties
[18:57] <hsn_> why bzr st sometimes reports file names with '*' at end? it breaks my scripts
[19:08] <verterok> hsn_: * means a change in the executable bit
[19:27] <Skoorbulous> Hi all. I am new to bzr and have a basic question: I have a branch that I have run the "bind" command on to convert to a checkout, but when I got to try to edit a file it is locked.
[19:28] <Skoorbulous> What is the correct process to follow so my branch is unlocked and editable?
[19:28] <Skoorbulous> thanks
[19:28] <LarstiQ> Skoorbulous: could you provide a bit more information?
[19:29] <Skoorbulous> It is a website and I am trying to starty with a simple bzr model whereby I simpy bind a branch to convert to checkout, make edits, unbind, commit
[19:30] <Skoorbulous> not sure if that makes sense but I do not want to create a whole local copy of it to make changes
[19:31] <LarstiQ> Skoorbulous: what specifically do you mean with 'it is locked'?
[19:32] <Skoorbulous> it is locked by root so when I try to edit it with a text editor it tells me I do not have write priveleges
[19:32] <Skoorbulous> I thought that bzr probably locked everything up
[19:33] <LarstiQ> Skoorbulous: could you please pastebin a transcript of the command you run and it's output? (http://pastebin.com)
[19:34] <Skoorbulous> I am trying to edit with a text editor on my mac - so there is not really a command that I can paste
[19:34] <LarstiQ> Skoorbulous: as is you are leaving out the information from which to determine what is going on
[19:34] <LarstiQ> Skoorbulous: and this text editor has bzr integration?
[19:34] <LarstiQ> Skoorbulous: or what is the message it comes up with?
[19:34] <Skoorbulous> no its just a standard text editor. Can I not use standard software to edit my files if I use bzr?
[19:34] <SamB> jelmer: wow, SVN uses a dumb protocol ...
[19:34] <LarstiQ> Skoorbulous: are you just having regular unix permission problems?
[19:35] <LarstiQ> Skoorbulous: yes you can, but now I think your issue has nothing to do with bzr
[19:36] <Skoorbulous> It says "Are you sure you want to unlock entry.php that doucment is owned by "root""
[19:36] <jelmer> SamB: ?
[19:36] <Skoorbulous> I did not have permission problems until just now when I added bzr
[19:36] <SamB> jelmer: oh, maybe it's not quite as dumb as it looks ... but this server is being silly, at least:
[19:37] <SamB> Transfer-Encoding: chunked
[19:37] <SamB> Content-Type: text/xml; charset="utf-8"
[19:38] <LarstiQ> Skoorbulous: well, why is entry.php owned by root?
[19:39] <Skoorbulous> I guess I must have been in root when I added the directory to bzr - would that have done it?
[19:40] <SamB> hmm, I wonder why the SVN client doesn't send an Accept-Content-Type header?
[19:41] <LarstiQ> Skoorbulous: I wouldn't think so
[19:41] <Skoorbulous> hmm
[19:42] <Skoorbulous> thanks for your help - this is a stupid question, but how do I convert everything back to ownership by a different user?
[19:42] <SamB> jelmer: I don't suppose it would be possible for bzr-svn to pipeline it's requests?
[19:43] <jelmer> SamB: it is, see the bug report about replay in bzr-svn's bugtracker
[19:43] <SamB> ah
[19:43] <SamB> that's nicer than I somehow expected
[19:44] <SamB> though it's obviously feasible from the protocol POV, at least for the HTTP protocol
[19:45] <SamB> !bugs bzr-svn
[19:45] <SamB> aww.
[19:45] <LarstiQ> Skoorbulous: chown user -R
[19:45] <jelmer> SamB: https://launchpad.net/bzr-svn/+bugs
[19:45] <SamB> jelmer: ah, thanks
[19:45] <SamB> would be nice to have a bot command for that or something though ;-)
[19:45] <jelmer> SamB: svn isn't "standard" http, it uses REPORT to fetch revision delta's
[19:46] <SamB> jelmer: I can see it does that
[19:46] <SamB> I just happened to catch some of it's requests in wireshark when I was looking for something else
[19:49] <RenatoSilva> any bzrtools deveoper here?
[19:49] <SamB> jelmer: afaik, HTTP pipelining is possible iff you can make multiple requests on one connection, and that's sure what seems to be happening here
[19:49] <RenatoSilva> s/eo/elo
[19:49] <jelmer> SamB: sorry, I should rephrase. with replay pipelining should not be necessary afaik
[19:51] <SamB> jelmer: ah
[19:53]  * SamB wishes he could profile bzr-svn's heap traversal ...
[19:53]  * jelmer wishes he could, too
[19:54] <SamB> I would think it had a space leak if it didn't keep swapping that stuff back in
[19:55]  * SamB wonders how impossible it would be to actually implement such a thing
[19:55] <SamB> I mean, it's not actually impossible
[19:56] <SamB> ... you could do something with valgrind ...
[19:56] <hsn_> verterok: it breaks bzr-eclipse too
[19:56] <SamB> (in a new skin, of course)
[19:59] <verterok> hsn_: ?
[19:59] <SamB> ... but you might need to hook Python's allocators in some fairly nasty ways to get memory objects sufficiently segregated to actually notice when one is used for the first time in a while
[19:59] <amanica_> Adys: cool, I saw. I like your idea and am also tempted to contribute.
[19:59] <verterok> hsn_: a change in the executable bit?
[19:59] <jelmer> SamB: yes
[20:00] <SamB> I guess whatever cachegrind's approach is would allow doing it without allocating each Python object on it's own 4k page, at least
[20:02] <SamB> of course, you'd also want to take snapshots of the arrangement of the heap like that tool that was introduced on the bzr list...
[20:03] <SamB> hmm. you might need to deactivate/delay deallocation due to refcounts reaching zero, too ...
[20:03] <SamB> (I assume Python still has refcounts?)
[20:04] <jelmer> yeah, ther'es refcounts
[20:05] <SamB> ... otherwise, you'd not be able to get any sense out of accesses to objects that were both allocated and deallocated between one snapshot and the next ...
[20:08] <SamB> ... I guess you'd probably want to deactivate the access logging while running the cycle collector, too
[20:13] <LarstiQ> SamB: CPython does
[20:13] <LarstiQ> Skoorbulous: did that help
[20:13] <LarstiQ> Skoorbulous: ?
[20:14] <SamB> LarstiQ: yeah, I was talking about CPython
[20:14] <SamB> using valgrind to profile a program running under Jython would probably be rather useless
[20:14] <LarstiQ> SamB: there are way more Python implementations than those two :)
[20:15] <SamB> or PyPy, or IronPython, or ...
[20:15]  * LarstiQ nods
[20:15] <LarstiQ> personally I need/want to look at Stackless soonish
[20:15] <SamB> guess I should have used an 'e.g.'
[20:16] <SamB> I think Stackless doesn't really count as different from CPython for my purposes
[20:16] <SamB> I mean, about the profiling thing
[20:16] <LarstiQ> fair enough
[20:17] <LarstiQ> SamB: so how about that bzr memory profiler you mentioned earlier? That has worked for us
[20:18] <SamB> LarstiQ: I just want to see what bzr-svn is keeping so much stuff in RAM for
[20:19] <SamB> and, worse, apparantly using it
[20:19] <LarstiQ> SamB: then I can recommend it
[20:19] <jelmer> SamB: which version of bzr-svn is this specifically?
[20:19] <SamB> jelmer: did you improve it recently wrt that?
[20:20] <jelmer> SamB: yeah
[20:21] <SamB> what was the issue caused by?
[20:21] <jelmer> multiple copies of a file kept in memory
[20:23] <SamB> how recently?
[20:23] <SamB> oh, and why did you remove the branching schemes help topic?
[20:25] <SamB> oh, apparantly I had the latest code before I told you about that incorrect use of "four" in the help
[20:25] <SamB> ... no, wait
[20:25] <jelmer> SamB: it was fixed since 0.6.2
[20:25] <SamB> confusingly, bzr pull -v lists changes *in order*
[20:25] <SamB> not reverse order as one would expect
[20:26] <jelmer> SamB: I removed the branching scheme help topic because it's only relevant for people who are doing interoperability with bzr-svn 0.4.x
[20:26] <jelmer> SamB: and there's no way to hide help topics in bzr atm
[20:26] <SamB> jelmer: eh?
[20:27] <jelmer> SamB: ?
[20:27]  * SamB reads the patch ...
[20:27] <SamB> jelmer: oh, how do you find branches now?
[20:28] <jelmer> SamB: repository layouts
[20:28] <SamB> jelmer: oh!
[20:29] <SamB> missed the part where there were too versions of the concept with different names
[20:29] <SamB> ;-)
[20:29] <jelmer> well, it's not exactly the same concept
[20:29] <SamB> well, no
[20:29] <SamB> I did say "versions"
[20:30] <jelmer> right, sorry
[20:30] <SamB> er. and I should have said "two" rather than "too", shouldn't I have ;-)
[20:31]  * SamB is relieved, considering that he had to put something in .bzr to get anything sensible for the repository that contains PuTTY 
[20:34] <SamB> jelmer: oh, speaking of which, it might be usefull if you would do full globbing of branch paths in ~/.bazaar/subversion.conf
[20:34] <SamB> you know, with ? and [abc] in addition to *
[20:39]  * SamB wonders if the japanese have a wide copyright symbol ...
[20:40] <SamB> ... nuts. they don't seem to :-(.
[20:43] <SiDi> Hello people
[20:43] <SiDi> Does anyone know if there are IRC commit bots for bzr branches hosted on LP, by chance ?
[20:49] <SamB> jelmer: hmm, bzr doesn't much like being killed mid-branch, does it?
[20:49] <RenatoSilva_> verterok: hi
[20:50] <Adys> amanica_: cool, glad to hear :) if you got any suggestion do tell on the mail
[20:50] <verterok> RenatoSilva_: hi!
[20:51] <amanica_> Adys: ok, hope I get round to it
[20:56] <RenatoSilva_> verterok: hi, I've sent you a replacement for the log view fix. The fix was generalized to solve another problem, the one I thought it was related to JSDT. I also added another fix to iirc revno which was sending a non-ascii file:// URL to bzr which was causing an error in error view. These changes are in my branch bzr-java-lib/encoding-fixes. I also changed xmoutput's code to make xmlannotate work with non-ascii paths (this is
[20:56] <RenatoSilva_> verterok: This change is in bzr-xmlouptut/encoding-fixes (which was previously merged).
[20:56] <verterok> RenatoSilva_: oh, cool!
[20:57] <verterok> RenatoSilva_: I'll take a look to the merge proposal(s) tonight
[21:05] <Skoorbulous> LarstiQ: I tried the chmod -R * and it still reports that the files are owned by root
[21:05] <RenatoSilva_> verterok: I detected the xmlannotate issue while running bzr-eclipse tests. Now there are only 3 test failures, all regarding path comparison. The one expected is like a\b\c but it is returned a/b/c. As they're not literal values, I wasn't sure about which one was correct so that I could try fixing it. So I'm just telling you.
[21:06] <LarstiQ> Skoorbulous: you did supply the correct user to chown to?
[21:06] <verterok> RenatoSilva_: bzr-eclipse or bzr-java-lib?
[21:06] <RenatoSilva_> verterok: sorry, bzr-java-lib
[21:06] <LarstiQ> Skoorbulous: oh, and chown, not chmod
[21:06] <LarstiQ> Skoorbulous: so, in my case: `chown larstiq -R .`
[21:07] <verterok> RenatoSilva_: oh, ok. I'll take a look to the while doing the review
[21:08] <RenatoSilva_> verterok: there are some test failures in xml-output too. One tries to find a python/executable entry in xmlversion, however in my case it is returned a python/dll (bzr built-in)
[21:08] <verterok> RenatoSilva_: oh, bzr.exe, right?
[21:09] <verterok> RenatoSilva_: I'll change the test to be bzr.exe friendly
[21:10] <RenatoSilva_> verterok: It was like assertEquals(1, count(pythn/executable)), then I tested a change...
[21:10] <verterok> RenatoSilva_: could you file a bug about this and the failing tests in bzr-java-lib? that will help us to keep track of this issues
[21:10] <RenatoSilva_> verterok: assertEquals(1, count(python/executable) + count(python/dll))
[21:10] <RenatoSilva_> verterok: the other failure is an XML parser error for a weird non-sense non-ascii char inside the output of some command (I can't recall which one)
[21:11] <RenatoSilva_> verterok: I couldn't find where that char came from, it didn't even make sense in the XML
[21:12] <verterok> RenatoSilva_: weird... if you can reproduce the error, please save the traceback
[21:12] <RenatoSilva_> verterok: let me see
[21:13]  * SamB wonders if bzr branch shouldn't repack revisions every so often in mid-branch rather than waiting until the end
[21:16] <RenatoSilva_> how to avoid searching all plugins in selftest?
[21:17] <LarstiQ> RenatoSilva_: -s bp.<pluginyouareinterestedin>
[21:18] <RenatoSilva_> LarstiQ: oh dot, I was trying semi-colon
[21:18] <LarstiQ> RenatoSilva_: bp. is actually a shorthand for bzrlib.plugins.
[21:18] <RenatoSilva_> LarstiQ: what does bp stands for
[21:18] <RenatoSilva_> LarstiQ: ah ok
[21:18] <LarstiQ> RenatoSilva_: so it is the python identifier for the containing module
[21:19] <LarstiQ> RenatoSilva_: some of those we use so frequently, they have shorthands, like bp for plugins or bt for tests
[21:19] <LarstiQ> sorry, bzrlib.tests, to be complete
[21:21] <RenatoSilva_> FYI, bzrtools delivered with bzr 1.16-1 has a test failure, it tries to load a test module which does not exist
[21:25] <hsn_> verterok: if bzr st reports filename* then bzr-eclipse doesnt see it as changed
[21:26]  * RenatoSilva_ tried right now run it at work, many more failures: http://pastie.org/544640.txt
[21:26] <verterok> hsn_: oh, good catch :)
[21:26] <verterok> hsn_: would you mind to file a about this?
[21:27] <Skoorbulous> LarstiQ: it worked! Thanks so much. Now my problem is when I run bzr annotate file it spits everything out apparently in one long string without crlf - it is so messy I can't make anything of it
[21:28] <LarstiQ> Skoorbulous: does the file actually contain more than 1 line?
[21:29] <Skoorbulous> it is a php file and it apparently does when I open in a text editor
[21:29] <SamB> Skoorbulous: what does wc -l say ?
[21:29] <RenatoSilva_> verterok: http://pastie.org/544652.txt
[21:29] <Skoorbulous> it says "0 batch_production.php"
[21:30] <jelmer> SamB: patches to support more kinds of globbing are welcome as long as they come with sufficient tests
[21:30] <SamB> Skoorbulous: I guess you're hosed -- you seem to be depending on word wrap
[21:31] <LarstiQ> RenatoSilva_: FAILED (failures=35, errors=1) is what I get for bzrtools
[21:31] <Skoorbulous> it definitely has multiple lines I guess there is an encoding compatibility problem or something
[21:31] <RenatoSilva_> verterok: the error if for the weird char, the failure is for the python dll instead of executable
[21:31] <SamB> Skoorbulous: ... it didn't originate on a Mac, did it?
[21:31] <jelmer> SamB: it's fairly independent of the rest of the code
[21:31] <Skoorbulous> yes it is on a mac
[21:31] <SamB> Skoorbulous: ah.
[21:31] <Skoorbulous> and probably originated from a mac
[21:31] <RenatoSilva_> LarstiQ: you mean it's normal?
[21:32] <hsn_> verterok: you want output of bzr xmlstatus?
[21:32] <jelmer> SamB: bzr branch does indeed fail if you break it, see a recent discussion between lifleless and me on the mailing list for details
[21:32] <SamB> Skoorbulous: oh. it probably uses only CR as the line seperator...
[21:32] <gioele> helo
[21:32] <Skoorbulous> so I should just find a way to convert all cr to crlf?
[21:32] <verterok> hsn_: no, not needed, just to keep track that the decorator isn't handled the change of the executable bit
[21:32] <SamB> jelmer: I'm talking about what it leaves behind
[21:32] <gioele> what is more correct: "ghost revision" or "revision ghost"? I'd say ghost revision
[21:32] <verterok> RenatoSilva_: ok, looking
[21:33] <LarstiQ> RenatoSilva_: ideally, it wouldn't be. But I have no idea about bzrtools development
[21:33] <SamB> jelmer: oh, and breaking was insufficient
[21:33] <SamB> I had to ^Z and kill it
[21:33] <LarstiQ> RenatoSilva_: it doesn't seem to be a problem specific to your computer if that is what you're asking
[21:33] <verterok> hsn_: that info is in xmlstatus, it's just bzr-eclipse not using it :/
[21:33]  * SamB looks, however
[21:33] <LarstiQ> SamB: that, shouldn't be needed
[21:34] <SamB> it wouldn't have been if the first ^C didn't start it trying to repack
[21:34] <jelmer> SamB: ^C always works for me
[21:34] <SamB> which was thrashing awfully
[21:34] <SamB> I only have ~512 MiB of RAM
[21:35] <jelmer> SamB: but yeah, the recent mailing list thread should explain most of the reasoning
[21:35] <jelmer> SamB: it should probably just remove the directory,
[21:35] <SamB> jelmer: yeah
[21:35] <SamB> at least when there isn't a repository in it
[21:36] <SamB> dunno about if there is
[21:37] <RenatoSilva_> s/if for/is for
[21:37] <RenatoSilva_> LarstiQ: at home when I try just selftest it stops in bzrtools while loading a non-existing test module
[21:38] <SamB> jelmer: so what's the subject of this thread?
[21:38] <LarstiQ> RenatoSilva_: that I don't get
[21:38] <verterok> RenatoSilva_: I need to debug this, so I'll push it for later, still at work
[21:38] <LarstiQ> RenatoSilva_: do you know which one?
[21:38] <RenatoSilva_> LarstiQ: I don't think 'ideally'
[21:38] <RenatoSilva_> LarstiQ: which module? I can't recall
[21:38] <Skoorbulous> LartiQ: so I should just find a way to convert all cr to crlf?
[21:39] <LarstiQ> Skoorbulous: that would be a workaround
[21:39] <LarstiQ> Skoorbulous: (and something I'd personally do anyway)
[21:40] <RenatoSilva_> LarstiQ: I guess it's test_fetch_ghosts
[21:40] <jskulski> I have a module I am working on that I keep in a bzr repos that I branched into a svn project and I wanted to push back some changes
[21:41] <jskulski> but when I do bzr segfaults saying the svn repo is locked (which it is). however after i svn cleanup, and try to push again bzr is doing the locking
[21:41] <RenatoSilva_> verterok: bug 398997, bug 399000
[21:44] <jskulski> i dont want bzr to do anything with .svn besides ignore it
[21:44] <lifeless> moin
[21:44] <RenatoSilva_> verterok: with all these changes in bzr-xmloutput, bzr-java-lib and redstone xmlrpc, I could run bzr-eclipse pretty fine in Galileo :)
[21:45] <RenatoSilva_> verterok: I mean, with non-ascii paths
[21:45] <jelmer> jskulski: uninstall bzr-svn
[21:45] <jskulski> jelmer:: anything less drastic?
[21:45] <jskulski> i need bzr-svn for other projects
[21:46] <jelmer> jskulski: you can specify --no-plugins, which will disable all plugins including bzr-svn
[21:47] <jskulski> jelmer:: thank you
[21:47] <Skoorbulous> is there simple version control software I can use? I feel like bzr is a little complex and hard to use for simple mortal beings like myself
[21:47] <dash> Skoorbulous: !
[21:48] <dash> Skoorbulous: bzr is the easiet vcs i've ever used :)
[21:48] <dash> Skoorbulous: what difficulties have you had?
[21:48] <Skoorbulous> well shoot I am an idiot then
[21:48] <dash> Skoorbulous: or maybe i'm just too used to svn
[21:48] <Skoorbulous> well for example now I'm going to have to find a way to convert all the cr in all my files to crlf
[21:48] <Skoorbulous> I'd prefer not to have to learn unix just to control the versions of my website
[21:49] <RenatoSilva_> verterok: BTW, https://bugs.eclipse.org/bugs/show_bug.cgi?id=282226
[21:49] <dash> Skoorbulous: not sure what that has to do with version control?
[21:49] <SamB> jelmer: so ... what was the subject line on this email thread ?
[21:49] <jelmer> SamB: I'm not sure exactly
[21:49] <SamB> jelmer: date?
[21:49] <Skoorbulous> exactly - it has nothing to do with version control so it would be nice not to have to do all these things just to be compatible with bzr
[21:49] <jelmer> I think it was in a thread about being able to resume bzr-svn branches
[21:50] <jelmer> SamB: it was in the last 30 days
[21:50] <Skoorbulous> my website doesnt seem to mind that I have cr in my docs
[21:50] <SamB> gee that helps a lot :-(
[21:50] <lifeless> Skoorbulous: you don't need to convert your files to use bzr on them
[21:51] <Skoorbulous> well for example I can't use annotate because it sees everything in the file as one line
[21:51] <dash> Hm
[21:51] <dash> what version of bzr are you using?
[21:51] <Skoorbulous> me? I'm using the latest version. Just installed yestereday
[21:53] <verterok> RenatoSilva_: thanks for the bugs :)
[21:53] <verterok> RenatoSilva_: that's great! you did most of the work ;)
[21:54] <verterok> RenatoSilva_: oh, that would be excelent (https://bugs.eclipse.org/bugs/show_bug.cgi?id=282226)
[21:54] <lifeless> Skoorbulous: that is true. However we're currently working on annotate to improve it; when thats been done it will be able to annotate files with other End-Of-Line formats.
[21:55] <RenatoSilva_> verterok: I can't wait for new releases of bzr-java-lib and xmloutput :)
[21:56] <verterok> RenatoSilva_: as soon all this fixes land in trunk, new version..maybe a big jump to 0.9
[21:56] <Skoorbulous> Lifelss: can you suggest a way that I can convert my docs to an end of line symbol that will work with bzr and continue to fuction on my mac web server?
[21:56] <RenatoSilva_> verterok: the only problem is xmlrpc, I will still need a patch to make it work
[21:56] <verterok> RenatoSilva_: why?
[21:57] <RenatoSilva_> verterok: because it was the ExPat error, do you remember? It is caused by redstone client declaring utf-8 in XML to send, but sending platform default bytes. Then I did that patch, but they need to release it right?
[21:58] <verterok> RenatoSilva_: oh, I completely missed that \o/
[21:58] <verterok> RenatoSilva_: I can bundle whatever version of redston xmlrpc we need
[21:58] <verterok> in bzr-eclipse
[21:59] <RenatoSilva_> verterok: what do you mean
[21:59] <verterok> RenatoSilva_: your patch to the redstone xmlrpc guys, I missed that
[22:00] <RenatoSilva_> verterok: it is being watched in the xmloutput bug
[22:00] <RenatoSilva_> verterok: I can bundle whatever version of redston xmlrpc we need --> what do you mean?
[22:00] <lifeless> Skoorbulous: for each file do 'cat file | tr \\r \\r\\n > file.fixed'
[22:00] <RenatoSilva_> verterok: however redstone guys didn't give any feedback yet
[22:01] <verterok> RenatoSilva_: if bzr-eclipse needs a patched redstone-xmlprc, I can make the build with the "fixed" redstone-xmlrpc
[22:02] <RenatoSilva_> verterok: ok, nice
[22:02] <verterok> RenatoSilva_: as it's just a dependency in bzr-java-lib pom.xml, and I already provides a maven repository with all the depdendencies, I cound push a new jar to the maven repo ;)
[22:04] <Skoorbulous> lifeless, can I do cat * | tr \\r \\r\\n ?
[22:04] <RenatoSilva_> verterok: you could just add the patch file with the bug number somewhere, then _during the buid_ you patch the diff, so that you can use updated versions of redstone library...
[22:04] <Skoorbulous> i.e., can I just use a wildcard?
[22:05] <verterok> RenatoSilva_: I'm not building redstone-xmlrpc during the build of bzr-eclipse, just using the jar available in the maven repository.
[22:06] <RenatoSilva_> verterok: ah ok
[22:07] <RenatoSilva_> verterok: but that maven repo, it is self-made right?
[22:07] <verterok> RenatoSilva_: right, I can use a patched version from the maven repo ;)
[22:08] <RenatoSilva_> verterok: and you put the lib there right, so you'd get the source and patch the fix and build the custom lib and put int the repo right?
[22:08] <verterok> RenatoSilva_: yes
[22:09] <verterok> RenatoSilva_: but I don't know if I can call it redstone-xmlrpc...you know licenses, etc
[22:09] <RenatoSilva_> verterok: ok I just mean to keep the source of the custom lib as {source + patch}, and the resulting build as {compile source + apply patch }, instead of {pacthed source} -> {compile patched source}. I think it's a better approach, just a suggestion.
[22:11] <verterok> RenatoSilva_: I agree, just that including that in the build of bzr-eclipse is overkill
[22:11] <RenatoSilva_> verterok: ok
[22:14] <RenatoSilva_> verterok: the patch is pretty simple. There is an encoding in some .properties file. It is used in XML header, but not in the actual bytes (new String(bytes)). I just changed the content to new String(bytes, readEncodingFromProperties).
[22:16] <RenatoSilva_> verterok: note: the patch in sf itself is out-dated (can't be updated), because it uses hard-coded "UTF-8". Then one attached in launchpad is ok, it gets from preferences.
[22:16] <verterok> RenatoSilva_: do you remember the bug number?
[22:16] <lifeless> Skoorbulous: no - tr outputs to std out
[22:16] <lifeless> so you need to translate each file to a temp name and then mv the output back over the original file
[22:17] <lifeless> Skoorbulous: there are probably scripts on the web that will do groups of files for you
[22:17] <RenatoSilva_> verterok: bug 300300, in SF: http://sourceforge.net/support/tracker.php?aid=2816563
[22:18] <RenatoSilva_> verterok: sorry, bug 388300
[22:18] <verterok> RenatoSilva_: thanks!
[22:19] <RenatoSilva_> verterok: the up-to-date patch is attached in lp (If you're going to create the custom lib): http://launchpadlibrarian.net/28683665/xmlrpc_fix.diff
[22:20] <verterok> RenatoSilva_: great!
[22:20] <verterok> RenatoSilva_: we can use the patched xmlrpc, but I'll try to contact the redtone devs
[22:20] <RenatoSilva_> verterok: ok
[22:23] <RenatoSilva_> RenatoSilva_: what do you mean with 0.9, xmoutput?
[22:23] <RenatoSilva_> verterok: ^
[22:24] <verterok> RenatoSilva_: the version number, currently it's 0.8.4 and trunk is 0.8.5
[22:24] <RenatoSilva_> verterok: ah ok, I tought for a moment it was 0.9.4 or so
[22:27] <RenatoSilva_> verterok: trunk 0.8.5? so the commit comment on that means its development is starting? I thought it means it was actually released...
[22:28] <verterok> RenatoSilva_: I was this >< close to release 0.8.5, and then you came and filed a lot of bugs, so I just ignored 0.8.5, and targeted all this fixes to 0.8.6 ;)
[22:28] <verterok> RenatoSilva_: btw, thanks a lot!!
[22:29] <RenatoSilva_> verterok:hehehe, sorry for interrupting 0.8.5 :)
[22:30] <verterok> RenatoSilva_: at all, great work! :)
[22:30] <RenatoSilva_> verterok: thank you, thanks for helping
[22:31]  * RenatoSilva_ is away
[22:32] <verterok> RenatoSilva_: seeya later!
[22:59] <jml> good morning Bazaar!
[23:02] <jkakar> Good morning jml. :)
[23:03]  * RenatoSilva_ is gmt -3, 7pm
[23:09] <poolie> good morning
[23:10] <RenatoSilva_> good night
[23:12] <RenatoSilva_> ctcp verterok TIME
[23:25] <lifeless> hi p obst
[23:25] <lifeless> bah
[23:25] <lifeless> hi poolie
[23:25] <lifeless> sorry obst, mistyped
[23:25] <poolie> hey
[23:47] <gioele> will a property set with propset -R be inherited by new directories?
[23:49] <SamB> lifeless: I don't understand your excuses about interrupted "branch"es
[23:50] <gioele> (sorry, wrong VCS :))
[23:50] <SamB> gioele: I didn't think bzr supported those (yet?)
[23:55] <lifeless> SamB: what don't you understand?
[23:55] <SamB> lifeless: well, it might have to do with the fact that I'm trying to branch from a multi-thousand-rev SVN branch
[23:56] <lifeless> SamB: Thats a very different use case than interrupted branches of bzr to bzr
[23:56] <SamB> true
[23:56] <lifeless> SamB: bzr-svn does everything incremental anyway
[23:57] <SamB> it doesn't update the branch heads during a "bzr branch" incrementally
[23:57] <lifeless> thats true
[23:57] <SamB> on a slightly different note, I'm wondering why "bzr branch" is waiting until all revisions are pulled to start repacking any of them
[23:58] <lifeless> generally we don't repack any
[23:58] <igc> morning
[23:58] <SamB> oh. maybe I need to ask jelmer about that ?
[23:59] <lifeless> its only when data conversion is needed that any repacking will occur (or an autopack, but thats orthogonal to fetching data - its db maintenance)
[23:59] <SamB> still, it doesn't seem like it would kill you to do a checkpoint every thousand revisions or so?
[23:59] <SamB> hmm, I switched back, didn't I?
[23:59]  * SamB can't seem to hold just one conversation at a time lately
[23:59] <lifeless> SamB: bzr fetching doesn't move data topologically or chronologically