[00:01] could the problem be in unlocking? === kiko is now known as kiko-afk [00:06] yes [00:06] or some interaction [00:06] please file a bug [00:07] ok, will do [00:07] thanks for the help [00:46] yay! loggerhead revision view down from 2.9sec to 0.2 [00:46] * beuno commits [01:07] Is there a way to configure a repository to accept only signed commits? === tro|| is now known as tro [01:31] beuno: nice [02:21] thatch: hi; you might have an answer to this... is there a good, low-dependency python IR/text indexer around ? [02:22] not aware of one... but that's not an easy problem to solve (especially if you need multilingual stemming) [02:23] what do you need one for? [02:24] searching bzr repositories [02:24] you know bonsai for instance, or fisheye [02:25] ok [02:25] I don't see why the core storage should be the web apps domain [02:25] I can easily imagine nice text clients [02:26] I think I looked at Lupy and PyLucene a while back but haven't particularly used either [02:26] argh, loggerhead on LP slowly dying again... :( [02:27] beuno: when can we start deploying your zpt branch [02:27] ignoring fancy css etc its better already [02:28] thatch: have you seen the template engine discussions going on here [02:28] lifeless, I'm mainly doing some cleaning, so, if I put a good amount of hours this weekend, I can probably have something up for review on your monday morning. Not sure if mwhudson__ will have time to review it though [02:30] I imagine it will be a priority for him :) === tro|| is now known as tro [02:31] well, I'll make sure first thing monday, to do any tweaks needed [02:31] lifeless: nope, I don't think I've been in #bzr for a week. I can check the logs, was it today? [02:32] I also cleaned up all the deprecated methods, so it won't be hanging from a thread everytime bzr gets updated on LP [02:41] lifeless, css and all visual goodness is delayed til we know what 2.0 will actually look like, so we can have something accordingly [02:42] basically, colors and some other visual elements will change a bit from the last draft [02:42] better CSS should make rendering faster too. There are a lot of areas we can still easily improve performance-wise [02:43] I even have an evil idea to get rid of the sqlite cache completely, but I still have to go over it with mwhudson__ [02:54] * beuno commits, pushes, and goes to dinner [03:35] thatch: basically the loggerhead template enginge is largely why its slow [03:35] beuno knows more [03:35] I think they looked at a couple of others but found zpt is actually leanest/fastest [03:36] beuno: I have been encouraging removal fo the cache for a while ;P === tro|| is now known as tro [03:56] hello guys, where I can download a paramiko? [04:01] toyto1: http://www.lag.net/paramiko/ [04:03] thanks spiv, got it already :) [04:03] toyto1: great :) === tro|| is now known as tro [05:36] how impossible would it be to add custom diff support to bzr? for e.g. storing XML files where custom diff / merge handlers must be used and bzr should not interpret the data [06:05] guys i run this in my local computer [06:05] bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/ [06:05] bzr init sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing [06:06] then in the other computer I try [06:06] bzr checkout sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing testing-local [06:07] how can i checkout the code or the whole testing project scripts? [06:07] when I try to go to $PWD/testing-local/ i thought the scripts of the project will be residing in there [06:07] how to do that? === mwhudson__ is now known as mwhudson [06:19] keir: we have that [06:19] keir: we disambiguate delta-storage and user-diffs [06:20] delta storage is currently always a binary-safe line orientated delta [06:21] but user diffs are pluggable [06:21] toyto1: init creates a tree or branch, it doesn't add files [06:21] toyto1: you need to: [06:21] do a checkout [06:21] copy your files in [06:21] do bzr add [06:21] bzr commit [06:22] then in your testing-local checkout you can do bzr update and it will get the files [06:23] lifeless: let's assume that there are 3 computers involve where the sftp:sftp://toytoy@192.168.2.10/home/toytoy/repositories/ would be the server that has the script repo [06:24] let's say in my local pc that has the scripts located in /home/www/testing/*where my scripts of project* [06:24] and i'm on that directory then issuing this command to server [06:24] bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/ [06:24] and [06:24] bzr init sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing [06:24] that will have made a branch at sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing with no commits in it [06:25] you can run 'bzr log sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing' to see this ;P [06:25] i see i'll try [06:26] lifeless: let's say at first i'm going to cd /home/www/testing [06:26] it doesn't matter where you cd to [06:26] I won't do bzr init myrpoject anymore right? [06:26] init URL only affects URL [06:26] instead i'll use this [06:26] bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/ [06:26] in that way, i want to decentralized the scripts of the project. did I follow the idea? [06:27] I think you are confused about what init does [06:27] it creates an *empty* branch, it does not *add your data to it* [06:28] lifeless: can you do me a favor so that I can clearly understand it, can you tell me step by step with it involving the [06:28] bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/ [06:28] command [06:28] toyto1: where are your existing scripts [06:28] my friend told that in that way, we can decentralized the scripts [06:28] okay [06:28] let's say here in my local pc [06:28] it's in [06:29] /home/www/testing [06:29] ok [06:29] cd /tmp [06:29] ok [06:29] then [06:29] bzr checkout sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing [06:29] cp -a /home/www/testing/* . [06:29] bzr add [06:29] bzr commit -m 'import scripts' [06:29] oh hmm, missed a command [06:30] bzr checkout .. [06:30] cd testing [06:30] then cp -a [06:30] and so on [06:30] let me try :) [06:30] lifeless, is it possible to tell bzr to never merge? or to use external merge programs? [06:31] keir: the former not as such; the latter I think so, or at least, one can write a plugin to enable that [06:31] (which is not quite the same thing, I know) [06:32] hmm, ok. i am envisioning a system where a textual merge is strictly incorrect and should never be attempted... so bzr needs to be extended to do this? [06:32] There's an extmerge plugin. [06:32] I believe we have all the necessary machinery [06:32] (I think that's its name.) [06:32] some assembly required [06:33] yup, ok. [06:34] which is to say you can get what you want without patching bzr itself, or deep voodoo [06:34] but I may be wrong :P [06:34] alright. it's ok if i have to patch bzr, i was just curious [06:35] :) [06:38] lifeless: it says [06:38] Committed revision 1. [06:38] after issuing the bzr commit -m 'import testing scripts' [06:38] right [06:38] and then what's next after it? [06:39] now, go somewhere you want to get a new copy of the scripts - your third machine [06:39] lifeless: okay let's say in this computer again but in different directory [06:40] sure [06:40] cd there [06:40] lifeless: let's say in my /home/mypc/Desktop/repo <- im here now [06:40] and do bzr checkout ... [06:40] ok trying... [06:41] wow it's there already ;) [06:41] and now since i'm in this director /home/mypc/Desktop/repo/testing [06:41] let's say i'll edit test.txt [06:42] after I will bzr commit -m 'i did edit test.txt' [06:42] will it automatically sync with the scripts from the server? [06:42] or update that script also? [06:42] it will write to the database on the server [06:43] in a file in .bzr there [06:43] on the other machine, where you have done bzr checkout, you can do 'bzr update' to sync [06:44] lifeless: wow ;) I get it thank you so much :) [06:44] now i can bzr diff sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing too right? [06:46] hmm it doesn't return or say anything since I edited and commited one of the file there [06:46] after issuing bzr diff sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing [06:46] you can just do 'bzr diff' [06:46] and it will tell you whethe ryou ahve edited anything or not [06:48] lifeless: it doesn't tell anything. Again, i tried modifyng one of the scripts. But after modifying it, when i issue bzr commit -m 'modifying the 3rd script' [06:48] it goes to the server opening sftp [06:48] then updates the script and says [06:48] Commited 3 [06:48] sure [06:49] thats what I would expect [06:49] modify the script but don't commit [06:49] then run 'bzr diff' [06:49] ah i'll try [06:50] ah i see so lifeless, it will show bzr diff if not yet commited right? [06:51] yes [06:51] hence if commited, then it will update there and finalize it. [06:51] is that what you wanted to know, or something else? [06:51] ah i see, thanks lifeless... [06:51] yeah that's it [06:51] when I try to unlink test.txt [06:51] then bzr diff it shows the contents [06:51] and says it was removed... [06:52] then when i issue bzr commited -m 'removed test.txt' [06:52] it did open a log file [06:52] then how other developers would see that log? [06:52] 'bzr log' [06:52] also 'bzr log -v' [06:52] bzr diff sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing [06:52] ah i see [06:53] so bzr log lifeless, underneath to it, it does go to the server and gets information on their right, then it will return back to the user by just that 'bzr log' [06:53] yes [06:54] if they do not have a checkout you can do 'bzr log URL' [06:54] bzr log URL (URL can be from sftp)? because I found most examples using http [06:55] yes [06:56] hmm lifeless back to the /tmp/testing directory [06:56] when i try bzr log sftp://toytoy@192.168.2.10/home/toyoy/repositories/testing [06:56] it says [06:56] onbzr: ERROR: Not a branch: "sftp://toytoy@192.168.2.10/home/toyoy/repositories/" [06:57] you made a spelling error I think [06:57] toyoy is not how you spelt it earlier [06:57] hehe yeah [06:58] lifeless: 0-0 wow ! :) [06:58] love it, thanks for your help. I understand it now. my friends tutorial seems to be chatty and confusing x( [06:58] thanks for your brief tutorial. I love it ;) [07:00] my pleasure [07:38] finally, svn-1.5 next week [07:39] 'new' life for bzr-svn === emgent_ is now known as emgent [09:00] finally [09:00] I have removed the last weave_store reference [09:22] hi [09:22] i'm having problems uploading to lp's bzr [09:22] go on [09:22] i'm trying to bzr push lp:terminator [09:23] as it says on the code page [09:23] but it's trying to upload via http [09:23] which is not working [09:23] have you told bzr your lp username ? [09:24] and i do that how? [09:24] bzr launchpad-login [09:24] with bzr whoami? [09:25] * nxvl tries [09:25] woohoo [09:25] thanks [09:25] i didn't knew about the new bzr changes [09:25] i didn't upload anything since "bzr push bzr+ssh" [09:25] thanks [09:25] * nxvl HUGS lifeless and Peng [09:26] You could've still manually done that. [09:26] lp: URLs are just simple shortcuts. [09:26] They translate to http if you're not logged in, or bzr+ssh if you are. [09:26] :D [09:26] thnz [09:26] thnx === gour is now known as gour|afk === pmezard is now known as pmezard|afk [10:56] hiya, how do I add subtrees to a branch? [10:56] I have it in rich-root-pack already [12:03] mathrick@hatsumi:~/elisp$ bzr join --reference dvc [12:03] bzr: ERROR: Cannot join dvc. Trees have the same root id. [12:03] huh? [12:04] they're most definitely two different trees [12:05] but their root ids could be the same [12:05] Hello all. bzr version numbers after merges are causing great confusion with the Leo and IPython projects. Somebody on the Leo project said "if everyone starts with rev 505 and does some stuff and commits on after another you can't all get 506." which makes sense to me. Is this issues documented anywhere? If not, I think you could help lots of people, including me, if you did so. [12:06] What? [12:06] LarstiQ: howso? [12:07] edreamleo: no, each of the trees will have its own rev 505 [12:07] depending on how you merge, the other "505s" will end up as different revisions in your tree [12:08] revno is only meaningful for a single tree [12:08] what matters cross-tree is that the revisions are the same [12:08] mathrick: before there was rich root support, all the root ids (fileid of /) were TREE_ROOT [12:08] LarstiQ: oh [12:08] LarstiQ: how can I change that? [12:08] mathrick: import bzrlib.branch; bzrlib.branch.Branch.open('.').basis_tree().path2id('/') [12:09] the top-level repo is under my control [12:09] mathrick: hmm, been a while [12:10] * LarstiQ knows how to set if through the bzrlib api, but not sure on what the procedure is in converting an older branch [12:10] mathrick: it seems that rev numbers aren't documented. It would be "soothing" to newbies if we could understand where rev numbers like 507.2.2 came from. True, bzr log does show the renumbered branches, but I think a discussion in the docs somewhere would help. [12:12] edreamleo: revnos are determined by the lefthand side ('mainline') of the revision DAG of a branch [12:13] edreamleo: as an aside, revids (and not revnos) globally uniquely define a revision. See bzr log --show-ids for example [12:14] edreamleo: hmm, is that really an issue? It only shows up in commit logs for merge revisions, where you can immediately see it's a merge [12:14] edreamleo: Merged revisions, the indented ones in bzr log output, get dotted revnos, the first number is the same as the revno of the revision in the current branch where they branched from. [12:15] otherwise the whole merge will be just 506 in your tree [12:16] LarstiQ: if you can give me a snippet to set it on a fresh tree, it's no problem, I can just replay commits onto the new branch [12:17] mathrick: on a fresh tree created with a rich root format, it should already be rich. [12:17] aha [12:17] mathrick: you don't want to keep your revisions? [12:18] mathrick: It's "really" an issue only in the sense that it confuses newbies. True, the log is about as clear as it could be. The problem is, that newbies think there recently committed changes went away, depending on what the "main" revno is, and newbies then don't think to look at the log. I strongly suspect the revnums are fine, it's just a learning problem with bzr. But I know for sure that it is confusing for several sets of n [12:18] LarstiQ: I do, but can't I merge/replay them from the old tree? [12:18] mathrick: you can merge them, 'replay' made me think of something different [12:18] although to be honest, in that particular tree I don't care all that much, as long as functionally equivalent revs are present, it's just my conf dir [12:19] mathrick: you should be able to do something with moving things to a subdir, then merging into a new tree and removing everything to the root, or some such [12:19] "removing everything to the root"? [12:20] edreamleo: your message got truncated [12:20] after " several sets of" [12:20] mathrick: sorry, 'removing' is ambigious [12:20] mathrick: that should be 'moving everything back to' [12:21] mathrick: sorry about that. Some forums like one-liners. [12:21] mathrick: It's "really" an issue only in the sense that it confuses newbies. True, the log is about as clear as it could be. [12:21] mathrick: The problem is, that newbies think there recently committed changes went away, depending on what the "main" revno is, and newbies then don't think to look at the log. [12:22] mathrick: I strongly suspect the revnums are fine, it's just a learning problem with bzr. But I know for sure that it is confusing for several sets of newbies. [12:23] edreamleo: have you seen the revision ids with --show-ids? [12:23] edreamleo: ah, so you mean they branch at 504, commit "foo" at 505, merge someone else's tree where 505 is "bar", then wonder why they still don't have the bar in their tree, since 505 is "foo"? [12:25] mathrick: yes, I believe that something like that is what is confusing folks. [12:25] edreamleo: that is a problem when you think of "the" repo and checkouts, instead of a set of DAGs [12:26] To repeat, once people think to look at the log they are probably going to be reassured [12:26] edreamleo: however, how do they find out 505 is "foo" and not "bar" if not through the log? [12:26] Interesting. Afaik, dag's are never mentioned in the docs. [12:28] I guess a little technical aside mentioning DAGs and how trees being DAGs means they can be non-identical yet equivalent could help [12:28] mathrick: here is the original report on http://groups.google.com/group/leo-editor [12:29] I committed the leoSettings.leo file with a couple of vi emulator changes as revision 509. [12:29] Later, with Edwards updates the leoSettings.leo changes moved to revision 511 and the revision description that I entered is gone. [12:30] That's the essence of the report. Does that make any sense to you? I'm totally confused :-) [12:30] * LarstiQ starts up X and a browser [12:30] edreamleo: this one? http://groups.google.com/group/leo-editor/browse_thread/thread/a207aa1ba5247363 [12:31] mathrick: yes, that's the thread [12:32] edreamleo: ok, did you commit on a branch and pushed, or committed on a checkout? [12:32] my workflow is to commit and push [12:32] the two look similar, but are fundamentally different when it comes to commits [12:33] edreamleo: aha, then indeed you will never get the same revnos if there's been intermediate traffic on the target branch [12:33] edreamleo: can I have your mainline branch URL? [12:35] mathrick: https://code.launchpad.net/~leo-editor-team/leo-editor/trunk [12:38] edreamleo: ah, yes, I suppose you have looked at the log already? [12:38] if no, bzr log https://code.launchpad.net/~leo-editor-team/leo-editor/trunk | less [12:38] edreamleo: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#understanding-revision-numbers [12:39] edreamleo: and also 1.2.2, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#id19 [12:40] LarstiQ: thanks for these urls! [12:41] edreamleo: np :) [12:41] LarstiQ: I suppose specifically mentioning implications of merges in http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#understanding-revision-numbers would help, tho [12:41] mathrick: Aha. I have only looked at my local log... [12:41] mathrick: yes, patches appreciated :) [12:41] mathrick, edreamleo: or something for http://bazaar-vcs.org/FAQ [12:42] LarstiQ: ok, how do I contribute to the FAQ? [12:43] mathrick: I think the FAQ is just a wiki page [12:43] ah [12:43] at least, I can't find it in the bzr.dev source tree [12:44] mathrick: for the user-guide, bzr.dev/doc/en/user-guide/zen.txt [12:44] mhm [12:46] edreamleo: out of curiosity, what is your local log like? The revisions should stay intact there [12:46] Thanks all. I'll post this discussion on the thread I gave above on leo-editor. I think it will help. [12:47] mathrick: it looks the same as the global log to my untrained eyes. [12:47] oh, do you have an URL? [12:47] edreamleo: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#id27 might also be of use [12:48] edreamleo: you can do things like bzr diff -r -3..-1 for example [12:50] edreamleo: the key thing to take away here is that what uniquely identifies a revision is the revision _id_ (revid for short, example: pqm@pqm.ubuntu.com-20080606135624-1ambbf8pct52xfh8) and a revision _number_ (revno for short, simple integers for mainline revisions, or dotted for merged) is just a convenient shorthand in a particular branch [12:51] LarstiQ: thanks. I'll post this to leo-editor. [12:51] edreamleo: the former is always the same for a particular revision, the latter can change if the mainline changes. (I locally commit 505, someone else can merge that into their 505, then mine will probably be 504.1.1) [12:52] edreamleo: also practice with `bzr log --show-ids -r -3..-1` and then `bzr diff -r revid:..revid:` [12:52] edreamleo: that should give your users/developers a better grasp on the differences I hope. [12:54] LarstiQ: Excellent: practical usage tips will certainly help. [12:54] edreamleo: and as mathrick said, if people fear their changes have been lost, have a good look at the log output and search for merged revisions. (You can search for a commit log with `bzr log -m `) [12:54] edreamleo: oh! And `bzr missing` [12:54] edreamleo: bzr missing will compare two branches and tell you which revisions the one has the other hasn't. [12:56] Ok. Enough for now. This is plenty for us newbies to digest. Again, many thanks. [12:57] * LarstiQ stops :) [12:57] edreamleo: feel free to ask more questions later on. === Toksyuryel` is now known as Toksyuryel [13:18] LarstiQ: http://bazaar-vcs.org/FAQ#head-c45efef970ac690a0e997fbc904c3ea989e3fcea <-- looks good? [13:40] hmm [13:41] that merge messed up my history somehow [13:41] I get revnos such as -3 now [13:46] lifeless: are you there? [13:50] revision numbers suck [13:57] I recreated it, and I still can't get a tree with root id other than TREE_ROOT [13:57] if I pull from the existing branch onto an empty tree, I will get the same id [13:57] mathrick: looks good to me [13:58] mathrick: ah yes, the root id is only set after the first commit [13:58] Pieter: they're perfectly fine if you know what they are [13:58] yeah, and if I commit, the branches become unmergeable [13:59] ok, let me see if I can figure out how to do this [13:59] * LarstiQ will be afi for a couple of minutes [13:59] if I commit after merge, I get this: [13:59] deleted [13:59] working tree is out of date, run 'bzr update' [13:59] Committed revision 1. === asabil_ is now known as asabil [14:33] hi [15:17] LarstiQ: can blender edit art of illusion files ? [15:18] lifeless: never heard of art of illusion before, no clue what fileformats it supports === pmezard|afk is now known as pmezard [15:59] did something change in difftools? [16:00] I'm sure that bzr diff --using=meld used to open one window with the changes [16:00] now it opens one per file [16:00] in fact, I don't have difftools installed -- did --using find its way into bzr proper? [16:01] Keybuk: since 1.1rc1 according to NEWS === mario_ is now known as pygi [16:03] but it runs multiple tools for each file, rather than just one? :-( [16:09] ah, installing difftools makes it use just one :p [16:10] Sounds like a bug to me, but I don't use --using. [16:11] * spiv -> bed [17:54] Hi, Guys! [17:54] I'm having problems installing the bzr plugin for eclipse on hardy [17:54] can anybody help me? [17:58] when I try to configure it, I get a line of errors on top (not the bzr-xmloutput plugin problem, though) [17:59] http://www.pastebin.ca/1041360 [19:31] hmm, how can I fix a "RevisionNotPresent: Revision {...} not present in "revisions.kndx"." in a bzr merge ? === rockstar_ is now known as rockstar [20:15] lifeless: so I used cvsps to do a one-time conversion of an old CVS package repo to bzr, and afterwards someone noted that the contents of the bzr branches don't actually match what was tagged in the CVS repo... [20:17] lifeless: halp :) [21:24] heya [21:25] lifeless: are you there? [22:47] moin