[00:00] jelmer: or possibly an ordering bug in branch --stacked etc [00:00] jelmer: uhm find the call point that does the fetch [00:01] lifeless: Svn's fetcher is being called before any data has been fetched [00:01] btw, if they allow data access, they aren't Fake objects :P [00:01] virtual [00:01] or svnbacked [00:01] but not fake [00:02] whats calling the svn fetcher? [00:02] heh, true [00:02] bzrdir.sprout() iirc [00:05] lifeless: No idea, someone else made it/sent it via email. [00:05] uhm, is self._pack_collection.revision_index.combined_index supposed to be accessing fallback repositories? [00:07] lifeless: Thanks... I am going to send back the results to the user to figure out. [00:07] krow: so [00:07] krow: let me give you a little info [00:07] krow: say you have three branches [00:07] TRUNK [00:07] my-branch [00:07] your-branch [00:08] 'bzr send' is used to create a patch, which contains a _bundle_ of data [00:08] for me to send some commits from my-branch to you [00:09] 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] ok [00:09] so the send command wants a branch that it can use to determine that common point of reference [00:09] now, if someone cherrypicks - if they say -r x..y [00:10] this *still applies* - because bzr needs enough data in the patch to verify that noone edited it in transit [00:10] 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] I bet that your user did something like this: [00:11] 'bzr send . -r x..y' [00:11] (where . says 'the SUBMIT_BRANCH is my current branch' [00:12] this caused the problem, because bzr said 'oh, *everyone* has all the data, I just need to include the instruction [00:12] (rather than finding the common point between 'my-branch and TRUNK' it was the common point between 'my-branch and my-branch' [00:12] so the solution is to do 'bzr send -r x..y TRUNK' [00:13] and it will all be good [00:13] I hope that made sense and will help [00:14] lifeless: Is Repository.has_revisions() supposed to be querying fallback repositories? [00:14] jelmer: of course, if they are absent locally [00:14] lifeless: It does... I assume there is no way to recover this patch? [00:15] krow: not and maintain the commit metadata/revision id etc [00:16] krow: if you really just want the textual patch you see at the top 'bzr patch /tmp/patch' [00:19] hmm, something funny is happening here [00:19] jelmer: here is the stacking expectation: [00:19] jelmer: data available locally is used before data available remotely [00:19] jelmer: queries are only made for remote data when it is needed [00:19] jelmer: few complex queries are preferred over many small ones [00:20] jelmer: so whats triggering the fetcher [00:20] ? [00:21] lifeless: Trying to figure that out atm [00:21] 'bt' ? [00:21] back in 15-20 [00:21] you mean, what's starting the fetcher? [00:21] or what's causing it to fetch non-tip revisions? [00:22] bzrdir.sprout() is starting the fetcher [00:25] jelmer: and is the repository stacked at that point? [00:25] lifeless: Yes [00:25] lifeless, has_revisions() doesn't appear to go to the fallback repository [00:26] jelmer: oh [00:26] delete pack_repo.py's has_revisions [00:27] woot [00:27] lifeless, that did it [00:27] not that it works, but I get a different error now [00:28] jelmer: :P [00:28] NotImplementedError: > [00:36] lifeless: in self.texts.get_parent_map(), is it required to return more than the lhs parent? [00:38] yes [00:39] if you don't per-file log will be fucked [00:39] and check will fail [00:39] bbiab [00:40] hmm, that sucks [00:51] lifeless: It would be nice if there was some way to override build_tree() to just call revision_tree() [00:52] rather than using iter_file_bytes(), etc [01:04] jelmer: if you need that; patch it :) [01:05] heh [01:05] jelmer: but really, you should be able to do iter_file_bytes efficiently for merge and other operations as well [01:05] going to a movie - laters [01:05] lifeless: Merge from svn you mean? [01:06] merge from bzr [01:06] when the base of any text is in svn [01:06] That's always going to be significantly slower [01:06] svn's protocol is very tree-oriented [01:07] For now, I'll just return None for parents [01:07] enjoy your movie! [01:08] which one are you going to? === mw is now known as mw|out [01:10] get smart [02:12] jam: you here? [02:19] hm, the smart server isn't working for me at all at head [02:34] 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] markh: It's correct. Protocol v3 is very new. [02:36] markh: (That is, I think it might be even newer than 1.6b2. I'm not sure.) [02:36] 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] I use bzr.dev all the time. [02:37] me too :) Thats something I can decide later though :) [02:37] ssh issues on windows are still driving me nuts too, so I better get back to that... [02:37] It might be good to package the revision before VersionedFiles, though, since that's a big API change and breaks many plugins. [02:38] these are binaries for windows, where a good plug story remains to be written anyway :) [02:39] by the time we would out to package them reasonably, hopefully they will all then be working again! [02:39] s/would/work/ [02:48] does bzr cache passwords used for the "lp:" protocol? [02:51] lifeless: W00T [02:51] 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] Initialising Subversion metadata cache in /home/jelmer/.bazaar/svn-cache-exp/203ae883-c723-44c9-aabd-cb56e4f81c9a [02:51] using experimental bzr-svn mappings; output may change between revisions [02:51] Created new stacked branch referring to svn://svn.gnome.org/svn/gnome-specimen/trunk. [02:52] and bzr info actually shows there are 0 revisions in the local repository [02:58] * markh thinks maybe it caches a certificate... [03:05] jelmer: sweet [03:16] which is the difference between sftp and bzr+ssh schemes? [03:17] baco: bzr+ssh is a protocol native to bzr. It runs bzr on the remote end. [03:17] 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. === kiko-afk is now known as kiko-zzz [03:18] spiv: like the commits being made locally in bzr+ssh? [03:18] I'm not sure what you mean. [03:19] The behaviour is the same, just bzr+ssh tends to be faster. [03:19] The downside is that it needs bzr installed on the server. [03:20] sftp uses ssh an then ftp on the remote end [03:20] SFTP is not FTP. [03:20] It's similar, but it doesn't just SSH in and run FTP. [03:22] SFTP also doesn't have the weird control channel/data channel split that FTP has. [03:23] 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] It's not that simple, but basically yeah. [03:25] 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] Yes. [03:27] 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] Yes. [03:28] tnx [03:56] 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] If I understand you correctly, it's just Launchpad stuff. [03:58] 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] baco: you don't branch repos, you branch branches :) [04:00] ok, I usually, but not on lp, I mean you have the option not to [04:01] What? [04:03] 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] hi spiv [04:04] jelmer: congrats! [04:05] spiv, lifeless: thanks [04:05] lifeless: There's no rich-root-stackable format yet, right? I'm using devleopment-rich-root for now [04:06] jelmer: thats stackable yes [04:06] argh, it's getting late [04:06] jelmer: there is no non-development stackable if thats what you are asking [04:06] I meant development-subtree [04:06] jelmer: hmm, we should add that [04:06] jelmer: patch it up :P [04:07] heh, some other day maybe :-P [04:07] jelmer: still, fantastic news [04:07] Peng: am I right? [04:07] jelmer: should be trivial yo add development-rich-root [04:07] Performance on operations like log in this branch is pretty terrible right now, though that was to be expected [04:08] jelmer: so we need to fix that; log --short shouldn't be terrible though [04:11] lifeless, it's worse than usual though [04:11] as it's accessing these objects as XML [04:11] rather than calling get_revisions() directly, avoiding a conversion back and forth [04:12] jelmer: yeah; so stacking in a semantic fashion is actually significantly more work, as every layer needs to be taught [04:12] jelmer: and every api needs to be stack-aware [04:12] yeah [04:13] lifeless, I also had to disable packrepo's get_parent_map implementation btw [04:14] jelmer: right, please turn those into patches [04:14] jelmer: they should not be needed with the thinner layers of VersionedFiles [04:14] bac: No. You only branch branches, not repos. [04:14] bac: Are you talking about "lp:" URLs? [04:14] Augh, crap. [04:14] Peng: yes [04:14] I'm sorry, bac. I meant baco. [04:15] understood :-) [04:15] Peng: np :) [04:15] Usually it's safe to tab-complete three characters. Whoops. [04:15] LOL [04:16] 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] baco: This has nothing to do with repos having default branches or anything. [04:17] Peng: ok, tnx === BasicPRO is now known as BasicOSX [04:38] spiv: It looks like a python clone is significantly faster now, btw [04:39] jelmer: sweet [04:39] spiv: about 1500 revisions in the first 5 minutes (not involving stacked branches) [04:40] Not bad! [05:10] jelmer: if you support texts properly now [05:10] jelmer: try bzr-search, and disable 'revisions_only' for svn [05:10] 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] pfharlock: exactly that [05:10] but with .. instead of : [05:11] yeah, but when I try bzr merge -r 3..2 it doesn't do what I would expect [05:11] pfharlock: what does it do ? [05:11] pfharlock: oh, you probably want 'bzr merge -r 3..2 .' [05:12] well the revision in question I added a file, I would expect the file to be marked for removal [05:12] oh, what does the . do [05:12] its merges from the current branch [05:12] rather than from the parent branch [05:12] duh [05:12] thanks [05:12] let me try that [05:14] jelmer: oh, just remembered, I haven't dont VersionedFiles for bzr-search yet. [05:14] jelmer: I will today probably [05:14] yes, that worked like I expected, thanks a bunch [05:15] cool [05:20] 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] s/or/of [05:22] I've been contemplating writing a script to do it if one doesn't already exist [05:22] there are plugins [05:22] the underlying api can do it of course, but unreferenced revisions are just garbage pending gc [05:24] jam: ping [05:24] 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] 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] on my TODO is to write an efficient gc to give people direct control over this in case they need it [05:26] wow, that's pretty cool, other than deleting a branch, what could cause a revision to become unreferenced? [05:27] I would guess that uncommit might do it [05:27] pfharlock: Rebasing, I think. [05:28] ok, that makes sense (not knowing how the rebasing plugin does it's magic :) [05:29] pfharlock: Yeah, I only have vague recollections, but it's the sort of operation that might. :) [05:29] uncommit [05:29] and rebasing [05:31] 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] 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] pfharlock: hmm, I would say 'bzr search' :) [05:35] cool, thanks, I'll give that one a try :) [05:40] pfharlock: its a plugin, it currently searches per-branch [05:40] pfharlock: but once indexed the searches are subsecond [05:41] 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] yup [05:41] the index is agnostic as to where content comes from [05:41] would be a good primer on how to start programming for bzrlib [05:41] 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] very cool :) [05:42] if I get anywhere with that I'll get in touch, are you the author of the search plugin? [05:42] sure am [05:44] cool, well thanks for all the help, it's greatly appreciated [05:47] 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] And with that wall of text, I shall head to bed. [05:49] Odd_Bloke: pqm's bugs are a good place to look too [07:12] 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] yes i am an idiot [07:14] don't worry i am an idiot [07:14] fixed [07:17] dbmoodb__: no need to beat up on yourself. Everyone has to learn things the first time at some point. [07:20] dbmoodb__: hi [07:21] oh hi [07:21] 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] thats fine, 2.4 should be enough [07:22] what are the packages required for bzr search ? [07:22] have you got bzr installed ? [07:22] yes [07:22] what version? [07:22] 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] oh [07:23] ignore the setup.py for the plugin, thats for distro's that want to install it system [07:23] 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] wide [07:23] k sure i couldn't get that to work either :) [07:23] 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] dbmoodb__: are you using ubuntu? [07:23] this is ubuntu hardy yes [07:23] ok [07:23] if you add [07:24] launchpad repo yah ? [07:24] deb http://ppa.launchpad.net/bzr/ubuntu hardy main [07:24] so your /etc/apt/sources.list [07:24] it will give you the current release of bzr [07:24] which is 1.5 [07:24] lifeless: ok sure..... it would be nice to use it with what i currently have tho [07:26] 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] lifeless: so it will work with what i have just produce an error ? [07:26] 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] dbmoodb__: yes [07:26] dbmoodb__: it will also not auto-update the index when you commit/push/pull [07:27] dbmoodb__: but if you're happy with those caveats then its ok by me :)( [07:27] lifeless: because thats in my release. sigh its still dev so ok ! [07:28] i will add packages that have no gpg auth :) [07:28] dbmoodb__: ah I see. we're going to get a backport done [07:29] lifeless: its still dev don't worry. but what you were saying was that it previously was using cron jobs and things. [07:29] dbmoodb__: still; you don't have to upgrade to 1.4/1.5, its only a recommendation [07:29] that was because of the old bzr ? [07:29] lifeless: i have done it. [07:29] dbmoodb__: *loggerhead* used to need all sorts of nastiness [07:29] dbmoodb__: ok. [07:29] https://edge.launchpad.net/bzr-search [07:30] has install instructions for bzr-search [07:30] (mkdir -p ~/.bazaar/plugins [07:30] bzr branch lp:bzr-search ~/.bazaar/plugins/search [07:30] ) [07:30] 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] 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] dbmoodb__: yes, for the command line, cd to the branch you want to search - [07:31] I'll add those to the README [07:32] 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] again -- i know its dev [07:32] dbmoodb__: let me see if I understand [07:33] you want a global list of the branches that you have indexed ? [07:33] that would be nice. given you intend for this to be networkable no ? [07:34] well, it is networkable already using the same model bzr has [07:35] well autocompletion would be nice (of the ones you have done and perhaps a few suggested projects [07:35] so, what would the global list help you do ? [07:35] lifeless: tab complete ? [07:36] dbmoodb__: so, you're saying you could 'cd ~', 'bzr search -d ' - and it would list places you could search? [07:37] perhaps. [07:37] I'm just trying to understand the use case [07:37] I mean [07:37] imagine you hack on openoffice, binutils and gcc [07:38] you'll have branches of them that you edit code in [07:38] 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] data, consumed = self.encode(object, self.errors) [07:38] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 21: ordinal not in range(128) [07:39] dbmoodb__: can you get the backtrace from ~/.bzr.log ? [07:39] sure thing [07:39] (and don't paste it all in the channel!) [07:40] dbmoodb__: I think what I'm saying is that the issue with finding previously used branches is much broader than bzr search [07:40] 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] dbmoodb__: http://rafb.net/paste/ [07:40] dbmoodb__: Sure, pasting 2 lines is no problem. I was just making sure. [07:41] http://rafb.net/p/UEdy7J89.html [07:42] dbmoodb__: ah ok [07:42] dbmoodb__: your console is ascii [07:42] dbmoodb__: but the search result was unicode, and it can't show it to you [07:43] 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] 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] ah yes, you do have UTF8 local [07:43] ok, something different, one sec [07:43] can you edit home/X/.bazaar/plugins/search/commands.py [07:44] yes. how so ? [07:44] on the line before self.outf.write(" Summary: '%s'\n" % result.summary()) [07:44] insert [07:44] print type(result.summary()) [07:44] print result.summary.decode('utf8') [07:45] run it and pastebin the output [07:47] lifeless: the repr might be useful too [07:47] (And is usually ascii-clean) [07:47] spiv: I'm betting I have utf8 data I'm tossing at outf [07:47] but its doing implicit decode(ascii( [07:48] lifeless: it doesn't like my indentation :( [07:48] dbmoodb__: use spaces and not tabs, and line it up with the 'self.outf' line [07:49] http://rafb.net/p/9scZU348.html [07:50] i hate spaces [07:50] oh, result.summary().decode('utf-8') [07:51] add the ()'s that all ? [07:52] yes [07:52] sorry that doesn't work either [07:52] ok, I'll do it and make a patch [07:53] good because i don't want to learn a language where space is used over a tab :) (just kidding) [07:54] 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] dbmoodb__: ok, cd to the ~/.bazaar/plugins/search, and do 'bzr pull lp:~lifeless/bzr-search/debugging' [07:57] hum i think i'm going to look up a c++ project. run "bzr launchpad-login YOUR_ID" lifeless another time [07:57] wait i don't have to login do i ? [07:57] dbmoodb__: no [07:57] dbmoodb__: its just spam [07:58] that branch will print debug output [07:58] ko [07:58] oh, you'll want to do 'bzr revert' after the pull [07:58] because your edits will conflict [07:59] still get an error. [07:59] thats to be expected [07:59] the output should help me determine the cause and fix it for you [07:59] if i was to guess. it is because you are using weird characters that cannot be printed on my screen. [08:00] rofl ah dude it think you need utf_8 ? [08:01] dbmoodb__: could you paste the output please? [08:01] will do [08:02] http://rafb.net/p/LTcKpa44.html [08:03] wait are you using a null character some where ? [08:03] its not what I'm using [08:03] its whats been indexed [08:03] what you searched for found a hit in a .png file [08:03] lovelly :) [08:04] but i'm in squid3 i got that too. that is what i'm indexing and searching [08:04] so, what I need to do is to upcast the byte sequence of the summary [08:04] or something similar. [08:05] perhaps you should check the magic numbers of files and get only the relevant ones ? [08:05] dbmoodb__: perhaps [08:05] though images can be relevant :) [08:05] yes if you like to hide stuff [08:05] - they can have comments in headers and so on [08:06] sure sure. but ah there isn't going to be a bug in the image header. lest the end is nigh [08:06] sure there can be [08:06] "can" [08:06] i can fly. [08:06] all it takes is a header style that is not printable cleanly [08:06] squid includes images in its source too [08:07] 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] I can imagine less trivial examples too. [08:08] 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] dbmoodb__: I'm writing the code now to print it safely [08:08] dbmoodb__: code takes a little time [08:08] i know [08:09] lifeless: You should consider a dependency on libaa, to display image search results. ^_^ [08:09] i use debian etch lifeless as my primary os :) [08:10] have fun fixing it up lifeless. [08:27] woo, the smart server thing got fixed already [09:17] igc: hello, any questions on reading? [09:17] gour: not yet - I'll read them this weekend but I'm yet to do so [09:18] igc: good. keep up the good spirit ;) === doko_ is now known as doko [11:06] hi [11:07] why bzr doesn't let me commit if I'm not exactly in the last revision of the repository ? [11:07] I mean, I was committing to a file that had not even changed in the new revisions...... [11:08] it doesn't make sense to me [11:08] commiting to old revision of checkout would have to make branch , right ? [11:09] so if you want stay as checkout , update checkout and than commit your changes [11:09] I want to commit it to trunk no to an old revision [11:09] whatever, subversion would have allowed me to commit it for example :P [11:09] without branching [11:10] or if you want to make branch, unbind checkout , and commit to yours created branch [11:10] svn is different than bzr [11:11] * gour is glad that it is [11:11] *err, i'm glad taht bzr is different than svn :-D [11:12] let's agree to: bzr and svn are different ;) === abentle1 is now known as abentley [11:25] well yes they're different xD === kiko-zzz is now known as kiko [12:24] 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] bjacques: in checkout you see all messeges from branch [12:38]