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