[01:35] does anybody know if there is a way to determine weather a revid is between 2 other revid's in the revision history? [01:36] AmanicA, there's no standard version [01:37] s/verison/function/ [01:37] but you can of course iterate over the ancestors of revision 1 and look for your revision until you hit revision 2 [01:37] is there a way though? [01:38] do you know of an example I can find somewhere [01:38] (eg. which command does something like this) [01:38] not aware of anything of the top of my head, sorry [01:38] thx [01:40] iterating over ancestors should be pretty easy with a Graph object though [02:36] jelmer: thanks a lot, I got it working! :) [03:33] AmanicA: graph.heads() perhaps too [03:40] lifeless: thanks, I ended up using graph.is_ancestor which claims it uses graph.heads() [03:41] (its used for `bzr tags -r 1..2` which I submitted two seconds ago :) [03:56] I'm running bzr 1.5 on Debian. I mainly use it for syncing a heap of text files between a few machines, although I also follow a couple of software projects with it as well. Is there anything to be gained by compiling and installing 1.10? [04:02] cammoblammo: speed [04:11] lifeless: Speed's not a huge factor, although it's always nice. I have had problems pulling from a project's server lately though---is that a possible cause? [04:12] cammoblammo: anything is a possible cause. details needed to analyse [04:13] lifeless: I knew you'd say that ;-) I'll try to replicate it when I get a chance. It's not a problem. === mark1 is now known as markh === fsagsagsa is now known as pygi === fta_out is now known as fta [14:57] hi everyone! [14:58] Last time I came here, I've been suggested to use the bzr upload plugin, and it works perfectly [14:58] except one thing [14:59] the ftp upload makes all the uploaded files having a specific "chmod" [14:59] which prevent the server to execute them [14:59] so I need to use SSH to change the "chmod" of these files [15:00] Can the plugin (or bazaar) do this itself? [15:01] (info: I upload from Windows to an Unix ftp server) [15:01] Enisseo: possibly, but I'm guessing this is going to be very ftp server dependant. [15:03] LarstiQ: you mean that this is a global option for all bzr branches? [15:04] Enisseo: no, I mean that it may not always be possible to chmod files on an ftp server, since there are a lot of broken ftp servers out there. [15:04] Enisseo: can you ftp manually to your server, and chmod them that way, instead of sshing in? [15:05] Enisseo: if not, then there isn't much that can be done unfortunately. [15:06] LarstiQ: well, what I want is to use the bzr upload plugin, which is great but does not apply the expected rights to the file it uploads [15:06] * LarstiQ nods at Enisseo [15:07] Enisseo: so could you tell me if it is possible to chmod using ftp? [15:07] Enisseo: another option for you personally, would be to use sftp instead of ftp [15:17] Hy [15:17] I was wondering if there is any way to unsplit a tree ? [15:18] duckx: if you did `bzr split` before, `bzr join` [15:18] Ok thx ;) [15:18] I have a try now [15:26] -> bzr: ERROR: Cannot join apache2/. Trees have the same root [15:27] In my case bzr is used to store revision for the /etc of my servers [15:27] I initialised /etc (bzr init) & /etc/apache2 (Both contains a .bzr subdirectory) [15:28] -> I converted the /etc directory to the --dirstate-with-subtree format ... [15:28] duckx: there should't be a need to use a -subtree format, -rich-root (e.g. 1.9-rich-root) should be sufficient [15:28] bzr version is 1.5 [15:28] ok [15:29] in that case, --rich-root-pack probably [15:29] ok [15:29] Let me retry [15:30] Well quite logicaly I hit this : [15:30] bzr: ERROR: Cannot convert to format . Does not support nested trees [15:32] In both trees (/etc & /etc/apache2) Tree root is . [15:32] Which could explain the thing (bug) I hit, as the path are not expanded [15:32] * LarstiQ only knows how to change the treeroots via bzrlib [15:33] ;) [15:34] duckx: I suppose you have multiple servers? [15:34] Indeed ;) [15:35] Changes on the servers are then send to mailing list through the mail plugin [15:35] Hi. Do I need to open up for any special port numbers, in order to access a remote bazaar repository, using the bzr+ssh protocol? (other than port 22) [15:35] Nop [15:35] I am on the server [15:35] jensen: no, it's just ssh [15:35] LarstiQ: hum, [15:35] It is local commit [15:35] duckx: you can't go back after you've upgraded to -subtree, unfortunately [15:36] That is quite logical [15:36] duckx: how willing are you to experiment? [15:37] duckx: What are you trying to do exactly though? A one-time join? Since it'll be problematic keeping "apache2" up-to-date afterwards [15:37] Well, that a kind of test server [15:37] History of revision are not so important [15:37] LarstiQ: I've made a ssh tunnel to the remote machine (which is not directly accesible from my current location), I am able to successfully connect to it with a standard ssh client, but for some reason, bzr fails, with an "ERROR: Connection close: ..."-message. [15:37] duckx: you'd want "bzr join --reference" for that, which is still experimental [15:37] ok lets test [15:38] jensen: the two tree roots are still the same then? [15:39] yeah, it should be. [15:39] Indeed bzr: ERROR: Cannot join apache2/. Trees have the same root id. [15:39] ehm [15:39] s/jensen/jelmer/ [15:40] duckx: is it an option to `bzr init` and use a rich-root format from the start, so that it will set the tree root to something unique? [15:41] duckx: if not, you could 'from bzrlib.workingtree import WorkingTree; WorkingTree.open(".").set_root_id("something-unique")' [15:41] LarstiQ: hehe, [15:41] jensen: which client are you using to set up the tunnel? [15:41] i'm using putty. [15:41] Hmm, I thing I will get ride of the revision on my apache2 conf, and add them to the /etc root tree [15:42] LarstiQ: is that a problem? [15:42] jensen: I've seen some problems in this area before, having to do with aliases of tunnels [15:42] aliases? [15:42] duckx: or that :) [15:42] jensen: doesn't ring a bell? good :) [15:43] Hum, I can see, that i get far enough, to get the servers key fingerprint... [15:43] LarstiQ: hehe [15:43] jensen: did you check ~/.bzr.log for more information on the connection close? [15:43] jensen: can it find bzr on the server? [15:43] LarstiQ: No, just a sec. [15:44] LarstiQ: I believe so, the exact same command works perfectly, when i remote desktop to a desktop on the internal network. [15:45] LarstiQ: hm, is the ~/.bzr.log located some place else on windows? [15:45] +file [15:45] yes :) [15:45] :) [15:46] iirc it says where if you run `bzr --version`? [15:46] 1.9 [15:46] oh, sorry [15:46] misread that. :) [15:46] yes, it does, thanks. [15:49] hm, nothing but a Traceback, orginating in bzrlib/smart/message.pyo, L247, does'nt really ring a bell for me. [15:49] could you pastebin me the traceback? [15:49] Of course, just a sec. [15:51] LarstiQ: http://pastebin.com/m257da06d [15:52] s//username/, s//full-path/ ... [15:52] oh feh [15:52] and not a bzrlib install with source [15:52] Those should be correct, again, same command works internally on the network. [15:53] LarstiQ: should I get that? [15:53] jensen: hmm, first try if bzr gets to log something on the server [15:57] hm, doesn't seem like it.. [15:57] Me again ... [15:57] I removed my .bzr in the subtree ... [15:57] Works fine now ;) [15:58] LarstiQ: No activity when I make a new attempt. [15:59] jensen: I'm having my doubts it is finding a bzr to execute at the remote end [15:59] LarstiQ: it is possible, but it seems strange, that everything works fine from the other desktop. [16:00] jensen: does that desktop have the same ssh tunnel? [16:01] No, it is on the same internal network, so it can connect directly to the server. [16:24] bzrlib.errors.InvalidURL: Invalid url supplied to transport: "file://hestia/etc/": local urls must start with file:/// [16:24] hmmm, this is not rfc compliant dudes ;) [16:26] In my case it would be really nice if the host could appear in the base info of a branch [16:30] duckx: interesting [16:30] duckx: what would that do if the host is not the local host as well? [16:35] LarstiQ: I have got no idea ... [16:35] May be the best test would be to use urllib2 & have a try [16:36] duckx: sounds fair [16:39] http://pastebin.com/d65b05eb1 [16:39] Here is the trace I have for an unknown host lookup [16:39] Works fine with the right hosts [16:41] duckx: will you submit a patch? [16:42] Hmm, first I would like to determine the best to implement it [16:42] Because putting it by default would break one workflow [16:42] scp your tree to another host [16:43] it is only used in bzrlib.urlutils.local_path_from_url [16:43] (the posix and win32 variants) [16:43] duckx: right [16:43] bzr will break if the host could not be lookup [16:44] I am more thinking to a switch to init .... [16:44] Like add hostname [16:44] sorry --add-hostname or something [16:44] maybe we should take a step back [16:44] what is it you want to accomplish? [16:45] Well, when I commit my modification on my server (Still on the /etc tree) the branch.base is append to the mail subject [16:45] right [16:45] that is on my case file:///etc [16:46] Each time I commit on a server I should specify on what server I was working on [16:46] eg: Subject: MY_HOST I did some stuff on it [16:47] So I tried to find out a way to add the server automaticaly [16:47] That has a sense only if you work locally [16:47] maybe it is a better idea to add an option to the emailing hook? [16:47] Yeah, but options are parsed from the bazaar.conf configfile [16:47] Where you only have static information [16:48] 'include hostname in email subjects' [16:48] lol ;) That is what I was trying to say ;) [16:48] So best way is to patch email plugin right [16:48] I think so [16:48] K [16:48] At one time, I think lifeless discussed adding templating capability to the email thingy... I don't know how far that ever got. [16:49] But if it were completeish, adding a %h escape or something wouldn't be much work I'd think. [16:49] that would the more general step [16:50] Well, I am ready to hack a bit on email module ... [16:50] But I prefer to follow your instructions/point of view ;) [16:51] duckx: if you have enough time, see if there has been work done on templating, if not, ask lifeless about his plans. And then implement them :) [16:52] Short term could be a commit_include_host option in the config file ? [16:52] something like that, yes [16:52] ok [16:53] I'd say subject_include_host [16:53] Ok I am on it ;) [16:53] duckx: you'll be at fosdem I assume? [16:53] lol, I don't even know where it takes place ;) [16:54] Brussels! [16:54] Well, it is not far away ... [16:54] May be it will be a good time to find a job @ canonical ... ;) [16:54] -> my current job breaks my xxx [16:57] I am currently working @ a banck doing some wired Unix Admin tasks ... [16:58] Better than wireless admin tasks ;> [17:16] Ok patch ready ;) [17:18] LarstiQ: What the best way to submit it ? [17:19] duckx: the email plugin README doesn't mention anything? [17:20] Let me check [17:20] This should be send to the mailing list ;) [17:30] pl [17:30] ok [17:30] make sure to include in the subject that it is for the email plugin [17:37] ok [17:38] duckx: bzr/doc/developers/HACKING.txt on the code review process might be helpful too [17:46] Ok let me have a look at it [17:56] Time to go see my parents [17:56] Thx for your help dudes ! [17:56] See you [18:02] duckx: have fun! [19:07] hi [19:11] i have a problem to get a connection via ftp to my webspace [19:12] i have no chance to init my webspace as a branch [19:38] any idea [20:06] dilema: so how do you get access? [20:06] per ftp [20:07] dilema: can't you just go bzr init ftp://whatever? [20:10] matthias@matthias-laptop:/var/www/mydomain.de$ bzr init ftp://mydomain.de@mydomain.de/home/www/mydomain.de/htdocs/test/test [20:10] thumper, he required a pw [20:11] thumper, he gets it [20:11] thumper, then nothing happen [20:11] dilema: when you say nothing happens, does it hang? [20:11] thumper, i mean no feedback [20:12] dilema: I'm not sure if you normally get feedback... [20:12] thumper, ok [20:12] what if you then go `bzr info ftp://mydomain.de@mydomain.de/home/www/mydomain.de/htdocs/test/test` [20:14] thumper, wait .. [20:14] thumper, ok it looks nice, or? -> branch root: ftp://mydomain.de@mydomain.de/home/www/mydomain.de/htdocs/test/test/ [20:15] thumper, and sthing like Standalone branch (format: pack-0.92) [20:15] Hi. What work around are there for bug 302698? [20:15] Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698 [20:15] dilema: yes you have a branch there [20:15] thumper, so i can work with [20:15] garyvdm: not sure, but when you find it, I'd like to know [20:16] dilema: yes [20:16] thumper, thx ;) [20:16] garyvdm: I'd ask jam when he arrives, or poolie [20:17] thumper: I actualy know 2, but they are both pain full. 1. Delete branch and start again. 2. Install old version of bzr (1.9). [20:21] I'm trying to find a deb for 1.9 intrepid. I'm only able to find 1.10. === asac_ is now known as asac [21:55] garyvdm: installing 1.9 isn't a good workaround; 1.9 has the same problem, but doesn't notice it. i.e. it appears to succeed, but makes a repo with missing data that will cause problems later on. [21:57] garyvdm: although the traceback in that bug involves autopack, which suggests the repo already had this problem in it. [21:57] garyvdm: if there's a more recent traceback, could you pastebin it/ [21:57] ? [22:02] Hi spiv. [22:03] garyvdm: hi [22:03] Which repo would have the problem? The repo that I'm pushing from, or the repo that I'm pushing to, or the repo that I'm skated on? [22:04] *stacked [22:04] The one you are pushing to. [22:05] I can reproduce the bug as follows: [22:05] Delete the branch that I'm pushing to (lp:~qbzr-dev/qbzr/threadless-throbber/) [22:06] push -r -1 (gets stacked on lp:qbzr) [22:06] push - get error [22:06] Can you pastebin the traceback for that error? [22:06] ok [22:07] The one in the bug involves autopacking, but a fresh push shouldn't. [22:10] http://pastebin.com/m2284da73 [22:13] garyvdm: and that's with 1.10? [22:13] (final?) [22:13] Yes - deb from ppa [22:15] Huh, interesting, it hasn't taken the code path that it's supposed to if the target repo is stacked on another. [22:15] i.e. it's taken the code path for unstacked repos. [22:16] Sorry - that went over my head. [22:16] That's ok :) [22:17] Basically, it looks like that part of the code thinks the target is not stacked. [22:17] ok [22:18] Hmm, lp:qbzr is in pack-0.92 format, which means that's probably correct. [22:18] What does info -v report in your local branch? (pastebin again) [22:20] Ah - I've recently changed the format on my local. When that stack happend - the repo was using 1.9 [22:20] Ok, that's interesting. [22:21] http://pastebin.com/d2d1ed0f6 [22:21] Can you tar up the local repo and put it somewhere? (maybe chinstrap?) [22:21] ok [22:23] (I'm thinking that perhaps I was wrong, that this might actually be an issue in your local repo after all) [22:23] Sorry - whats the url for chinstrap [22:24] garyvdm: ah, nevermind, just mail it to me at andrew.bennetts@canonical.com [22:24] ok [22:26] Ok - I've sent it. I'm in South Africa - so it will get to you in Telkom time. [22:26] 3.4mb [22:28] Ok. Thanks! [22:32] garyvdm: got it [22:34] I'm busy trying the following: I've done an upgrade --1.6 on both repo and branch, and now trying to see if I can reproduce. [22:34] Thats local branch and repo. [22:37] Ok - That worked [22:40] garyvdm: interesting. I haven't been able to reproduce so far. [22:40] I upgraded to --1.9 and then pushed a new rev and it also worked. I'm confused now. [22:40] Ok - let me try one more thing - going afk [22:50] spiv: Revised steps to reproduce: [22:50] 1 - delete remote branch [22:51] 2 - *use bzr 1.11dev rev 3409* [22:51] 3. push -r -1 [22:51] 4. push - get erro [22:51] step 4 can be with 1.11 dev or 1.10 [22:52] but step 3 must be with 1.11dev [22:53] garyvdm: I'll try that [22:54] *rev 3904 [23:04] garyvdm: I have r3904, but I can't seem to reproduce :( [23:05] Ok - I did step 3 on my windows box (cause I'm running 1.11dev on it) [23:06] I don't know what's different there. [23:07] I'm going busy branching bzr.dev to my ubuntu box to see if I can reproduce it. [23:08] garyvdm: hmm. so from a different source repo? [23:08] Yes [23:10] garyvdm: try running "bzr check" on that repo or branch, just in case. [23:11] Someone else suggestive that when I first had the problem. It came up clean [23:12] Yeah, I thought it probably would. It was worth checking :) [23:23] I was not able to reproduce on my ubuntu box. I'll sign in to irc from my windows box. [23:31] spiv: I was not able to reproduce on ubuntu, but I was able to reproduce on windows. Here is another pastebin: http://pastebin.com/mc2183f1 [23:36] GaryvdM: it seems likely that there's something different about that repository. [23:36] I ran bzr check again, and noticed something I didnot notice before: 4 inconsistent parents (http://pastebin.com/m79361e1) [23:37] GaryvdM: likely it has delta records at different points than the other one? [23:37] Can I send you another tar? [23:37] Sure. [23:38] You can correct the inconsistent parents with bzr reconcile IIRC. [23:38] My guess is that that isn't the issue, but I'm not very confident about that. === verterok is now known as verterok|away [23:55] spiv: reconcile did not fix. [23:55] Did you get my tar? [23:56] GaryvdM: ah, yes