[00:00] <lifeless> fullermd: there is one particular vicious bug, which abentley suggested a great fix for
[00:00] <lifeless> but noone has executed it
[00:00] <fullermd> I take exception to commands doing totally different things.  Special cases are bad.
[00:00] <lifeless> fullermd: I agree with you
[00:01] <fullermd> Especially when every other VCS has an 'update' command that goes between a WT and its Branch (or whatever equivalent that VCS has)
[00:02] <lifeless> fullermd: well, git doesn't, hg doesn't do wt <-> branch (it does something different again), svn and cvs's updates are behaviourally identical to bzr's
[00:02] <lifeless> (modulo the 'check out new files' aspect.
[00:03] <fullermd> Well, git re-abuses 'checkout' for that.
[00:03] <fullermd> And hg's update DOES update the WT to something based on the branch.
[00:04] <fullermd> Anyway.  I totally don't have the time or the energy for the whole co/bb discussion.
[00:04] <lifeless> it changes the working copy to  a revision
[00:04] <lifeless> fullermd: ok
[00:04] <lifeless> fullermd: I want to get to the bottom of it some day
[00:04] <fullermd> sven_oostenbrink: Are you going to be around for a while yet?
[00:04] <lifeless> I think we should fix the polish bugs we have first
[00:05] <fullermd> Oh, totally.  I wouldn't keep grumping about it if I didn't want to get it dealt with eventually   :)
[00:05] <lifeless> :P
[00:05] <fullermd> I certainly agree that some of the behaviors (like that two-merge-update) are flat-out bugs, and need to be fixed irregardless of other issues.
[00:07] <fullermd> sven_oostenbrink: I have some discussions of 'mainline' I can put together and post up, but it's 18:00 and I reallyseriouslydesperately wanna go have lunch.  So it'll be a while.
[00:07] <lifeless> mwhudson: so at this point you forward your confirmation mail to plans@tripit.com and magic happens
[00:08] <phoenixz> fullermd: another thing.. since this is a DVCS.. if I want to have a backup of my work, I only need to have a copy of the .bzr directory, right?
[00:09] <fullermd> phoenixz: Yeah.  Though realize that every branch (or at least, every shared repo) is a 'backup' too.  We commonly back up branches via 'push'   ;)
[00:09] <fullermd> phoenixz: See above about mainline.
[00:10] <dash> phoenixz: to emphasize this fact, note that pushing to a remote branch does not create or modify the remote branch's working tree. :)
[00:10] <phoenixz> gottit, get some food, don't want you to starve to death, who else will help me out here? :)
[00:11] <fullermd> Somebody else, who won't get into an argument with lifeless in the middle of it?   8-}
[00:11] <phoenixz> dash: yeah, I was basically talking about branches with WT that would not contain changes..
[00:11] <phoenixz> heheh
[00:17] <fullermd> phoenixz: BTW, you say that AboutUsingRepositories link as well, yse?
[00:17] <phoenixz> fullermd: yeah, saw it, will give it a read in a moment
[01:36] <Peng_> jam: I might not have recompiled all of the extensions before the "merge" error. I'll see if I can reproduce it.
[01:38] <Peng_> jam: Ehh, I'll follow up in an email.
[01:44] <Peng_> jam: Short answer: I can't reproduce the errors. Looks like I did forget to recompile.
[01:47] <lifeless> james_w: around?
[01:48] <jfroy|work> jelmer: is there a way to push to a local (e.g. file) svn repository with bzr-svn?
[01:48] <jfroy|work> is seems there's no way to separate the branch name / path from the repository URL / path
[01:51] <wgrant> jfroy|work: WFM with file:// URLs.
[01:51] <jfroy|work> WFM?
[01:51] <wgrant> Works for me.
[01:51] <jfroy|work> mmm
[01:51] <wgrant> And it also seems to work with just a normal absolue path.
[01:52] <jfroy|work> well yeah, if you want to push to another bazaar branch
[01:52] <jfroy|work> I'm trying to push from bzr to a local svn repositoru
[01:52] <jfroy|work> *repository
[01:53] <wgrant> How does it complain when you try? It works fine for me.
[01:54] <jfroy|work> not a branch or directory already exists
[01:54] <jfroy|work> Ahh
[01:54] <wgrant> That's from 'bzr push /path/to/repo/path/to/subpath'?
[01:54] <jfroy|work> dpush fails, push works
[01:54] <jfroy|work> (I was trying to use dpush)
[01:55] <wgrant> Ahh.
[01:55] <jfroy|work> Ok, that's a new one
[01:55] <jfroy|work> bzr: ERROR: [Errno 24] Transaction cleanup failed
[01:56] <wgrant> New to me also.
[02:03] <mwhudson> lifeless: i wonder if tripit is going to understand the air nz itinerary in pdf i just mailed it...
[02:05] <lifeless> possibly :P
[02:05] <mwhudson> hm, it seems like it did, but now i can't find it online
[02:06] <mwhudson> ah, just took a while
[02:06] <lifeless> 'magic'
[02:06] <jfroy|work> so I just don't see how to use dpush
[02:07] <jfroy|work> (I really don't want the metadata)
[02:07] <lifeless> jfroy|work: file a bug :)
[02:07] <jfroy|work> it won't create the branch if it doesn't exists, and when it does, its error message stating I should pass --overwrite ends in failure because it doesn't have an overwrite option!
[02:08] <lifeless> mwhudson: indeed, it did better than for me; it thinks I stay in chch :P
[02:08] <lifeless> I guess I should tell them somehow
[02:08] <lifeless> which is odd vause their detailed view is right
[02:10] <mwhudson> it even coped with the hotel confirmation
[02:10] <mwhudson> lifeless: i think they might be using memcache or something a bit much
[02:10] <mwhudson> taking the "eventually consistent" to extremes
[02:13] <lifeless> mwhudson: we have longer lag than you saw, I think
[02:15] <jfroy|work> well, having more luck pushing to a svnserve-ed repository
[02:23] <igc> maxb: re storing git refs in bzr nicks, I'd like to explore the idea. Storing the value exactly probably isn't the best choice but having a deterministic mapping is a great idea
[02:27] <lifeless> igc: do you mean the object sha, or the human reflog name?
[02:27] <igc> lifeless: human name
[03:04] <Peng_> Either something odd has happened, or lp:~jameinel/bzr/2.1-static-tuple-chk-map has really helped Loggerhead's memory usage.
[03:07]  * igc food
[03:07]  * fullermd wouldn't rule out 'both', just on GP   :p
[03:08] <jfroy|work> so I don't understand fast-export :|
[03:08] <jfroy|work> no matter what bzr branch I export, it always seems to re-import it as trunk
[03:15] <jfroy|work> ahhh, 0b
[03:15] <jfroy|work> *-b
[03:15] <jfroy|work> magic
[03:19] <jfroy|work> do I need to re-export marks (whatever those are) if I have more than 2 branches to export and import?
[03:20] <jfroy|work> or do I need --export-marks only for the first export-import, and only need to use --import-marks for all subsequent export-imports?
[03:39] <mwhudson> spiv, lifeless: so i think the smart server doesn't handle unicode paths very well
[03:40] <lifeless> mwhudson: backtraces, details, please.
[03:41] <mwhudson> lifeless: run bzr serve --allow-write somewhere
[03:41] <mwhudson> bzr push bzr://localhost/b%C3%A9
[03:42] <mwhudson> --> http://pastebin.ubuntu.com/299462/
[03:46] <mwhudson> on the server side, Transport.__init__ is seeing a 'base' of filtered-41598608:///b\xc3\xa9/
[03:46] <lifeless> yup thats wrong
[03:47] <mwhudson> sigh
[03:47] <mwhudson> i think sftp has different bugs like this :(
[03:49] <mwhudson> is there some way i can see what's going over the wire easily?
[03:51] <mwhudson> huh nosmart+bzr:// works finer
[03:51] <mwhudson> -r
[03:58] <lifeless> tcpdump
[04:00] <fullermd> phoenixz: http://bazaar-vcs.org/MatthewFuller/AboutMainline
[04:07] <mwhudson> the path is sent across the wire unescaped
[04:10] <mwhudson> http://pastebin.ubuntu.com/299476/ fixes things, maybe
[04:10] <Peng_> This "pretend the screen is 65,536 columns wide" thing is causing problems. :\
[04:11] <Peng_> Including test failures. :D
[04:12] <spiv> mwhudson: hmm
[04:12] <Peng_> (And yes I'll file bugs, once I verify that that's what's responsible.)
[04:13] <spiv> mwhudson: seems plausible I guess
[04:13] <lifeless> mwhudson: in fact u1 have rolled back to paste, spawning was too much fail :)
[04:13] <spiv> mwhudson: I wonder about paths sent in responses, but one problem at a time...
[04:13] <Peng_> "u1"?
[04:13] <lifeless> Peng_: ubuntuone
[04:16] <mwhudson> lifeless: ugh
[04:16] <mwhudson> lifeless: oh well, my business with other things saved me some pain there i guess
[04:18] <mwhudson> spiv: uh yes i guess so
[04:18] <Peng_> How should environment variables be handled in tests? If you change one, will it be automagically fixed when the test ends?
[04:18] <mwhudson> spiv: which smart verbs respond with paths?
[04:19] <mwhudson> Peng_: there is certainly some support in testcase for that
[04:19] <lifeless> Peng_: many common ones are automatically saved and restored
[04:19] <Peng_> "common ones"?
[04:20] <lifeless> plugins path, email, HOME, editor etc
[04:20] <lifeless> see bzrlib.tests
[04:21] <Peng_> Ah.
[04:23] <Peng_> They're fixed after every test? So it's okay to mess with them?
[04:24] <lifeless> the set that are isolated, yes
[04:24] <lifeless> those that aren't, you should call the isolation helper on first
[04:25] <arjenAU> ahoy my beloved bzr magicians
[04:25] <lifeless> ahrr
[04:25] <arjenAU> i come to you in search of enlightenment.
[04:25] <arjenAU> lifeless: stay put you, i'm a happy user!
[04:25] <lifeless> I was doing pirate
[04:25] <arjenAU> I need something akin to a hardlink in a branch
[04:25]  * fullermd is a couple doves short of a sixpack.
[04:25] <lifeless> in the ahoy theme
[04:25] <arjenAU> oh righty
[04:26] <arjenAU> lifeless: ideas?
[04:27] <arjenAU> so I need a file in 2 or 3 directories, and keep 'em in sync. no risk of divergence. a straight link would do it, if bzr can grok that.
[04:27] <lifeless> arjenAU: bzr can version symlinks
[04:28] <arjenAU> ok so I'd have a main and secondary... that would do. just not hardlinks? and I presume the symlinks break on windows or did you use the magic API to use it on NTFS?
[04:28] <arjenAU> i don't need win, just curious ;-)  NTFS supports symlinks but win doesn't use 'em
[04:29] <lifeless> we degrade on windows
[04:29] <lifeless> there is a plugin
[04:29] <lifeless> to do something more than we do
[04:29] <arjenAU> lifeless: no worries. ok so symlinks. ok out of the box or do I need to set anything to make this jive?
[04:29] <lifeless> ln -s foo bar
[04:29] <lifeless> bzr add
[04:29] <arjenAU> sounds sane as usual. ok
[04:30] <arjenAU> then, can I get conflicts on a bzr pull if I didn't have any local changes that weren't pushed?
[04:30] <lifeless> sorry, rephrase that wont
[04:30] <lifeless> s/wont/one/
[04:30] <arjenAU> euh?
[04:30] <lifeless> I don't understand the question :)
[04:30] <arjenAU> I do a bzr pull and I get conflicts, even though I have no local divergence afaik
[04:31] <lifeless> you may have local changes
[04:31] <lifeless> such as files that are ignored in a subdirectory
[04:31] <arjenAU> not on those files.
[04:31] <lifeless> or uncommitted edits to a file
[04:31] <arjenAU> i've seen this a few times ove rlast week or so. using 2.0
[04:31] <arjenAU> well jaunty ppa
[04:32] <arjenAU> it's honestly files I have not touched.
[04:32] <lifeless> could you, for a while, do 'bzr st; bzr pull'
[04:32] <lifeless> and when it happens file a bug with the output of those two commands - the order matters ;)
[04:32] <spiv> mwhudson: lots of them
[04:32] <arjenAU> lifeless: rigthy. can I nicely back out of the current state totry that again. revert?
[04:32] <jam> lifeless: I don't remember it happening for files, but if you delete a directory, then you can get a conflict if there are temp files lying around
[04:33] <jam> Peng_: I would like to think 'static-tuple-chk-map' helps mem, but I wouldn't have expected it to effect loggerhead
[04:33] <lifeless> jam: yes, thats why I mentoned ignored iles in subdirs
[04:33] <Peng_> jam: Hi. :)
[04:33] <lifeless> arjenAU: no, because we don't have the exact state any more
[04:34] <jam> lifeless: I'm currently trying to get meliae to perform 'compute_referrers' on a 500MB dump file w/ 5.6M objects.
[04:34] <spiv> mwhudson: list_dir obviously, but also I think various opening verbs can e.g. BzrDir.find_repositoryV3 and Branch.get_config_file and probably several others.
[04:34] <jam> The problem is that a dict holding 5.6M entries is 200MB by itself...
[04:34] <Peng_> jam: Well, Loggerhead does read data that comes through bzrlib.chk_map.
[04:35] <jam> Peng_: for iter_changes?
[04:35] <arjenAU> lifeless: ehm. so to get rid of the mess, I did bzr revert then bzr clean-treeto be sure I didn't have build leftovers. then bzr pull says no rvisions to pull.... so it's just the local checkout that's the issue now, right? what command? or did I go foul somewhere
[04:35] <Peng_> jam: No clue. I know it hits iter_ancestry, but I forget how.
[04:36] <lifeless> arjenAU: well, thats the thing, we don't have the state that caused the conflicts
[04:36] <lifeless> arjenAU: so we need to wait for it to happen again
[04:36] <lifeless> arjenAU: thus my asking you to do 'bzr st; bzr pull' from here on in, to capture more detail when it happens again.
[04:36] <mwhudson> spiv: list_dir agrees on the encoding with that via a local transport fwiw
[04:37] <jam> arjenAU: so if you get conflicts, 'bzr revert' should restore you to the pristine state, however, as lifeless says, determining what got you there in the first place would be useful
[04:37] <arjenAU> yes I get that, but I don't understand the situation I now have in my tree.
[04:37] <mwhudson> >>> get_transport('bzr://localhost').list_dir('.') == get_transport('/home/mwh/tmp').list_dir('.')
[04:37] <mwhudson> True
[04:38] <spiv> That's good.
[04:38] <Peng_> jam: Loggerhead caches a copy of the revision graph. . .
[04:38] <jam> mwhudson: yeah, I would use list_dir() as a guideline for how paths should be encoded
[04:38] <jam> Peng_: revision graph comes from the indices
[04:39] <jam> I thought it also cached the per-revision deltas
[04:39] <mwhudson> yeah, it does
[04:39] <jam> and that could certainly come from chk_map
[04:39] <mwhudson> though not in ram very much i think
[04:39] <arjenAU> jam: if you need graph magic, look at http://openquery.com/blog latest entry, you may find useful.
[04:39] <spiv> mwhudson: oh, and of course the various error responses that contain paths
[04:40] <spiv> mwhudson: e.g FileExists
[04:41] <Peng_> jam: FYI, I just ran "bzr selftest" on bzr.dev + 2.1-static-tuple-chk-map + statictuple-pickling, and there were no failures (related to ST, anyway)
[04:42] <mwhudson> argh
[04:43] <mwhudson> now get_transport('bzr://localhost').mkdir('b%C3%A9bbb') creates a directory with the escaped path :(
[04:43] <spiv> mwhudson: :(
[04:46] <spiv> mwhudson: so clients today are sometimes sending utf-8 bytes and sometimes sending urlutils.escape'd?
[04:47] <mwhudson> spiv: it seems that way
[04:47] <mwhudson> spiv: at a guess bzrlib.remote and bzrlib.transport.remote are different
[04:47] <spiv> mwhudson: is it varying by verb only?
[04:48] <mwhudson> spiv: not sure
[04:48] <mwhudson> spiv: actually
[04:48] <spiv> If it's just a difference between VFS verbs and not, that's not too bad
[04:48] <mwhudson> spiv: what do you mean by that question? :)
[04:49] <spiv> I mean, for every verb X, do clients consistently send paths a particular way?
[04:49] <mwhudson> spiv: i don't think there are cases where the same verb is called with varying levels of escaped-ness
[04:49] <igc> lifeless, jam: any hints on where I should look to solve bug 441125?
[04:49] <spiv> Right
[04:49] <mwhudson> spiv: right, yes, afaik
[04:49] <spiv> That's what I'd expect (and hope)
[04:49] <lifeless> igc: isn't it a dupe?
[04:49] <spiv> If so, that's not insurmountable.
[04:50] <igc> lifeless: not sure. It's well beyond my knowledge area
[04:50] <spiv> Especially if the split is exactly VfsRequest/everything-else
[04:51] <spiv> mwhudson: so bzrlib.remote calls something that seems to intentionally unquote the url before transmission
[04:52] <mwhudson> spiv: if you say so, i've become a bit lost among the various objects & methods
[04:52] <jam> lifeless: so if I understand the exception, it is triggering because an inventory is referring to a file key  (file_id, revision) which is *not* present in the repository
[04:52] <jam> sorry igc^^
[04:53] <jam> which is certainly bad-mojo
[04:53] <jam> is this a stacked branch?
[04:53] <igc> jam: yes
[04:53] <lifeless> spiv was fixing a bug like this yesterday
[04:53] <lifeless> or so
[04:53] <jam> and does reconcile fail on the base?
[04:53] <igc> jam: reconcile on the trunk works ok
[04:53] <spiv> mwhudson: specifically RemoteBzrDir._path_for_remote_call invokes _SmartClient.remote_path_from_transport invokes the medium's remote_path_from_transport
[04:53] <igc> jam: it's only on the stacked branch it fails
[04:54] <spiv> mwhudson: both implementions of that make a urlutil.relative_url and urlutils.unquote it.
[04:54] <igc> jam: branching from there gives a branch on which reconcile works
[04:54] <jam> igc: so one possibility is to probe through all of the inventories to find one that references this text key
[04:54] <igc> jam: can comparing the log -v -p on the orginal branch and the created branch gives the same results
[04:54] <jam> it is certainly possible that this inventory is 'unreferenced'
[04:55] <spiv> mwhudson: where bzrlib.transport.remote uses RemoteTransport._remote_path which appears to rely on whatever Transport._combine_paths does
[04:55] <jam> (or, not in the ancestry)
[04:55] <mwhudson> spiv: ah right
[04:55] <jam> _text_refs is built up by walking *all* chk pages, IIRC
[04:55] <jam> not  just chaining from revisions => inventories => chk_pages
[04:56] <mwhudson> spiv: so a cheap hack would be to have VfsRequest override translate_client_path to unescape again?
[04:56] <jam> hold on... maybe not. Maybe only ones that are referenced via an inventory
[04:56] <spiv> lifeless, jam, igc: The bug lifeless is thinking of that I fixed is bug 437626, I think
[04:56] <jam> it looks like unreferenced ones are just streamed out directly, without being parsed.
[04:57] <mwhudson> spiv: https://code.edge.launchpad.net/~mwhudson/bzr/escape-smart-server-requested-paths fwiw
[04:57] <spiv> lifeless, jam, igc: which didn't affect 2a repos, if that helps
[04:57] <igc> spiv: thanks
[04:57] <jam> however, that doesn't mean we have the *revision* for that inventory
[04:57] <igc> (it does)
[04:57] <lifeless> jam: unrefed ones shouldn't be copied though
[04:57] <lifeless> jam: except for the adjacent ones, and those we don't want the texts for
[04:58] <spiv> mwhudson: I think so
[04:58] <igc> jam, lifeless: so does that imply reconcile is looking at extra data it doesn't need to?
[04:59] <spiv> mwhudson: or not apply your escaping
[04:59] <spiv> mwhudson: whatever works is fine by me, though :)
[04:59] <lifeless> igc: possibly yes
[04:59] <mwhudson> spiv: is it sane to have vfs requests have different rules than the others?
[04:59] <spiv> mwhudson: we'll need tests, obviously, and I should add some text about this to network-protocol.txt
[05:00] <jam> igc: it is possible to have inventories in the repository that aren't referenced by the branch. it is further possible for those to be borked.
[05:00] <spiv> mwhudson: well, they already do AIUI?
[05:00] <jam> hence why I suggested you walk all inventories and find out which one thinks it knows something about the given file_key
[05:00] <mwhudson> spiv: i guess
[05:00] <mwhudson> fixing it would require defining a whole new tranche of verbs
[05:01] <spiv> mwhudson: the long term plan is to remove the vfs requests anyway, so if there's cruft that's restricted to just them I'm fairly comfortable with that
[05:01] <jam> for inv in b.repository.iter_inventories([k[0] for k in b.repository.inventories.keys()]):
[05:01] <spiv> mwhudson: and as far as cruft goes this is pretty minor, happily.
[05:01] <jam>   if file_key in inv:
[05:01] <mwhudson> spiv: true enough
[05:01] <jam>     print inv.revision_id
[05:03] <mwhudson> spiv: where are the vfs verbs tested?
[05:05] <mwhudson> just in the generic transport tests applied to RemoteTransport?
[05:05] <spiv> mwhudson: mainly those, yeah
[05:05] <spiv> mwhudson: there's also a little bit SmartServerRequestHandlerTests in test_smart_transport
[05:06] <spiv> mwhudson: most of the newer verbs are more rigorously tested in test_smart
[05:10] <mwhudson> spiv: i guess an appropriate test for this is to have a RemoteTransport onto a directory, mkdir('%C3%A9'), and then check list_dir via a LocalTransport matches?
[05:11] <mwhudson> spiv: can i get you to write that? :-)
[05:13] <igc> jam: thanks for the code snippet. That saved me ages I'm sure ...
[05:14] <igc> jam: I get 202 matches on that file-id and the rev-id is one of them
[05:14] <igc> i.e. rev-id failing in the KeyError exception
[05:14] <igc> jam: make that 280 matches sorry
[05:14] <spiv> mwhudson: I suppose so, although it's not my ideal way to spend a Friday afternoon ;)
[05:15] <mwhudson> argh
[05:15]  * mwhudson is all confused again :(
[05:15] <spiv> mwhudson: but yes, that sounds like a good test to have
[05:15] <spiv> mwhudson: oh, except I'd back it onto a MemoryTransport :)
[05:47] <mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/458762
[05:47] <mwhudson> spiv: can i assign that to you?
[05:48] <spiv> mwhudson: no
[05:48] <spiv> mwhudson: because I just did :)
[05:48] <mwhudson> spiv: ok :)
[05:48] <spiv> mwhudson: thankks
[05:49] <mwhudson> spiv: np
[05:49] <mwhudson> spiv: i'm glad the problem turned out to be fairly simple in the end
[07:01] <jkakar> lifeless: I've written a command to upgrade Bazaar branches on Launchpad.  I'm not sure it's working.  Do the formats here make sense: http://pastebin.ubuntu.com/299569/
[07:05] <lifeless> jkakar: lp has a bug where it doesn't update the reported format
[07:05] <lifeless> jkakar: bzr info nosmart+<url>
[07:05] <jkakar> lifeless: Ah ha, I was wondering about that.
[07:07] <jkakar> lifeless: Woot: http://pastebin.ubuntu.com/299574/
[07:07] <lifeless> its been upgraded :)
[07:08] <jkakar> It's probably a good time to make the first release of AutoLP.
[07:08] <lifeless> autolp ?
[07:08] <jkakar> I want a place to collect Launchpad commands.  I already have several scattered about.
[07:08] <lifeless> lptools
[07:08] <lifeless> https://code.edge.launchpad.net/lptools
[07:08] <lifeless> and there is another one as well that the lp folk made
[07:09] <lifeless> (that meaning rockstar/jml/abentley I think, though I'm hazy)
[07:09] <jkakar> I didn't know about lptools, will check it out, thanks.
[07:09] <lifeless> it has a review-notifier which is nifty
[07:09] <lifeless> on my TODO to package it
[07:09] <wgrant> Might want to add lptools to the lpx project group.
[07:09] <lifeless> lpx?
[07:09] <lifeless> surely launchpad ?
[07:10] <wgrant> A new officially-sanctioned project group for launchpadlib-using applications.
[07:10] <jkakar> Launchpad Extensions, similar to the tx project group for Twisted.
[07:10] <lifeless> mmm
[07:10] <lifeless> seems totally weird to me to not use the launchpad group
[07:10] <wgrant> They are not part of LP.
[07:11] <lifeless> so?
[07:11] <wgrant> To they should not be part of LP.
[07:11] <wgrant> s/To/So/
[07:11] <lifeless> you're repeatin yourself but not making a case
[07:11] <wgrant> They are not part of LP in the real world, so why should they be part of LP on LP?
[07:11] <lifeless> the launchpad project group isn't just launchpad.net
[07:12] <jkakar> I like having a way to separate "Launchpad the moving parts of the service" from "The set of tools that work with Launchpad".
[07:12] <lifeless> it needs to be shrunk if thats what its meant to be an exact match for
[07:12] <lifeless> jkakar: I can see that
[07:12] <lifeless> project tags FTW
[07:12] <jkakar> Yeah. :)
[07:12] <wgrant> Right. lpx is brand new, and things haven't been sorted out yet.
[07:13]  * lifeless sighs over data models
[07:13] <lifeless> so limiting
[07:13] <igc> lifeless: the reconcile problem seems to come down to parent_map(text_refs) not finding all parents
[07:14] <igc> lifeless: so maybe we aren't collecting things correctly for a stacked branch?
[07:14] <lifeless> igc: reconcile runs in unstacked mode
[07:14] <lifeless> igc: because it has to enforce 'this repo is internally consistent'
[07:14] <igc> groupcompress_repo.py, line 1289
[07:15] <igc> text_refs has 5024 items
[07:15] <lifeless> igc: do you perhaps mean 'reconcile is not fully up to date with the setup of stacked repositories'
[07:15] <igc> parent_map returns a dict with 4875 keys
[07:16] <igc> I may mean that, still fumbling my way through
[07:16] <igc> lifeless:^^^
[07:16] <lifeless> :)
[07:16] <lifeless> I'm done for the day btw
[07:16] <lifeless> should have been, oh, 3 hours back. But I'm bad at 8 hour days
[07:16] <igc> lifeless: sorry. not great timing I know
[07:17] <igc> lifeless: I'll update the bug report and look more on Monday
[07:17] <lifeless> kk
[07:18] <lifeless> win 32
[07:21] <vila> hi all
[07:21] <vila> lifeless: win 32... 2000 ? XP ? Vista ? :-P
[07:25] <igc> hi vila
[07:30] <lifeless> wgrant: its a shame that bzr, and various things with lp support won't ever be able to be in lpx :P
[07:35] <bialix> privet
[07:35] <wgrant> lifeless: This is why we need project tags.
[07:35] <bialix> oh! my favorite subject: project tags
[07:36]  * bialix looks at irclogs
[07:36] <lifeless> wgrant: I know :)
[07:36] <lifeless> hi vila
[07:53] <igc> lifeless: I'm seeing *much* better memory usage having dropped the cache size down to 1 by default, along with the latest bzr trunk with jam's improvements
[07:54] <igc> lifeless: you may want to retry a netbeans import when you get a chance
[07:54] <lifeless> igc: I'll teach you the cache mantra eventually ;)
[07:54] <igc> it helped at the time :-)
[07:55] <igc> but I'm really pleased it's mostly not needed now
[07:55] <lifeless> hows the performance?
[07:55] <igc> better!
[07:55] <lifeless> good
[07:55] <lifeless> gc costs a lot :)
[07:55] <igc> well, better or medium to large projects
[07:56] <igc> on
[07:56] <igc> it's slower on smaller projects but not by a big amount
[07:56] <spiv> igc: nice
[07:57] <igc> spiv: well, turning off a cache is simple - jam and you guys did the hard yards making the core fast enough that it wasn't helpful!
[07:57] <igc> spiv: but thanks :-)
[08:18]  * igc dinner
[08:21] <lifeless> vila: forward your trip booking mail to plans@tripit.com, should create an itinery :)
[08:21] <vila> lifeless: yup, I'm trying to sort out the email used first, but thanks for the t[r]ip :)
[08:22] <vila> lifeless: next time, treat me as spiv but with a '+' instead of '-' !
[08:25] <loxs_wrk> what do I need to do in order to revert some file to the state from the previous revision
[08:26] <lifeless> vila: I wasn't sure if they were magic oryou had to configure it
[08:27] <lifeless> loxs_wrk: bzr revert -r -2 FILE
[08:27] <vila> lifeless: '+' is the "standard" magic char, spiv cheats :-P
[08:28] <vila> bah, I can't find the merge accounts anymore, will just delete the othr
[08:54] <vila> bug 353370 upsets babune a lot, do you I need to submit a proposal to revert revnos 4766 and 4764 or can I just go ahead  ?
[11:13] <lifeless> james_w: you has bugs
[11:13] <james_w> lifeless: you has responses to bugs
[11:13] <lifeless> james_w: also a merge request on -builder; would love to have a todo-to-merge for it for Monday
[11:13] <lifeless> james_w: thanks
[11:15] <lifeless> james_w: did you only just comment? I don't see bugmail..
[11:15] <james_w> about an hour ago
[11:16] <james_w> for "needs -sa" I said "eh?"
[11:16] <james_w> bzr-builder currently builds native packages to sidestep tarball issues
[11:16] <james_w> so you shouldn't have an issue
[11:17] <james_w> for "invalid email address" I said that I couldn't see how it happened given the code
[11:17] <james_w> though I didn't look that closely
[11:18] <james_w> knowing what $DEBEMAIL $DEBFULLNAME $MAIL $NAME $EMAIL were in your environment
[11:19] <lifeless> dch -a gets something more 'sane' (though still not great)
[11:19] <james_w> this uses a port of dch's algorithm, so it should give the same behaviour
[11:19] <james_w> I can believe that we made a mistake in porting though
[11:19] <lifeless> I saw, it doesn't.
[11:19] <lifeless> $ echo a $DEBEMAIL b $DEBFULLNAME c $MAIL d $NAME e $EMAIL
[11:19] <lifeless> a b c /var/mail/bobthebuilder d e
[11:19] <james_w> $MAIL looks wrong to me
[11:20] <james_w> or not
[11:21] <james_w> I wonder where Javier got MAIL from, dch doesn't seem to use it
[11:21] <lifeless> looks fine to me
[11:21] <lifeless> its the maildir for the user
[11:21] <lifeless> I can't imagine it ever being useful for email address detection
[11:22] <lifeless> bzr has a pretty complete heuristic itself, built in
[11:22] <james_w> ok
[11:22] <james_w> yeah, I wanted the same as dch though
[11:22] <james_w> I thought that would be less surprising
[11:22] <lifeless> so the mail thing was a distraction
[11:22] <james_w> using bzr stuff as a fallback before the "guess based on socket.fqdn" though
[11:23] <lifeless> took me a bit of time to realise that it wasn't lp api's giving me grief :)
[11:23] <lifeless> the merge proposal is more interesting to me than the bug now [as I has workaround]
[11:25] <lifeless> its lightly tested as there doesn't seem to be any test support for lp apis
[11:25] <lifeless> [and cody gave me a chunk of the code in one hit]
[11:25] <james_w> yeah, I'm reviewing that now
[11:27] <james_w> lifeless: if you could respond to the other bug I would appreciate it
[11:27]  * james_w doesn't like incomplete bugs
[11:28] <lifeless> james_w: I thought I replied to both
[11:29] <james_w> ok
[11:29] <james_w> hanks
[11:30] <lifeless> yeah, I did
[11:30] <lifeless> just bugmail slowness
[11:30] <lifeless> really, smtp==www, should be instant :)
[11:48] <james_w> lifeless: review done
[11:49] <james_w> thanks for working on this
[12:02] <bialix> bzr guru I have a question about bzrdir.sprout
[12:03] <bialix> Bug 458914
[12:03] <bialix> I have following code in scmproj to clone control branch
[12:04] <bialix> http://pastebin.com/d5939252d
[12:04] <bialix> this code using sprout
[12:04] <bialix> as result it does not filter out unrelated revisions when cloning branch
[12:05] <bialix> but get entire shared repo
[12:05] <bialix> what I'm doing wrong?
[12:10] <vila> bialix: why don't you use branch.fetch() instead ? And why does your comment talks about creating a working tree for force_new_repo ?
[12:10] <bialix> I dunno, that code was written by amanica
[12:10] <bialix> I don't understand how sprout works
[12:10] <vila> :-/
[12:11] <bialix> that code invoked this way: http://pastebin.com/d41766d3d
[12:12] <bialix> wait
[12:12] <bialix> are you asking about comment after force_new_repo=True ?
[12:12] <bialix> vila: ^
[12:12] <vila> yes
[12:13] <bialix> the idea was is to create standalone branch always, regardless of presence of shared repo
[12:13] <vila> bialix: especially when sprout has a _create_tree_if_local parameter...
[12:13] <vila> ha
[12:13] <bialix> _create_tree has leading underscore, therefore it's private API
[12:14] <bialix> last time you was very hard that gary using private api in qbzr
[12:14] <vila> meh, no underscore, sorry typo
[12:14] <bialix> that code was written last winter, perhaps bzrlib evolved since then
[12:15] <vila> rhaa, I wasn't hard at all ! You misunderstood my intent, but nm
[12:16] <vila> bialix: you may want to use the revision_id parameter too
[12:16] <vila>         if revision_id is not None, then the clone operation may tune
[12:16] <vila>             itself to download less data.
[12:18] <vila> bialix: your caller certainly can get that from br_from.last_revision_info
[12:22] <bialix> vila: hmmm
[12:22] <bialix> strange
[12:25] <bialix> vila: so I need to change my clone fuinction?
[12:26] <vila> I'd say so...
[12:27] <bialix> :-/
[12:28] <bialix> so I need to make function as     def _clone_to_local_url(br_from, revisions_id, to_url, accelerator_tree=None):
[12:28] <bialix> vila: ^, right?
[12:29] <bialix> and pass revision_id to sprout?
[12:29] <vila> revision_id, no 's' , but yes, I'd try that
[12:29] <vila> bialix: do you have any evidence that this bug is recent or was it always there but unnoticed ?
[12:31] <bialix> my coworker just today discovered this
[12:31] <bialix> I think it was there always
[12:32] <bialix> but he has non-standard scmproj project clone
[12:32] <bialix> .scmproj should be standalone tree, we forcing this
[12:32] <bialix> but he made by hands this branch using shared repo
[12:32] <bialix> so it's not very critical but I'd like to fix it
[12:34]  * bialix trying what vila suggested
[12:34] <vila> Peng: ping !
[12:34] <bialix> Ping: peng
[12:35] <vila> Peng: just noticed bug #458743 and bug #458741
[12:36] <vila> Peng: I've been bitten by the problem in another way and I just proposed lp:~vila/bzr/353370-notty-no-term-width
[12:36] <vila> Peng: your feedback will be highly welcome
[12:36] <vila> Peng: oh, and more info at bug #353370
[12:38] <bialix> vila: branch.py suggests that I can obtain rev_id tip by br_from.last_revision() call. ok?
[12:38] <vila> bialix: yup
[12:39] <bialix> cool
[12:42] <bialix> vila: many many thanks
[12:42] <bialix> merci
[12:42] <bialix> it working
[12:43] <vila> bialix: \o/
[12:43] <bialix> all hail vila!
[12:43] <vila> :-D
[12:46]  * bialix mutters: that's new ajax lp made me crazy
[12:48] <Peng_> vila: AIUI (skimming things) your patch drops the no-TTY width from 65,536 to 256. My terminal is ~130 columns wide, so it should still get spammed, just a lot less.
[12:48] <Peng_> vila: Is that correct?
[12:48] <vila> Peng: not only, it changes the way is obtained in more cases
[12:48] <vila> Peng: not only, it changes the way the width is obtained in more cases
[12:49] <vila> Peng: can you try it ?
[12:49] <vila> err, which Peng are you ? Peng or Peng_ ? :)
[12:50] <Peng_> Oh look, I have $COLUMNS. 183? Didn't remember it was that high.
[12:50] <Peng_> vila: Both.
[12:50] <Peng> vila: ...And neither!
[12:50] <vila> lol
[12:51] <vila> Right, so if you set COLUMNS, it's obeyed. Period.
[12:51] <Peng_> OK, both of my computers have $COLUMNS. If it works, I don't really care about the details. :P
[12:52] <Peng_> vila: I'll grab a copy of your branch.
[12:52] <vila> ok, I'll grab some food then :-)
[12:52]  * SamB_XP still wishes bzr paid attention to SIGWINCH
[12:54] <vila> SamB_XP: patches welcome !
[12:54] <SamB_XP> heck, I'm not even sure I made sure there was a bug about it!
[12:55] <vila> SamB_XP: see.... :-D
[12:56] <bialix> vila: thanks again, you my hero
[12:57] <Peng_> That brings it to 4 branches I have merged to my bzr.dev. :D
[13:00] <Peng_> vila: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one.
[13:02] <Peng_> vila: when piped to less, anyway
[13:02] <Peng_> vila: This is an improvement, obviously, but it's still worse than the old code.
[13:04] <vila> Peng: with or without COLUMN being set ?
[13:04] <vila> COLUMNS
[13:06] <Peng_> vila: with
[13:06] <vila> Peng: and is the value coherent with your terminal ?
[13:06] <vila> i.e. <=
[13:09] <Peng_> vila: Yes.
[13:10] <vila> Peng: you said earlier that COLUMNS was set to 183 and your terminal ~130, right ?
[13:11] <vila> anyway, try to either *not* set COLUMNS or set it to a value that is *less* than your terminal width
[13:12] <vila> Peng: regarding #458741, can you tell me how to reproduce that ?
[13:13] <Peng_> vila: I just sent an email. All I did was "bzr selftest --parallel subprocess".
[13:14] <Peng_> vila: Well, to be exact I did "bzr selftest --parallel subprocess pending".
[13:14]  * Peng_ runs off to watch TV. I'll check in at ad breaks, though.
[13:15] <vila> ok, I can reproduce now, that's fixed with my patch
[13:15] <Peng_> Ohh, why is there always an ad break right when I get up?
[13:15] <vila> Peng: at your next break, can you precisely tell me what width your terminal is, what COLUMNS value you use and if you still experience a problem
[13:15] <Peng_> vila: 183, 183, and which problem? The selftest one? I'll check.
[13:16] <vila> the selftest one is fixed, just checkd it
[13:16] <Peng_> vila: Yeah, I can confirm it.
[13:17] <Peng_> vila: Which problem do you want me to check?
[13:17] <vila> You said: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one.
[13:18] <vila> I can't reproduce that
[13:18] <Peng_> vila: Oh. ...Show's back.
[13:18] <Peng_> vila: Anyway, that's with latest-everything, including your branch. And 3 others, but they shouldn't break this.
[13:19] <vila> ghaaa, I want a recipe to reproduce !!! :D
[13:19] <vila> ha, got it, if COLUMNS >> terminal_width I can see that, but if I use COLUMNS==terminal_width it's not the case, please double check
[13:21] <vila> and if COLUMNS >> terminal_width, well, it's kind of expected, if the terminal issue a linefeed, there is no way bzr can uses carriage returns to erase the current line (since it has become the previous line...)
[13:23] <vila> hmm, so, to be pedantically precise, the bug occurs if you set COLUMNS=terminal_width+2, so there probably is a off-by-one error somewhere
[13:23] <vila> Peng: but it also very probably means COLUMNS is not set the way you think it is :)
[13:29] <Peng_> Hmm.
[13:30] <Peng_> vila: $COLUMNS is right.
[13:30] <Peng_> vila: Also, like I said, it only happens when I pipe to less.
[13:30] <Peng_> vila: ....Now I can't reproduce it.
[13:31] <vila> Peng: haaaaa, I prefer that :-) THanks !
[13:31] <Peng_> vila: Sorry, I was wrong. I can reproduce it.
[13:32] <Peng_> vila: It works fine if I do "COLUMNS=183 bzr pull -v | less -F", but fails if I just do "bzr pull -v | less -F". Even though $COLUMNS is 183 anyway.
[13:32] <vila> >-/
[13:32] <Peng_> Sorry. :P
[13:34] <vila> env | grep COLUMNS
[13:34] <vila> vila:~/src/bzr/releases/2.0 :( $ echo $COLUMNS
[13:34] <vila> 80
[13:34] <vila> meh....
[13:35] <vila> Peng: Can you try COLUMNS=182
[13:35] <Peng_> vila: "export COLUMNS=182; bzr pull -v | less -F" works.
[13:35] <vila> Peng: amazing isn't it ?
[13:36] <vila> so it's *another* off-by-one error somewhere else
[13:36] <Peng_> vila: Bu I told you, 183 works. Sometimes.
[13:36] <Peng_> But*
[13:37] <Peng_> vila: "export COLUMNS=183; bzr pull -v | less -F" works too. Augh!
[13:39] <Peng_> vila: Ah-ha! "echo $COLUMNS" works, but "env" doesn't list COLUMNS.
[13:39] <vila> seems related to 'shopt -s checkwinsize' in my .bashrc
[13:39] <Peng_> vila: $TERMCAP does include the columns, though.
[13:40] <Peng_> Although I only have $TERMCAP inside of screen, but that's mostly where I run bzr anyway, so it's not a big deal.
[13:43] <vila> Peng: I'm pretty sure we are chasing a different bug here...
[13:45] <Peng_> vila: I dunno. What are we talking about?
[13:46] <vila> off-by-one errors bewtween terminal width and COLUMNS
[13:46] <vila> before my patch COLUMNS wasn't obeyed, so you didn't see these bugs
[13:50] <Peng_> So, um, hmm. Since it turns out I don't actually have $COLUMNS ("echo" lies), where does that put me?
[13:50] <Peng_> It's using the default of 156?
[13:50] <Peng_> 256*
[13:51] <vila> echo doesn't lie, try 'shopt' and search for checkwinsize
[13:51] <vila> if you do echo $COLUMNS and get something, so does bzr
[14:00] <Peng_> vila: echo really does lie. $COLUMNS is not listed in "env", or Python's os.environ.
[14:00] <Peng_> ...I hate computers. :P
[14:02]  * vila kills some more chickens
[14:19] <nyu> lifeless: thanks!
[15:13] <phoenixz> fullermd: Good morning!
[15:13] <phoenixz> fullermd: Just finished reading the other document you wrote
[15:22] <phoenixz> fullermd: I have to say, still not sure on how the init-repo thing works, though it seems cool..
[15:57] <dlee> Trying to use Bzr against an svn repo at http://opensource.adobe.com/svn/opensource/flex/sdk:  flex/sdk is the path in it, and it's from there laid out in "trunk" layout.  Read-only access requires no password, and this works with svn; but bzr insists on asking for one.
[15:58] <dlee> I gather that this is because bzr tries to determine layout by examining the root, but I must not have read access that far up.  Is there a solution to this?
[15:58] <jelmer> dlee: specify the layout manually
[15:58] <dlee> I've tried messing with ~/.bazaar/subversion.conf but it didn't help.  I may not have done that correctly.
[15:59] <jelmer> and disa ble the cache
[15:59] <dlee> Can I use bzr co/branch or do I need bzr svn-import?
[15:59] <dlee> The latter has a layout parameter; the former two don't I think
[16:00] <jelmer> you can set the layout in subversion.conf
[16:01] <jelmer> e.g. layout = trunk0
[16:01] <dlee> The 0 is new to me :) tried without.
[16:02] <jelmer> it shouldn't be necessray
[16:03] <dlee> My subversion.conf is just the [uid] line, layout=trunk (with or without 0), and locations = http://opensource.adobe.com/svn/opensource
[16:05] <jelmer> dlee: you'll also need to disable the cache
[16:05] <jelmer> dlee: 'use-cache = False'
[16:06] <dlee> in subversion.conf?
[16:06] <jelmer> yeah, in the uuid section
[16:07] <dlee> Hmm...still wants a user name.
[16:07] <dlee> tried co and svn-import, trying to check out both trunk and just flex/sdk
[16:07] <jelmer> can you send it ia sigquit and see what code path is tryuoing to access the repo root
[16:07] <jelmer> (apologies for my spelling today)
[16:09] <dlee> In the debugger, but I haven't been here before... what do you want from here?
[16:10] <cellofellow> I need to install bzr on a Mac that I don't have admin rights too. Is there some way I can do that?
[16:10] <Peng_> cellofellow: Worst case, run from source.
[16:11] <jelmer> dlee: 'bt' will print a backtrace
[16:12] <Peng_> cellofellow: You've tried the installer, and it failed without admin rights? http://bazaar-vcs.org/MacOSXDownloads
[16:15] <cellofellow> Peng_: it asked for them but I didn't just click cancel and see what happened.
[16:15] <cellofellow> if I click cancel it doesn't continue to the install
[16:17] <cellofellow> source it is I guess
[16:17] <dlee> Trying to sift out what matters... should I be suspicious at seeing "self._cached_revnum = self.transport.get_latest_revnum()"?
[16:17] <cellofellow> or just don't use it, I can commit from my laptop.
[16:20] <dlee> Looks like it happens when bzr tries to get the latest revnum.  Iirc, pasting large text chunks isn't appreciated in here, or I could paste some of the backtrace.
[16:24] <Peng_> dlee: Use a pastebin.
[16:27] <james_w> is there a way to do a backwards merge?
[16:27] <james_w> use case:
[16:28] <james_w> shared trunk with disconnected workflow
[16:28] <james_w> if there is a collision in pushing to the trunk then I get told the branches have diverged
[16:28] <james_w> if I merge trunk then it changes the left hand history of trunk
[16:29] <Tak> rebase?
[16:29] <james_w> the "correct" way to do it is to get another copy of trunk, update it, and then merge in
[16:29] <james_w> but that's a faf
[16:29] <james_w> if I could do "bzr merge", but just put the revision parents the other way around then I could do it in one directory couldn't I?
[16:30] <james_w> Tak: there's no need to rebase, and in fact I don't want to
[16:31] <dlee> Peng_ / Jelmer: I made a pastebin - never done that before either.
[16:32] <Peng_> dlee: What's the URL?
[16:33] <dlee> http://pastebin.com/m4e19701d
[16:35] <jelmer> dlee: looks like we try to open the repository root at the moment when we try to figure out the last revision number
[16:35] <jelmer> dlee: that's not really necessary, please file a bug
[16:36] <jelmer> sorry, gtg - breakfast
[16:36] <dlee> np and thanks
[16:41] <phoenixz> I have varios SVN repositories containing various implementations of one and the same inhouse developed framework. Simplified, I have repo A with the framework itself, as trunk, branches and tags, from there copied (using SVK), in repo B project B1, B2 and B3, and I have repo C with projects C1 and C2... When making updates to the framework while working in repo C, project 1, I merge those changes back to the framework in Repo A. When I have updates to the
[16:41] <phoenixz>  framework in repo A, I merge those changes to all projects in repos B and C.. I want to change from SVN / SVK to BZR. How can I import all these works from SVN / SVK to BRZ, keeping all the histories but also keeping the abilities to merge in between the various projects?
[16:45] <phoenixz> I know, SVN cannot copy cross-repository, but SVK can. Which is one of the reasons why I used SVK in the first place. Now, SVK is pretty much a dead project, and I want to jump ship, BZR seems like the perfect choice for me, but I would not want to loose the ability to merge in between projects..
[16:47] <jelmer> phoenixz: hi
[16:47] <phoenixz> jelmer: hi
[16:48] <jelmer> phoenixz: yes, if I understand your situation correctl bzr-svn should be able to handle that
[16:48] <jelmer> phoenixz: please note that you shouldn't be using the 'bzr dpush' command when attempting something like this
[16:49] <phoenixz> jelmer: I don't even know what dpush is or does, yet.. :)
[16:49] <jelmer> phoenixz: in that case, don't worry about it :-)
[16:49] <jelmer> phoenixz: dpush is the bzr-svn equivalent of "push but don't set svk:merge"
[16:49] <phoenixz> jelmer: haven't found dpush in bzr help commands..
[16:50] <phoenixz> jelmer: a question here..
[16:50] <phoenixz> so in subversion, I have varios projects
[16:51] <phoenixz> each project has a trunk, development branches and tags
[16:51] <phoenixz> pretty common way to work in SVN
[16:51] <phoenixz> I use this framework within different companies
[16:51] <phoenixz> for each company I have multiple projects that use that framework
[16:52] <phoenixz> for each company I have one SVN repository that contains the projects
[16:52] <phoenixz> like, /svn/companya/projecta/ (where companya is an SVN repo)
[16:52] <phoenixz> How do I set this up in BZR?
[16:53] <phoenixz> Because AFAIK, BZR has each branch being its own thing
[16:53] <phoenixz> there is a shared repo directory
[16:53] <phoenixz> where I can keep those branches together
[16:53] <phoenixz> so I figure, for each company, I would make a shared repository
[16:54] <phoenixz> and in there I would place directories for each project
[16:54] <phoenixz> and in those project directories, I would place the branches for each project
[16:54] <phoenixz> jelmer: does this make sense in BZR? or did I get it totally wrong?
[16:55] <dlee> Jelmer: Re: getting svn latest revno querying at repo root unnecessarily:  Bug #459187 filed.
[16:56] <Meths> Can bzr import from CVS?
[16:58] <Meths> nm, found bzr-cvsps-import
[17:01] <jelmer> dlee: Thanks
[17:01] <jelmer> Meths: you may also want to check out cvs2svn's fastexport option
[17:01] <jelmer> phoenixz: yeah, that should work
[17:02] <jelmer> phoenixz: I would recommend sticking to the standard layout for svn inside of those branch container directories
[17:02] <jelmer> phoenixz: because bzr-svn will automatically regonize what is a branch in that case
[17:03] <phoenixz> jelmer: another question.. Does BZR know if different branches are related? I suppose it does, but if I make a branch of a branch of a branch, etc etc.. will the last branch still know its related to the first one
[17:03] <phoenixz> ?
[17:03] <phoenixz> I know, noob questions.. :)
[17:03] <jam> Meths: or use 'cvs2bzr' from the 'cvs2svn' suite. Which will create a 'fast-import' stream, that you can import using 'bzr fast-import'.
[17:04] <jelmer> phoenixz: yes, it will know if different branches are related
[17:04] <phoenixz> jelmer: is it also possible to branch a sub directories? like, I have a project A with sub directory lib.. I want a branch of only lib, is that possible too?
[17:06] <jelmer> phoenixz: partial checkouts are possible but the related history with the partent branch will not be recognized
[17:10] <Meths> jelmer: jam: thanks.  How does bzr fast-import work?  bzr help fast-import isn't implemented
[17:10] <jelmer> Meths: you need the bzr-fastimport plugin
[17:11] <Meths> ah
[17:11] <jelmer> phoenixz: I'm out for the day. If you have more questions, please mail the list and cc me
[17:11] <vila> morning jam !
[17:11] <phoenixz> jelmer: thanks lots for the help so far!
[17:12] <vila> jam: I could spend a better week-end if I could land https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832
[17:12] <jam> hey vila
[17:12] <jam> I'm technically on vacation again today
[17:12] <jam> though I found a way to shrink mem by another ~50MB or so, so I can't stay away :)
[17:12] <vila> jam: ach, sorry again, but hey you're here again :)
[17:13] <jam> I'm not sure about trusting COLUMNS when isatty() is false
[17:13] <Tak> jelmer: btw, I figured out what the issue was with bzr-svn/subvertpy/md-bzr
[17:13] <vila> jam: well, the more I dig, the more I see COLUMN being set even when you don't touch it :-)
[17:13] <jam> certainly under 'less' you probably don't want to truncate
[17:13] <jam> even though Peng does
[17:13] <vila> Just try it in a terminal...
[17:13] <jam> vila: I'm pretty sure the terminal likes to set COLUMN / COLUMNS or whatever
[17:14] <jam> as a hint
[17:14] <vila> bash too
[17:14] <jam> vila: well bash has to get it from the terminal, rigth?
[17:14] <Tak> I wasn't invoking PyEval_InitThreads
[17:14] <jam> or perhaps it uses SIGWINCH, or TIO or whatever
[17:14] <vila> I dunno, surely they talk to each other, but that makes it even more reliable
[17:15] <jam> vila: right, and my point is if I do "bzr XXX > file"
[17:15] <jam> should it be paying attention to that?
[17:15] <jam> also note that for our purposes
[17:15] <jam> sys.stderr.isatty is probably more relevant
[17:15] <jam> I don't think we ever truncate stdout
[17:15] <jam> vila: can you verify that last statement?
[17:15] <vila> let's not open more cans than necessary....
[17:16] <vila> log --line is one know truncate case
[17:16] <jam> (stdout being valuable information that the command is generating, versus 'progress' etc information that can be truncated on a whim)
[17:16] <jam> vila: so my direct preference is "revert the 'bugfix"
[17:16] <jam> my second preference is "just set it to 256"
[17:17] <jam> my third is 'lets have a discussion and actually get this right"
[17:17] <vila> setting to 256 when using a tty is bad, I know that for sure
[17:17] <vila> ok, so I'll revert the offending revnos and wait more feeedback on the patch
[17:18] <Peng_> jam & vila: <3
[17:18] <jam> vila: but isatty() is False
[17:18] <jam> Or am I missing something
[17:18] <vila> jam: ECONTEXT
[17:19] <jam> (11:16:57 AM) vila: setting to 256 when using a tty is bad, I know that for sure
[17:19] <jam> You are setting it to 256 when "isatty()" is returning false
[17:19] <vila> yes
[17:20] <jam> hence "using a tty" but the system is telling us you aren't
[17:20] <vila> I was replying to: <my second preference is "just set it to 256">
[17:20] <jam> vila: I'm saying "set it to 256 when isatty() is False"
[17:20] <jam> I should have typed it all out, I guess
[17:20] <vila> ha ok, yes, that's what the patch does
[17:20] <jam> I was trying to say "change 65536 => 256"
[17:20] <jam> vila: and a bunch of other stuff
[17:21] <jam> My point is there is a one line 65536 => 256 change
[17:21] <jam> that seems to cover what you really need
[17:21] <vila> haaaa, I started with that, but them I realized there was other problems and that wasn't enough
[17:21] <vila> s/them/then/
[17:22] <vila> so, it's either, revert or fix them all
[17:22] <vila> well, for some values of all...
[17:23] <jam> vila: which is my point about (3)
[17:23] <jam> if we are going to spend significant time on it, lets do it the right way
[17:23] <jam> (and i feel stuff like checking sys.stderr is part of that, possibly handling SIGWINCH, possibly a few things)
[17:24] <vila> jam: ok, I thought I did that but by all means, let's discuss it widely :)
[17:24] <jam>  $COLUMNS concerns me, because doing something like:
[17:24] <vila> wow, wow, wow :)
[17:24] <jam> bzr log --line > file
[17:24] <jam> seems like it shouldn't truncate
[17:24] <jam> should bzr log --line | less?
[17:24] <jam> should we truncate a progress bar, but not log --line
[17:24] <jam> ?
[17:25] <vila> yeah, the truth is I started thinking COLUMNS wasn't set behind my back but *always* by the user, I'm less sure about that now
[17:26] <jam> vila: well if you resize your window
[17:26] <jam> COLUMNS is usually updated to match
[17:27] <jam> it just isn't updated 'on-the-fly' while the program is running
[17:27] <jam> hence SIGWINCH
[17:27] <vila> I thought you had to use termios, not COLUMNS for that... It appears I was wrong (still not completely sure, try:)
[17:28] <vila> try: env| grep COLUMNS
[17:28] <vila> then echo $COLUMNS
[17:28] <vila> then under python look at os.environ['COLUMNS']
[17:32] <jam> vila: I'm currently on Windows, which has fairly fixed column width for cmd.exe
[17:32] <jam> I can try it, I suppose
[17:33] <jam> echo "$COLUMNS" is empty for me
[17:34] <vila> Ach, windows, yeah, I have some pending questions there too... as pointed in some bugs bzr behaves differently wrt redirections on windows and linux...
[17:35] <jam> vila: well, there you have to also worry about '\r\n' and setmode(binary) etc.
[17:37] <vila> jam: on OSX: http://paste.ubuntu.com/299876/
[17:37] <jam> vila: pretty
[17:37] <jam> I like how it ends in a frown
[17:38] <vila> hehe
[17:38] <vila> on jaunty: http://paste.ubuntu.com/299877/
[17:38] <jam> hmm. same result
[17:38] <vila> yup
[17:40] <vila> on FreeBSD: http://paste.ubuntu.com/299879/
[17:40] <vila> some result too, except when set by the user, COLUMNS is not seen by python...
[17:40] <vila> I suppose *bash* knows about COLUMNS in some kind of way
[17:51] <Peng_> Oh, good, my weird results aren't unique.
[17:56] <jam> vila: go start enjoying your weekend
[17:56] <jam> :)
[17:57] <vila> jam: yeah, revert sent to pqm, I'll poke babune later :)
[17:57] <vila> jam: thanks, enjoy yours too when you decide it :)
[18:43] <jfroy|work> jelmer: ping-a-pong
[19:18] <Tak> if I set a command's outf to something other than stdout, will the file be closed automagically when the command is gced or no?
[19:23] <Tak> hmm, it looks like "no"
[19:55] <bialix> fullermd: ping
[20:31] <Kmos> hi
[20:31] <Kmos> kmos@kmos:~/packages/apport$ bzr push lp:apport
[20:31] <Kmos> bzr: ERROR: Cannot lock LockDir(lp-46086288:///~apport-hackers/apport/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
[20:31] <RenatoSilva> If I cerate an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and merge all-features into trunk, will only the new commits CONFLICT_N be merged from all-features into trunk?
[20:31] <Kmos> break-lock doesn't work
[20:32] <RenatoSilva> * If I create an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and then merge all-features into trunk, then will only these new commits CONFLICT_N be merged from all-features into trunk?
[20:32] <Kmos> RenatoSilva: don't repeat yourself
[20:33] <RenatoSilva> Kmos: Strictly speaking, I didn't ;)
[21:10] <Tak> hmm, if I have something in ~/.bazaar/plugins that I have a different version installed systemwide, will my local plugin override, or will there be a conflict?
[21:20] <lifeless> local wins
[21:27] <Tak> thanks
[22:18] <james_w> hi lifeless
[22:18] <lifeless> hi
[22:18] <james_w> thanks for making the changes
[22:19] <james_w> I haven't reviewed the incremental diff, but I don't foresee any problems
[22:19] <james_w> I just replied before seeing the mail that you had made them
[22:20] <lifeless> ok
[22:20] <lifeless> so I made the bits *I* consider a must given the things the review discussion uncovered
[22:20] <lifeless> I haven't change print to mutter, or other such things
[22:20] <james_w> as I said, I'm happy to take over if you are willing to block on me
[22:21] <lifeless> Well, I'm running from a homedir install now
[22:21] <lifeless> not going to block regardless
[22:21] <james_w> but as you are asking me to maintain the code I am wary of merging it with things that I can see being problematic
[22:21] <lifeless> so, I don't think there are things remaining that are problematic, just differnet
[22:21] <lifeless> with the sole exception of the oauth file
[22:22] <lifeless> and I think that all of that should be in launchpadlib *anyway*
[22:22] <lifeless> its fugly the way the setup stuff is cargo culted around
[22:22] <james_w> I pointed to the API for that
[22:22] <james_w> did you take a look at whether it matched?
[22:23] <lifeless> no, its saturday ;P
[22:23] <lifeless> and I don't understand enough to know if it matches or not.
[22:23] <james_w> fair enough
[22:23] <lifeless> the whole launchpadlib thing is rather opaque to me
[22:23] <lifeless> the pydoc is epic epic epic fail
[22:24] <lifeless> and the total inability to work and test with it offline (Without a multi-hundred mb separate download & apache locally) is a real disincentive to learn more
[22:24] <lifeless> so there is also a bit of passive resistance to learning more:P
[22:25] <james_w> pydoc launchpadlib.launchpad
[22:25] <james_w>  /login_with
[22:25] <james_w> if you are interested
[22:25] <lifeless> heh
[22:25] <lifeless> so this is actual code and documented ;)
[22:27] <lifeless> so, login_with looks fine, but given that I know nothing about the failure modes, internals, required facilities, expected conventions...
[22:27] <james_w> the only issue with it is that it puts the cache in "launchpadlib_dir"
[22:27] <lifeless> my approval doesn't mean much
[22:28] <james_w> and currently the cache is broken with multiple processes
[22:28] <lifeless> Oh, I really hate the cache
[22:28] <lifeless> it shouldn't need one.
[22:28] <james_w> because?
[22:28] <lifeless> Damn silly idea, HTTP caches are extremely hard to get right.
[22:29] <lifeless> build the API by introspecting the wsdl and compiling python from it; then ship the resulting static API, which is fully documented and faster
[22:29] <lifeless> I say HTTP caches are hard to get right after years as squid-core :), its an informed opinion.
[22:32] <lifeless> also, if you need an HTTP cache for a web services API to work, the API design is broken and will perform problematically [because of cache seeding overhead at a minimum]
[22:33] <james_w> bug 459418 filed as due dilligence
[22:33] <lifeless> what else, oh, require write access means you can't use launchpadlib as a very restricted user, or [for instance] to grab backup data during system restore when nothing is mounted writable
[22:34] <lifeless> s/require/requiring/
[22:34] <james_w> I can now go back to moaning about how login_with is broken with a clear conscience
[22:34] <lifeless> :)
[22:35] <james_w> anyhow, I shall make some time to merge your code at some point
[22:35] <james_w> thanks again
[22:35] <lifeless> that would be excellent
[22:37] <lifeless> I'd lke to be running a packaged bzr-builder
[22:38] <lifeless> the less string the easier to get OSA's to run the service ;)
[22:51] <jfroy|work> http://trac.webkit.org/changeset/50000
[22:51] <jfroy|work> uuuuarg oops
[22:51]  * jfroy|work hides in shame
[22:51] <jfroy|work> defeated by too many tabs, once agao
[22:51] <jfroy|work> *again. I apologize.
[22:59] <jfroy|work> jelmer: ok I have the weirdest problem with bzr-svn
[23:00] <jfroy|work> well, it seems to me that way. I have a completely clean repository with no bzr: props or revprops and no svn:mergeinfo or svk:merge props.
[23:00] <jelmer> jfroy|work: are you psychic? I just returned back to my computer after being away for half a day and you ask within a couple of seconds :-)
[23:01] <jfroy|work> and a straight bzr branch of the trunk branch in that repo yields a bazaar branch with a number of sha1 mismatch errors
[23:01] <jfroy|work> lol :p
[23:01] <jfroy|work> no, I'm pretty sure I'm not :p
[23:02] <jfroy|work> basically, we're migrating a project from a repo with a bunch of projects in it to a brand new repo dedicated to only one project
[23:04] <jfroy|work> so I 1) branched using bzr the trunk and the current active branches from the old svn repo 2) pushed trunk (with the push merged revision option enabled) to a simulation blank svn repo 3) dumped that 4) ran a filter on the dump to strip every revprop and prop starting with bzr: (as well as svn:mergeinfo and svk:merge) 5) loaded that filtered dump into a new repo and 6) branched the trunk from that repo
[23:04] <jelmer> did you change the UUID or throw away the cache?
[23:04] <jfroy|work> that should yield a clean bzr branch, shouldn't it?
[23:04] <jfroy|work> pretty sure I did
[23:05] <jfroy|work> ~/.bazaar/svn-cache/ and ~/.bazaar/subversion.conf
[23:05] <jfroy|work> And I get a "Initialising Subversion metadata cache" message when branching
[23:06] <jfroy|work> I'm guessing the only thing left that could trip bzr-svn are copy nodes it's trying to interpret
[23:06] <jfroy|work> I don't think there's anything that can be done about those
[23:07] <jelmer> can you reproduce the problem on a small repo?
[23:08] <jfroy|work> I have no idea how to reproduce this
[23:09] <jfroy|work> oi, wait a second...
[23:10] <jfroy|work> these are the sha1 mismatches
[23:10] <jfroy|work> http://paste.ubuntu.com/300096/
[23:10] <jelmer> can you pastebin the backtrace?
[23:10] <jfroy|work> no backtrace
[23:11] <jfroy|work> this is output by bzr check
[23:11] <jfroy|work> All of those files are symbolic links
[23:11] <jfroy|work> I think this is the problem
[23:11] <jelmer> ah, that might make sense
[23:11] <jelmer> That should be a relatively trivial bzr-svn bug
[23:11] <jfroy|work> those 4 files are all empty with Property svn:special set to *
[23:12] <jfroy|work> and the content set to "link Versions/Current/ATF"
[23:12] <jelmer> we're just filling in a different sha1 in the inventory as we put in the versionedfiles
[23:12] <jfroy|work> s/ATF/foo
[23:12] <jelmer> jfroy|work: can you file a bug?
[23:12] <jelmer> jfroy|work: :-)
[23:12] <jfroy|work> let me try to repro with a simple repo
[23:13] <jelmer> jfroy|work: I have some long flights coming up, might give me something to do :-)
[23:13] <jfroy|work> That would be incredibly awesome :)
[23:17] <jfroy|work> yup
[23:17] <jfroy|work> reproduced with a one commit repo
[23:22] <jfroy|work> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/459440
[23:23] <jelmer> jfroy|work: awesome, thanks
[23:26] <jfroy|work> jelmer: oh, I've found another minor issue
[23:27] <jfroy|work> if you create a brand new repo and push a branch to <repo url>/trunk, you won't get any tags (but branches will show up if you have push merged revisions)
[23:27] <jelmer> jfroy|work: please file a bug for that one as well
[23:27] <jelmer> jfroy|work: and thanks :-)
[23:27] <jfroy|work> if, however, you create a revision 1 with svn that creates the standard layout, then push --overwrite, then you'll get tags
[23:28] <jfroy|work> I'm guessing it doesn't detect that the repo is using the standard layout
[23:28] <jfroy|work> probably needs a "repo is at revision 0, I should make the standard layout first" special case
[23:29] <jelmer> I suspect it's because we have a different code for "create this branch" vs "push revisions to this existing branch"
[23:33] <jfroy|work> https://bugs.launchpad.net/bzr-svn/+bug/459444