[00:00] <lifeless> jelmer: or possibly an ordering bug in branch --stacked etc
[00:00] <lifeless> jelmer: uhm find the call point that does the fetch
[00:01] <jelmer> lifeless: Svn's fetcher is being called before any data has been fetched
[00:01] <lifeless> btw, if they allow data access, they aren't Fake objects :P
[00:01] <lifeless> virtual
[00:01] <lifeless> or svnbacked
[00:01] <lifeless> but not fake
[00:02] <lifeless> whats calling the svn fetcher?
[00:02] <jelmer> heh, true
[00:02] <jelmer> bzrdir.sprout() iirc
[00:05] <krow> lifeless: No idea, someone else made it/sent it via email.
[00:05] <jelmer> uhm, is self._pack_collection.revision_index.combined_index supposed to be accessing fallback repositories?
[00:07] <krow> lifeless: Thanks... I am going to send back the results to the user to figure out.
[00:07] <lifeless> krow: so
[00:07] <lifeless> krow: let me give you a little info
[00:07] <lifeless> krow: say you have three branches
[00:07] <lifeless> TRUNK
[00:07] <lifeless> my-branch
[00:07] <lifeless> your-branch
[00:08] <lifeless> 'bzr send' is used to create a patch, which contains a _bundle_ of data
[00:08] <lifeless> for me to send some commits from my-branch to you
[00:09] <lifeless> bzr could either give you a full copy of my-branch (bad, lots of data), or we can send the data since some common point of reference that we both share
[00:09] <krow> ok
[00:09] <lifeless> so the send command wants a branch that it can use to determine that common point of reference
[00:09] <lifeless> now, if someone cherrypicks - if they say -r x..y
[00:10] <lifeless> this *still applies* - because bzr needs enough data in the patch to verify that noone edited it in transit
[00:10] <lifeless> so it actually includes common_rev..y, but knows that when you merge from it you only want x..y in the merge
[00:11] <lifeless> I bet that your user did something like this:
[00:11] <lifeless> 'bzr send . -r x..y'
[00:11] <lifeless> (where . says 'the SUBMIT_BRANCH is my current branch'
[00:12] <lifeless> this caused the problem, because bzr said 'oh, *everyone* has all the data, I just need to include the instruction
[00:12] <lifeless> (rather than finding the common point between 'my-branch and TRUNK' it was the common point between 'my-branch and my-branch'
[00:12] <lifeless> so the solution is to do 'bzr send -r x..y TRUNK'
[00:13] <lifeless> and it will all be good
[00:13] <lifeless> I hope that made sense and will help
[00:14] <jelmer> lifeless: Is Repository.has_revisions() supposed to be querying fallback repositories?
[00:14] <lifeless> jelmer: of course, if they are absent locally
[00:14] <krow> lifeless: It does... I assume there is no way to recover this patch?
[00:15] <lifeless> krow: not and maintain the commit metadata/revision id etc
[00:16] <lifeless> krow: if you really just want the textual patch you see at the top 'bzr patch /tmp/patch'
[00:19] <jelmer> hmm, something funny is happening here
[00:19] <lifeless> jelmer: here is the stacking expectation:
[00:19] <lifeless> jelmer: data available locally is used before data available remotely
[00:19] <lifeless> jelmer: queries are only made for remote data when it is needed
[00:19] <lifeless> jelmer: few complex queries are preferred over many small ones
[00:20] <lifeless> jelmer: so whats triggering the fetcher
[00:20] <lifeless> ?
[00:21] <jelmer> lifeless: Trying to figure that out atm
[00:21] <lifeless> 'bt' ?
[00:21] <lifeless> back in 15-20
[00:21] <jelmer> you mean, what's starting the fetcher?
[00:21] <jelmer> or what's causing it to fetch non-tip revisions?
[00:22] <jelmer> bzrdir.sprout() is starting the fetcher
[00:25] <lifeless> jelmer: and is the repository stacked at that point?
[00:25] <jelmer> lifeless: Yes
[00:25] <jelmer> lifeless, has_revisions() doesn't appear to go to the fallback repository
[00:26] <lifeless> jelmer: oh
[00:26] <lifeless> delete pack_repo.py's has_revisions
[00:27] <jelmer> woot
[00:27] <jelmer> lifeless, that did it
[00:27] <jelmer> not that it works, but I get a different error now
[00:28] <lifeless> jelmer: :P
[00:28] <jelmer> NotImplementedError: <bound method SvnTexts.get_parent_map of <bzrlib.plugins.svn.versionedfiles.SvnTexts object at 0x8d830cc>>
[00:36] <jelmer> lifeless: in self.texts.get_parent_map(), is it required to return more than the lhs parent?
[00:38] <lifeless> yes
[00:39] <lifeless> if you don't per-file log will be fucked
[00:39] <lifeless> and check will fail
[00:39] <lifeless> bbiab
[00:40] <jelmer> hmm, that sucks
[00:51] <jelmer> lifeless: It would be nice if there was some way to override build_tree() to just call revision_tree()
[00:52] <jelmer> rather than using iter_file_bytes(), etc
[01:04] <lifeless> jelmer: if you need that; patch it :)
[01:05] <jelmer> heh
[01:05] <lifeless> jelmer: but really, you should be able to do iter_file_bytes efficiently for merge and other operations as well
[01:05] <lifeless> going to a movie - laters
[01:05] <jelmer> lifeless: Merge from svn you mean?
[01:06] <lifeless> merge from bzr
[01:06] <lifeless> when the base of any text is in svn
[01:06] <jelmer> That's always going to be significantly slower
[01:06] <jelmer> svn's protocol is very tree-oriented
[01:07] <jelmer> For now, I'll just return None for parents
[01:07] <jelmer> enjoy your movie!
[01:08] <jelmer> which one are you going to?
[01:10] <lifeless> get smart
[02:12] <markh> jam: you here?
[02:19] <bob2> hm, the smart server isn't working for me at all at head
[02:34] <markh> when connecting via ssh to launchpad, I'm seeing 'Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)', then the connection is (successfully) retried.  Is that "expected" (ie, is there any reason to believe the binaries I'm putting together are incorrect because of this?)
[02:35] <Peng> markh: It's correct. Protocol v3 is very new.
[02:36] <Peng> markh: (That is, I think it might be even newer than 1.6b2. I'm not sure.)
[02:36] <markh> Peng: thanks.  I wonder if the binaries I'm making should be from 1.6b2 rather than what is on the head when I happen to flick the switch...
[02:37]  * Peng shrugs.
[02:37] <Peng> I use bzr.dev all the time.
[02:37] <markh> me too :)  Thats something I can decide later though :)
[02:37] <markh> ssh issues on windows are still driving me nuts too, so I better get back to that...
[02:37] <Peng> It might be good to package the revision before VersionedFiles, though, since that's a big API change and breaks many plugins.
[02:38] <markh> these are binaries for windows, where a good plug story remains to be written anyway :)
[02:39] <markh> by the time we would out to package them reasonably, hopefully they will all then be working again!
[02:39] <markh> s/would/work/
[02:48] <markh> does bzr cache passwords used for the "lp:" protocol?
[02:51] <jelmer> lifeless: W00T
[02:51] <jelmer> ganieda:/data/tmp/stackable% BZR_PDB=1 ~/bzr/shallow-branch/bzr -Dfakevf branch --stacked svn://svn.gnome.org/svn/gnome-specimen/trunk tr-sp
[02:51] <jelmer> Initialising Subversion metadata cache in /home/jelmer/.bazaar/svn-cache-exp/203ae883-c723-44c9-aabd-cb56e4f81c9a
[02:51] <jelmer> using experimental bzr-svn mappings; output may change between revisions
[02:51] <jelmer> Created new stacked branch referring to svn://svn.gnome.org/svn/gnome-specimen/trunk.
[02:52] <jelmer> and bzr info actually shows there are 0 revisions in the local repository
[02:58]  * markh thinks maybe it caches a certificate...
[03:05] <spiv> jelmer: sweet
[03:16] <baco> which is the difference between sftp and bzr+ssh schemes?
[03:17] <spiv> baco: bzr+ssh is a protocol native to bzr.  It runs bzr on the remote end.
[03:17] <spiv> sftp is just standard sftp, so while it tends to be a little bit slower, it also works with every SSH server, even if bzr isn't installed on the server.
[03:18] <baco> spiv: like the commits being made locally in bzr+ssh?
[03:18] <spiv> I'm not sure what you mean.
[03:19] <spiv> The behaviour is the same, just bzr+ssh tends to be faster.
[03:19] <spiv> The downside is that it needs bzr installed on the server.
[03:20] <baco> sftp uses ssh an then ftp on the remote end
[03:20] <Peng> SFTP is not FTP.
[03:20] <Peng> It's similar, but it doesn't just SSH in and run FTP.
[03:22] <spiv> SFTP also doesn't have the weird control channel/data channel split that FTP has.
[03:23] <baco> let figure it out, with sftp you *put* your files on the remote server, and with bzr+ssh you make an ssh connection, you send a stream which is captured an then piped to bzr to make the commit real on the remote end?
[03:24] <Peng> It's not that simple, but basically yeah.
[03:25] <baco> then, on server side, the auth via ssh is the same, but in bzr+ssh you also need the command line client installed
[03:26] <Peng> Yes.
[03:27] <baco> the only options now working for auth on the server side are the provided by apache via http or ssh via ssh ones?
[03:28] <Peng> Yes.
[03:28] <baco> tnx
[03:56] <baco> I've been trying thins on launchpad, does the setting of the main branch affect the repo in any way? I mean, you really set that on the repo, or is just launchpad magic?
[03:57] <Peng> If I understand you correctly, it's just Launchpad stuff.
[03:58] <baco> So, there's no way you set a branch as the default or main one so when you branch the repo url you get only this branch in a normal setting
[03:59] <spiv> baco: you don't branch repos, you branch branches :)
[04:00] <baco> ok, I usually, but not on lp, I mean you have the option not to
[04:01] <Peng> What?
[04:03] <baco> that in launchpad you have the option of branching a project, which is a repo, and it gives you one branch, the one has been declared as the main one
[04:04] <lifeless> hi spiv
[04:04] <lifeless> jelmer: congrats!
[04:05] <jelmer> spiv, lifeless: thanks
[04:05] <jelmer> lifeless: There's no rich-root-stackable format yet, right? I'm using devleopment-rich-root for now
[04:06] <lifeless> jelmer: thats stackable yes
[04:06] <jelmer> argh, it's getting late
[04:06] <lifeless> jelmer: there is no non-development stackable if thats what you are asking
[04:06] <jelmer> I meant development-subtree
[04:06] <lifeless> jelmer: hmm, we should add that
[04:06] <lifeless> jelmer: patch it up :P
[04:07] <jelmer> heh, some other day maybe :-P
[04:07] <lifeless> jelmer: still, fantastic news
[04:07] <baco> Peng: am I right?
[04:07] <lifeless> jelmer: should be trivial yo add development-rich-root
[04:07] <jelmer> Performance on operations like log in this branch is pretty terrible right now, though that was to be expected
[04:08] <lifeless> jelmer: so we need to fix that; log --short shouldn't be terrible though
[04:11] <jelmer> lifeless, it's worse than usual though
[04:11] <jelmer> as it's accessing these objects as XML
[04:11] <jelmer> rather than calling get_revisions() directly, avoiding a conversion back and forth
[04:12] <lifeless> jelmer: yeah; so stacking in a semantic fashion is actually significantly more work, as every layer needs to be taught
[04:12] <lifeless> jelmer: and every api needs to be stack-aware
[04:12] <jelmer> yeah
[04:13] <jelmer> lifeless, I also had to disable packrepo's get_parent_map implementation btw
[04:14] <lifeless> jelmer: right, please turn those into patches
[04:14] <lifeless> jelmer: they should not be needed with the thinner layers of VersionedFiles
[04:14] <Peng> bac: No. You only branch branches, not repos.
[04:14] <Peng> bac: Are you talking about "lp:" URLs?
[04:14] <Peng> Augh, crap.
[04:14] <baco> Peng: yes
[04:14] <Peng> I'm sorry, bac. I meant baco.
[04:15] <baco> understood :-)
[04:15] <bac> Peng: np  :)
[04:15] <Peng> Usually it's safe to tab-complete three characters. Whoops.
[04:15] <baco> LOL
[04:16] <Peng> baco: When you use "lp:myproject", the launchpad plugin (which comes with bzr) translates that to bzr+ssh://you@bazaar.launchpad.net/~you/myproject/trunk or whatever branch it refers to.
[04:17] <Peng> baco: This has nothing to do with repos having default branches or anything.
[04:17] <baco> Peng: ok, tnx
[04:38] <jelmer> spiv: It looks like a python clone is significantly faster now, btw
[04:39] <spiv> jelmer: sweet
[04:39] <jelmer> spiv: about 1500 revisions in the first 5 minutes (not involving stacked branches)
[04:40] <spiv> Not bad!
[05:10] <lifeless> jelmer: if you support texts properly now
[05:10] <lifeless> jelmer: try bzr-search, and disable 'revisions_only' for svn
[05:10] <pfharlock> if I wanted to remove a change that happend awhile back (say the repo is on version 11) and I wanted to undo whatever happened in rev 3, in svn I would do something like svn merge -r 3:2 followed by any tweaking and then commit.  What would be the best way to do this in bazaar?
[05:10] <lifeless> pfharlock: exactly that
[05:10] <lifeless> but with .. instead of :
[05:11] <pfharlock> yeah, but when I try bzr merge -r 3..2 it doesn't do what I would expect
[05:11] <lifeless> pfharlock: what does it do ?
[05:11] <lifeless> pfharlock: oh, you probably want 'bzr merge -r 3..2 .'
[05:12] <pfharlock> well the revision in question I added a file, I would expect the file to be marked for removal
[05:12] <pfharlock> oh, what does the . do
[05:12] <lifeless> its merges from the current branch
[05:12] <lifeless> rather than from the parent branch
[05:12] <pfharlock> duh
[05:12] <pfharlock> thanks
[05:12] <pfharlock> let me try that
[05:14] <lifeless> jelmer: oh, just remembered, I haven't dont VersionedFiles for bzr-search yet.
[05:14] <lifeless> jelmer: I will today probably
[05:14] <pfharlock> yes, that worked like I expected, thanks a bunch
[05:15] <lifeless> cool
[05:20] <pfharlock> if I wanted to pull the history/log or an entire repository, not just a branch, is there a way to do that, either builtin or through plugin?
[05:21] <pfharlock> s/or/of
[05:22] <pfharlock> I've been contemplating writing a script to do it if one doesn't already exist
[05:22] <lifeless> there are plugins
[05:22] <lifeless> the underlying api can do it of course, but unreferenced revisions are just garbage pending gc
[05:24] <markh> jam: ping
[05:24] <pfharlock> you'll have to forgive me, I'm not familiar with bzr's internals, but that's interesting, if you delete a branch with a bunch of revisions, they'll be removed from the shared repo automatically after awhile through garbage collection?
[05:25] <lifeless> pfharlock: yes, we don't guarantee preservation or timely gc, what we do guarantee is that referenced data is preserved, and unreferenced data is not cloned
[05:26] <lifeless> on my TODO is to write an efficient gc to give people direct control over this in case they need it
[05:26] <pfharlock> wow, that's pretty cool, other than deleting a branch, what could cause a revision to become unreferenced?
[05:27] <pfharlock> I would guess that uncommit might do it
[05:27] <Odd_Bloke> pfharlock: Rebasing, I think.
[05:28] <pfharlock> ok, that makes sense (not knowing how the rebasing plugin does it's magic :)
[05:29] <Odd_Bloke> pfharlock: Yeah, I only have vague recollections, but it's the sort of operation that might. :)
[05:29] <lifeless> uncommit
[05:29] <lifeless> and rebasing
[05:31] <pfharlock> as to repo-wide log, one of my common use cases is not remembering where something is I know I worked on months ago and searching the logs looking for whatever it is.  I realized the other day that if I wanted to duplicate this workflow that I use from subversion to bazaar I would need to get history from the whole shared repo.
[05:32] <pfharlock> I'm not sure what the best way to order the logs would be, my thought is that organizing it chronologically would probably be best.
[05:33] <lifeless> pfharlock: hmm, I would say 'bzr search' :)
[05:35] <pfharlock> cool, thanks, I'll give that one a try :)
[05:40] <lifeless> pfharlock: its a plugin, it currently searches per-branch
[05:40] <lifeless> pfharlock: but once indexed the searches are subsecond
[05:41] <pfharlock> yeah, I'm looking for repo-wide, but if it's close to what I need, maybe I can modify it to be repo wide
[05:41] <lifeless> yup
[05:41] <lifeless> the index is agnostic as to where content comes from
[05:41] <pfharlock> would be a good primer on how to start programming for bzrlib
[05:41] <lifeless> so you should be able to quite easily tweak it; and I'd be happy to accept any patch (though I might ask for tweaks to fit in with $plans)
[05:42] <pfharlock> very cool :)
[05:42] <pfharlock> if I get anywhere with that I'll get in touch, are you the author of the search plugin?
[05:42] <lifeless> sure am
[05:44] <pfharlock> cool, well thanks for all the help, it's greatly appreciated
[05:47] <Odd_Bloke> For anyone who's around, I'm going to be sending an email tomorrow asking for input on what I should be working on for PQM this summer.  Already on my list are XMLRPC submissions and getting rid of the crufty VCS abstraction.  Existing ideas (from the London sprint) are at http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms#head-f2678f1f3acd54a5199c577538301a91be6f7915-2 but I'm looking for some idea of which of those are most important.
[05:47] <Odd_Bloke> And with that wall of text, I shall head to bed.
[05:49] <lifeless> Odd_Bloke: pqm's bugs are a good place to look too
[07:12] <dbmoodb__> hi i'm new to bzr i ran bzr branch lp:bzr-search .... so i now have what-- i'm trying to use what i just got
[07:12] <dbmoodb__> yes i am an idiot
[07:14] <dbmoodb__> don't worry i am an idiot
[07:14] <dbmoodb__> fixed
[07:17] <AfC> dbmoodb__: no need to beat up on yourself. Everyone has to learn things the first time at some point.
[07:20] <lifeless> dbmoodb__: hi
[07:21] <dbmoodb__> oh hi
[07:21] <dbmoodb__> ah to use your nice little thing what do i need to do. i'm new to bzr and wanted to have a play. i can't use python2.5.
[07:22] <lifeless> thats fine, 2.4 should be enough
[07:22] <dbmoodb__> what are the packages required for bzr search ?
[07:22] <lifeless> have you got bzr installed ?
[07:22] <dbmoodb__> yes
[07:22] <lifeless> what version?
[07:22] <dbmoodb__> but i have python2.5 installed prior to this and hardy is trying to use python 2.5 even tho your setup says 2.4 i think
[07:22] <lifeless> oh
[07:23] <lifeless> ignore the setup.py for the plugin, thats for distro's that want to install it system
[07:23] <dbmoodb__> Bazaar (bzr) 1.3.1 Python interpreter: /usr/bin/python 2.5.2.final.0 Python standard library: /usr/lib/python2.5 bzrlib: /usr/lib/python2.5/site-packages/bzrlib
[07:23] <lifeless> wide
[07:23] <dbmoodb__> k sure i couldn't get that to work either :)
[07:23] <lifeless> dbmoodb__: it will work with 1.3.1 but print an error on every bzr command; if you can upgrade to 1.4 or newer that would be a good idea
[07:23] <lifeless> dbmoodb__: are you using ubuntu?
[07:23] <dbmoodb__> this is ubuntu hardy yes
[07:23] <lifeless> ok
[07:23] <lifeless> if you add
[07:24] <dbmoodb__> launchpad repo yah ?
[07:24] <lifeless> deb http://ppa.launchpad.net/bzr/ubuntu hardy main
[07:24] <lifeless> so your /etc/apt/sources.list
[07:24] <lifeless> it will give you the current release of bzr
[07:24] <lifeless> which is 1.5
[07:24] <dbmoodb__> lifeless: ok sure..... it would be nice to use it with what i currently have tho
[07:26] <lifeless> dbmoodb__: unfortunately I haven't written the backwards compatability stuff needed - 1.5 is disk and network compatible with 1.3 though. Is there some reason to stay on 1.3 ?
[07:26] <dbmoodb__> lifeless: so it will work with what i have just produce an error ?
[07:26] <AfC> dbmoodb__:  you're going to use Bazaar you might as well use the latest release. The version you will find published there will be significantly better than whatever was around when Ubuntu last froze its package set.
[07:26] <lifeless> dbmoodb__: yes
[07:26] <lifeless> dbmoodb__: it will also not auto-update the index when you commit/push/pull
[07:27] <lifeless> dbmoodb__: but if you're happy with those caveats then its ok by me :)(
[07:27] <dbmoodb__> lifeless: because thats in my release. sigh its still dev so ok !
[07:28] <dbmoodb__> i will add packages that have no gpg auth :)
[07:28] <lifeless> dbmoodb__: ah I see. we're going to get a backport done
[07:29] <dbmoodb__> lifeless: its still dev don't worry. but what you were saying was that it previously was using cron jobs and things.
[07:29] <lifeless> dbmoodb__: still; you don't have to upgrade to 1.4/1.5, its only a recommendation
[07:29] <dbmoodb__> that was because of the old bzr ?
[07:29] <dbmoodb__> lifeless: i have done it.
[07:29] <lifeless> dbmoodb__: *loggerhead* used to need all sorts of nastiness
[07:29] <lifeless> dbmoodb__: ok.
[07:29] <lifeless> https://edge.launchpad.net/bzr-search
[07:30] <lifeless> has install instructions for bzr-search
[07:30] <lifeless> (mkdir -p ~/.bazaar/plugins
[07:30] <lifeless> bzr branch lp:bzr-search ~/.bazaar/plugins/search
[07:30] <lifeless> )
[07:30] <dbmoodb__> do i have to be in the directory of the folder i am searching ? i see no option to search within an index that i have made
[07:31] <dbmoodb__> lifeless: yes but that page is hard to come by actually perhaps put an install / info in the read me (i know its dev just suggesting)
[07:31] <lifeless> dbmoodb__: yes, for the command line, cd to the branch you want to search -
[07:31] <lifeless> I'll add those to the README
[07:32] <dbmoodb__> lifeless: ok i wish to request a database of the indexes / file that says which indexes you have so one can autocomplete / use dirs / blah to search using your tool.
[07:32] <dbmoodb__> again -- i know its dev
[07:32] <lifeless> dbmoodb__: let me see if I understand
[07:33] <lifeless> you want a global list of the branches that you have indexed ?
[07:33] <dbmoodb__> that would be nice. given you intend for this to be networkable no ?
[07:34] <lifeless> well, it is networkable already using the same model bzr has
[07:35] <dbmoodb__> well autocompletion would be nice (of the ones you have done and perhaps a few suggested projects
[07:35] <lifeless> so, what would the global list help you do ?
[07:35] <dbmoodb__> lifeless: tab complete ?
[07:36] <lifeless> dbmoodb__: so, you're saying you could 'cd ~', 'bzr search -d <TAB>' - and it would list places you could search?
[07:37] <dbmoodb__> perhaps.
[07:37] <lifeless> I'm just trying to understand the use case
[07:37] <lifeless> I mean
[07:37] <lifeless> imagine you hack on openoffice, binutils and gcc
[07:38] <lifeless> you'll have branches of them that you edit code in
[07:38] <dbmoodb__> lifeless: it was a suggestion that is all. if you use firefox you can see how useful it is. however in this case there probably aren't that many things
[07:38] <dbmoodb__>     data, consumed = self.encode(object, self.errors)
[07:38] <dbmoodb__> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 21: ordinal not in range(128)
[07:39] <lifeless> dbmoodb__: can you get the backtrace from ~/.bzr.log ?
[07:39] <dbmoodb__> sure thing
[07:39] <Peng> (and don't paste it all in the channel!)
[07:40] <lifeless> dbmoodb__: I think what I'm saying is that the issue with finding previously used branches is much broader than bzr search
[07:40] <dbmoodb__> Peng: i only pasted that small amount and i was afriad of being kicked. sorry i will just query to paste this time
[07:40] <lifeless> dbmoodb__: http://rafb.net/paste/
[07:40] <Peng> dbmoodb__: Sure, pasting 2 lines is no problem. I was just making sure.
[07:41] <dbmoodb__> http://rafb.net/p/UEdy7J89.html
[07:42] <lifeless> dbmoodb__: ah ok
[07:42] <lifeless> dbmoodb__: your console is ascii
[07:42] <lifeless> dbmoodb__: but the search result was unicode, and it can't show it to you
[07:43] <lifeless> dbmoodb__: I'll file a bug for this; have you considered using a UTF8 locale ? (or perhaps I'm not analysing the error right).
[07:43] <dbmoodb__> http://rafb.net/p/o7XV9H92.html -- full thing. lifeless well my locale is the one setup for me by ubuntu isn't that utf8 ?
[07:43] <lifeless> ah yes, you do have UTF8 local
[07:43] <lifeless> ok, something different, one sec
[07:43] <lifeless> can you edit home/X/.bazaar/plugins/search/commands.py
[07:44] <dbmoodb__> yes. how so ?
[07:44] <lifeless> on the line before self.outf.write(" Summary: '%s'\n" % result.summary())
[07:44] <lifeless> insert
[07:44] <lifeless> print type(result.summary())
[07:44] <lifeless> print result.summary.decode('utf8')
[07:45] <lifeless> run it and pastebin the output
[07:47] <spiv> lifeless: the repr might be useful too
[07:47] <spiv> (And is usually ascii-clean)
[07:47] <lifeless> spiv: I'm betting I have utf8 data I'm tossing at outf
[07:47] <lifeless> but its doing implicit decode(ascii(
[07:48] <dbmoodb__> lifeless: it doesn't like my indentation :(
[07:48] <lifeless> dbmoodb__: use spaces and not tabs, and line it up with the 'self.outf' line
[07:49] <dbmoodb__> http://rafb.net/p/9scZU348.html
[07:50] <dbmoodb__> i hate spaces
[07:50] <lifeless> oh, result.summary().decode('utf-8')
[07:51] <dbmoodb__> add the ()'s that all ?
[07:52] <lifeless> yes
[07:52] <dbmoodb__> sorry that doesn't work either
[07:52] <lifeless> ok, I'll do it and make a patch
[07:53] <dbmoodb__> good because i don't want to learn a language where space is used over a tab :) (just kidding)
[07:54] <spiv> dbmoodb__: python lets you use tabs or spaces for indentation, it just doesn't like you to mix them... bzr's code chooses to use spaces.
[07:55] <lifeless> dbmoodb__: ok, cd to the ~/.bazaar/plugins/search, and do 'bzr pull lp:~lifeless/bzr-search/debugging'
[07:57] <dbmoodb__> hum i think i'm going to look up a c++ project. run "bzr launchpad-login YOUR_ID" lifeless another time
[07:57] <dbmoodb__> wait i don't have to login do i ?
[07:57] <lifeless> dbmoodb__: no
[07:57] <lifeless> dbmoodb__: its just spam
[07:58] <lifeless> that branch will print debug output
[07:58] <dbmoodb__> ko
[07:58] <lifeless> oh, you'll want to do 'bzr revert' after the pull
[07:58] <lifeless> because your edits will conflict
[07:59] <dbmoodb__> still get an error.
[07:59] <lifeless> thats to be expected
[07:59] <lifeless> the output should help me determine the cause and fix it for you
[07:59] <dbmoodb__> if i was to guess. it is because you are using weird characters that cannot be printed on my screen.
[08:00] <dbmoodb__> rofl ah dude it think you need utf_8 ?
[08:01] <lifeless> dbmoodb__: could you paste the output please?
[08:01] <dbmoodb__> will do
[08:02] <dbmoodb__> http://rafb.net/p/LTcKpa44.html
[08:03] <dbmoodb__> wait are you using a null character some where ?
[08:03] <lifeless> its not what I'm using
[08:03] <lifeless> its whats been indexed
[08:03] <lifeless> what you searched for found a hit in a .png file
[08:03] <dbmoodb__> lovelly :)
[08:04] <dbmoodb__> but i'm in squid3 i got that too. that is what i'm indexing and searching
[08:04] <lifeless> so, what I need to do is to upcast the byte sequence of the summary
[08:04] <lifeless> or something similar.
[08:05] <dbmoodb__> perhaps you should check the magic numbers of files and get only the relevant ones ?
[08:05] <lifeless> dbmoodb__: perhaps
[08:05] <lifeless> though images can be relevant :)
[08:05] <dbmoodb__> yes if you like to hide stuff
[08:05] <lifeless> - they can have comments in headers and so on
[08:06] <dbmoodb__> sure sure. but ah there isn't going to be a bug in the image header. lest the end is nigh
[08:06] <lifeless> sure there can be
[08:06] <dbmoodb__> "can"
[08:06] <dbmoodb__> i can fly.
[08:06] <lifeless> all it takes is a header style that is not printable cleanly
[08:06] <lifeless> squid includes images in its source too
[08:07] <spiv> Definitely there can.  Metadata in images can include things like attributions for the author(s), and that sort of data can be wrong and get corrected.
[08:07] <spiv> I can imagine less trivial examples too.
[08:08] <dbmoodb__> spiv: yes and no. my point is at least identify the file and not try to get stuff from image files / not print it if it can't do that
[08:08] <lifeless> dbmoodb__: I'm writing the code now to print it safely
[08:08] <lifeless> dbmoodb__: code takes a little time
[08:08] <dbmoodb__> i know
[08:09] <Odd_Bloke> lifeless: You should consider a dependency on libaa, to display image search results. ^_^
[08:09] <dbmoodb__> i use debian etch lifeless as my primary os :)
[08:10] <dbmoodb__> have fun fixing it up lifeless.
[08:27] <bob2> woo, the smart server thing got fixed already
[09:17] <gour> igc: hello, any questions on reading?
[09:17] <igc> gour: not yet - I'll read them this weekend but I'm yet to do so
[09:18] <gour> igc: good. keep up the good spirit ;)
[11:06] <Edulix> hi
[11:07] <Edulix> why bzr doesn't let me commit if I'm not exactly in the last revision of the repository ?
[11:07] <Edulix> I mean, I was committing to a file that had not even changed in the new revisions......
[11:08] <Edulix> it doesn't make sense to me
[11:08] <matkor> commiting to old revision of checkout would have to make branch , right ?
[11:09] <matkor> so if you want stay as checkout , update checkout and than commit your changes
[11:09] <Edulix> I want to commit it to trunk no to an old revision
[11:09] <Edulix> whatever, subversion would have allowed me to commit it for example :P
[11:09] <Edulix> without branching
[11:10] <matkor> or if  you want to make branch, unbind checkout , and commit to yours created branch
[11:10] <matkor> svn is different than bzr
[11:11]  * gour is glad that it is
[11:11] <gour> *err, i'm glad taht bzr is different than svn :-D
[11:12] <matkor> let's agree to: bzr and svn are different ;)
[11:25] <Edulix> well yes they're different xD
[12:24] <bjacques> So I have a mirror checkout and I created a branch from the checkout. Now I made various commits to the branch, and I'm merging them into the checkout. Now, if I merge my changes, will the commits (including commit messages) from the branch also be imported into my local checkout?
[12:38] <matkor> bjacques: in checkout you see all messeges from branch
[12:38] <matkor> so if you merged to branch you will have full history
[12:38] <bjacques> great, thanks
[12:51] <bjacques> matkor, so how does this work? I merged my changes to my mirror checkout and then committed the result to the 'main' repository. My commit shows up as a single commit with only the brief summary I gave in the final commit stage.
[13:13] <radix> bjacques: if you 'bzr log', you'll see all your revisions indented underneath the merge revision
[13:13] <radix> bjacques: all the revisions are there
[13:14] <matkor> bjacques: you can use also bzr-gtk to see graph of revisions ...
[13:21] <bjacques> ah, I see, I guess it's just the web interface that doesn't show them
[13:21] <bjacques> explicitly, anyway
[13:24] <bjacques> thanks for your help guys
[14:41]  * LarstiQ frowns at libapr
[14:46] <enobrev> having a bit of trouble getting trac-bzr working on win32.  i can import tracbzr fine in the python console.  i've added the [components] section to the ini with "tracbzr.* = enabled"  I've set my repo type to "bzr", but I'm still getting 'Unsupported version control system "bzr"'.  Anyone familiar?
[15:40] <LarstiQ> enobrev: I've never tried trac-bzr on win32 I'm afraid
[15:41] <enobrev> hmmm... anyone? thanks LarstiQ
[15:41] <LarstiQ> enobrev: are trac and the normal python console using the same sys.path?
[15:41] <enobrev> good question
[15:42] <enobrev> LarstiQ any easy way to figure that out?
[15:43] <LarstiQ> enobrev: for starters, is it the same interpreter?
[15:43] <enobrev> only have py2.5 on my system.. single install
[15:44] <enobrev> (2.5.1)
[15:44] <LarstiQ> ok
[15:44]  * LarstiQ has a gander
[15:46] <LarstiQ> enobrev: have you tried increasing the logging level?
[15:46] <enobrev> LarstiQ doing that now
[15:49] <enobrev> this could be it.. though im not quite sure how to resolve
[15:49] <enobrev> 2008-06-28 10:46:01,030 Trac[loader] ERROR: Skipping "bzr = tracbzr.backend": (can't import "bad local file header in C:\Program Files\Python25\lib\site-packages\tracbzr-0.2-py2.5.egg")
[15:50] <bob2> perhaps the zip header is messed up
[15:53] <LarstiQ> enobrev: remove it and try a fresh build?
[15:53] <enobrev> LarstiQ exactly what I'm doing now... actually going to grab a couple builds from LP to see if any of them work... if not, time to get my hands dirty
[15:54] <LarstiQ> cool :)
[15:54] <enobrev> thanks LarstiQ, bob2
[16:08] <enobrev> LarstiQ, bob2, fixed.  wish i could say i know what the problem was, but I just installed bzr from source (instead of bzr win32 installer) and now it's workin... thanks again
[16:08] <enobrev> oddly, bzr's been working great all this time.  just had to reinstall for the tracbzr plugin to work
[16:22] <LarstiQ> enobrev: doh
[16:51] <qense> I'd like to create a copy of a branch in Launchpad to my own profile so I can implement something and propose it for a merge later
[16:51] <qense> but how do you create the copy? I can't find it
[16:54] <dato> I think you just have to push it to ~youruser/productname/yournameforthebranch
[16:56] <qense> ok
[17:23] <pfharlock> does anyone in here maintain the bzr-upload plugin?  I have a small patch.
[17:25] <jelmer> pfharlock: vila and beuno are the people to talk to
[17:26] <pfharlock> cool, thanks, I've not used launchpad before, so I'm signing up for an account now.  it's just a small syntax error in the setup script
[17:39] <bobesponja> hi
[17:39] <bobesponja> how do I create a bare (empty) repository to push to? if there is such a thing
[17:40] <pfharlock> bzr init
[17:40] <pfharlock> bzr init .
[17:40] <pfharlock> creates a branch
[17:41] <pfharlock> actually if you just push to an ssh location and there isn't a repo there, I think it just creates it for you, if I'm wrong about this somebody please let me know.
[17:42] <bobesponja> pfharlock: I mean, in git for hosted repositories( where people push) there is no working tree with files, only a .git
[17:42] <dato> bobesponja: there is no such thing as "bare" in bzr (as in, having the .bzr/* stuff at the top level), but there are branches without trees
[17:43] <Pilky> bobesponja: bzr init-repo --notrees
[17:43] <dato> bobesponja: and, you need not (as in git) logging into the remote server to create the repo first; you can just push directly, and bzr will create it if it does not exist, making it without a tree by default
[17:43] <Pilky> oops, that should be --no-trees
[17:44] <bobesponja> ok thanks
[17:44] <bobesponja> Pilky: so bare would be --no-trees
[17:44] <Pilky> if you want one with no working tree and just the .bzr folder
[17:46] <bobesponja> yep, that's what I want
[17:46] <bobesponja> Pilky: isn't that what is always used on hosted repositories?
[17:47] <Pilky> I believe it's what is usually used on (and recommended for) hosted repositories, you still have to specify --no-trees though
[17:49] <bobesponja> what if my local repo has trees, if I push to a repo that doesn't exist yet, will it create automatically with or withour the trees?
[17:49] <dato> bobesponja: do you have clear the disticntion between repo and branch in bzr?
[17:49] <Pilky> I dunno, I believe it will just push the branch if a repo doesn't exist
[17:50] <dato> Pilky: uh, sure it will
[17:50] <bobesponja> dato: a repo has many branches?
[17:50] <fbond> Would `bzr multi-pull' be useful for updating all of the threads in a loom from another loom?
[17:50] <dato> bobesponja: yes, but branches can exist outside repos
[17:51] <Pilky> dato: I mean, I have a repo on my desktop, I've pushed a branch from it to my server and pull the branch to my laptop (with no repo)
[17:51] <bobesponja> basically, my use case is people have local repositories with working trees they work on and when they push it creates (if the repo doesn't exist yet) a remote repository with --no-trees
[17:52] <bobesponja> branch without repo? that's weird I guess I need to do some reading
[17:52] <Pilky> bobesponja: I think you have to create the repo manually, otherwise it will push the branches as being self contained
[17:52] <Pilky> branches are just directories
[17:53] <Pilky> bobesponja: this may be of help: http://bazaar-vcs.org/BzrVsGit#head-8d6788e5fb366d04efa536c4c41d4b36e67233fb
[17:53] <bobesponja> ok thanks
[17:55] <bobesponja> so branches are kind of like svn I guess
[17:57] <Pilky> yeah, sort of
[18:11] <baco> question, you branch branches, not repos, which are re-branchable, but then no one except the original server can have the same structure of repo and branches, but a bunch of branches which could eventually be grouped in a repo, but there's no way to clone the entire repo from the server
[18:12] <bob2> there's repo-push and multi-pull to do bunches together
[18:18] <baco> bob2: I don't have repo-push in my command-line client, and multi-pull pull all branches, but does not says anything about the configuration of the repo, you'll have to do a bzr init-repo in the directory pulled after that
[18:18] <bob2> repo-push is a seperate plugin
[18:18] <bob2> as for the rest, you've lost me
[18:19] <bob2> what is "configuration of the repo"?  and multi=pull pulls into a repository (so no need for a init-repo after - it has to be before or it won't work)
[18:21] <baco> bob2: the .bzr directory in the repo directory that is created after a bzr- init-repo is what I say for configuration, and ﻿multi=pull was a typo of ﻿multi-pull
[18:22] <bob2> for configuration, do you mean branch.conf?
[18:23] <baco> when you do bzr init-repo a .bzr directory is created with lots of files
[18:24] <baco> brb
[18:45] <baco> back
[20:14] <\sh> guys, which version of bzr supports lp: formed uris? regarding bzr+ssh usage? :)
[20:21] <jelmer> \sh: All recent versions do
[20:22] <\sh> jelmer: hardy can't use lp: to push branches to launchpad :)
[20:22] <\sh> jelmer: so I think more the intrepid one can?
[20:22] <jelmer> hmm, not sure then
[20:23] <jelmer> sorry
[20:23] <jelmer> it's probably just that push in that version is unaware of directory lookups (such as lp)
[20:47] <pygi> \sh, afaik thats a plugin
[20:48] <pygi> \sh, 1.3.1-1 from Hardy I think, and all works =)
[20:49] <\sh> pygi: I always have problems doing a "bzr push lp:~<team|user>/<branchname>" because this starts to use http[s]:// and not bzr+ssh :)
[20:51] <dato> did you do `bzr launchpad-login`?
[20:52] <pygi> \sh, do what dato said :)
[20:55] <\sh> dato: something like this exist? ;)
[20:55] <\sh> dato: so no :)
[20:56] <\sh> dato: but I'll try :)
[22:44] <libwilliam> I have a question about commit --show-diff...
[22:44] <libwilliam> In the guide it said you could use that instead of using --message
[22:45] <libwilliam> but when I do bzr commit --show-diff it still asks for a message and fails if I don't give one
[22:45] <LarstiQ> It's not a replacement, but --show-diff isn't useful if you supply --message on the cli.
[22:46] <LarstiQ> libwilliam: where in the guide should I look?
[22:46] <libwilliam> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#commit
[22:46] <libwilliam> the --show-diff option
[22:46] <libwilliam> "When no message is supplied, show the diff along with the status summary in the message editor."
[22:46] <LarstiQ> Right.
[22:47] <libwilliam> to me it means if I don't supply a message but use the --show-diff option it should ask for a message after, then fail if I leave it blank
[22:47] <libwilliam> should not*
[22:47] <libwilliam> I typed that confusing
[22:47] <LarstiQ> ah, to me it means what you said without the correction :)
[22:47] <libwilliam> ok let me try again :)
[22:48] <LarstiQ> Ie, it will fire up the message editor and show the diff for your review. You still have to write a commit message.
[22:48] <libwilliam> oh
[22:48] <libwilliam> i get what it means... I read it as instead of showing the diff for review. it just takes the diff and uses it as the message
[22:48] <LarstiQ> *shudder*
[22:49] <LarstiQ> libwilliam: That doesn't make sense to me, at all.
[22:49] <libwilliam> it does make sense now that I reread it
[22:49] <LarstiQ> libwilliam: you actively want to use the diff as a commit message?
[22:49] <libwilliam> no... I am just writing the Anjuta IDE plugin and I am making sure the user can't execute a command that will fail... so I am handling all of the scenerios
[22:50] <LarstiQ> libwilliam: ah ok, cool
[22:50] <LarstiQ> libwilliam: the reason I ask is I've come across some projects where that is done, and I never understood why.
[22:50] <libwilliam> I essentially read it as  "When no message is supplied, show the diff along with the status summary in the message editor." without the last word "editor"
[22:50] <LarstiQ> I mean, the diff is available in the tool anyway, and it only obfuscates what the commit was about.
[22:51] <LarstiQ> libwilliam: ah, I see.
[22:51] <libwilliam> its just me reading it wrong
[22:51] <libwilliam> well thanks for your help
[22:53] <LarstiQ> libwilliam: would a different wording have helped?
[22:56] <libwilliam> LarstiQ, well it is currently worded correctly, I just wasn't paying very good attention. It might be worded a little better.
[22:57] <libwilliam> I'm not very goods with words though, I'll try and think of something that sticks out more though.
[22:57] <ChristopheT> How am I supposed to use bzr-svn-1.5 with bzr.dev?  If I just make a link from ~/.bazaar/plugins/svn to the svn-1.5 branch, I get the message "Unable to load bzr-svn extensions - did you build it?"
[22:58] <Peng> ChristopheT: Run make.
[22:59] <libwilliam> LarstiQ, "When no message is supplied, show the diff along with the status summary to help the user decide on a message."
[23:00] <ChristopheT> Peng: thanks.  Why isn't "make" run by "setup.py build"?
[23:00] <LaserJock> I was just trying to revert some changes. After doing bzr revert I seem to have several .~1~ files. Are those from bzr?
[23:00] <LaserJock> hmm, maybe I should've read bzr help revert first ;-)
[23:02] <Peng> ChristopheT: I dunno. Maybe jelmer forgot to update setup.py.
[23:02] <Peng> ChristopheT: Maybe setup.py builds them in build/, while make builds them in-place.
[23:02]  * Peng shrugs.
[23:05] <LarstiQ> ChristopheT: I expect things to be the other way around usually, the README is certainly out of date though.
[23:05] <LarstiQ> (ie, make doing a superset of setup.py, the latter not being 'complete')
[23:08] <LarstiQ> libwilliam: hmm, I'm not entirely happy with that, but I haven't found something better :/
[23:09] <libwilliam> LarstiQ: I am the wrong guy to ask. Words are far from my strong suit.
[23:10] <LarstiQ> libwilliam: I do get the gist of what you tried to express though.
[23:11] <libwilliam> LarstiQ: Really it doesn't necessarily need to be rewritten. I just never use the message editor so when I was reading it I skimmed right over that word.
[23:12]  * LarstiQ nods at libwilliam 
[23:12] <LarstiQ> libwilliam: still, if we can improve it, that wouldn't be bad
[23:12] <LarstiQ> but I'll stop breaaking my head for noow :)
[23:13] <libwilliam> Also one more question why I am in here. Is there a way to know if a bug pattern will work or fail with the --fixes option in bzr commit.
[23:13] <libwilliam> I am trying to throw a warning if the user inputs an invalid bug bug I have currently have no way of knowing what is the wrong form.
[23:21] <LarstiQ> libwilliam: hmm, I don't think the cli exposes that
[23:22] <libwilliam> I can use the Python code from the C/Python interface if it isn't too confusing for me :) I will check it out there
[23:23] <LarstiQ> libwilliam: look at commit 2446 then
[23:24] <LarstiQ> libwilliam: bzrlib/bugtracker.py and bzrlib/builtins.py:_get_bug_fix_properties() are of intereste
[23:24] <LarstiQ> libwilliam: and the MalformedBugIdentifier error
[23:25] <libwilliam> LarstiQ, thanks, I am looking them up now
[23:27] <LarstiQ> libwilliam: I think it's basically <tracker_identifier>:<bug_identifier>
[23:27] <LarstiQ> libwilliam: where the first exists due to configuration, and the second is tracker instance specific
[23:27] <libwilliam> LarstiQ: I will need to use the Bazaar Methods though because I can't just test for that format because a:1 won't work
[23:28] <LarstiQ> libwilliam: it could work
[23:28] <LarstiQ> libwilliam: but yeah, using bzrlib beats parsing bazaar.conf yourself and potentially querying the tracker for existance of the bug
[23:29] <LarstiQ> (or even verifying that the commit actually fixes _that_ bug, but that's a lot further than checking if the syntax is ok)
[23:29] <libwilliam> LarstiQ: ya I believe so, definatly going the  bzrlib route
[23:29] <libwilliam> LarstiQ: I didn't even know it had that ability
[23:29] <LarstiQ> libwilliam: the ability to configure bugtrackers/
[23:30] <libwilliam> LarstiQ: the ability to have it actually check if the bug was fixed
[23:30] <LarstiQ> ah, it can't :)
[23:30] <LarstiQ> and it would be a difficult problem. If you require a unit test that demonstrates the bug, it would be easier to do.
[23:31] <libwilliam> LarstiQ: I'm kinda glad it can't because my head was going to explode trying to figure out how
[23:31] <libwilliam> LarstiQ: ya
[23:31] <LarstiQ> :)
[23:31] <LarstiQ> that might actually be a useful workflow bit, ala aegis
[23:31] <libwilliam> LarstiQ: I need to take off, thanks for helping me out with everything. I am definitely going the bzrlib route.
[23:32] <libwilliam> see ya
[23:32] <LarstiQ> libwilliam: np, take care!
[23:32] <libwilliam> you too, have a good one