[00:22] <tro> i'm trying to convert a svn repository into a bzr one. i just did "bzr svn-import --all --trees http://...mysvnrepo/project ../project-bzr", but there are no working trees in ../project-bzr. it's a repository, in fact. how do i get a branch from that?
[00:22] <tro> i'm using bzr 1.7 and bzr-svn 0.4.13
[00:23] <jelmer> tro, are any branches created?
[00:39] <tro> jelmer: i'm not sure. it's just a .bzr directory inside. the size looks about right
[00:39] <tro> and i saw it retrieving revisions one by one
[00:39] <jelmer> tro, did you specify --scheme ?
[00:40] <tro> nope. i have no trunk/branches/tags. it's just one directory per project
[00:41] <tro> should i have done "--scheme none"?
[00:51] <tro> jelmer: would it work better if i had an svnadmin dump?
[00:52] <jelmer> tro, if you have just one directory per project, use "bzr branch"
[00:52] <jelmer> rather than svn-import
[00:52] <jelmer> svn-import is for complete repositories
[00:52] <tro> ah
[01:00] <tro> jelmer: tried bzr branch. got: "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("REPORT of '/svn/!svn/vcc/default': Chunk delimiter was invalid (http://glyphy.com)", 175002)"
[01:00] <tro> and then a stacktrace
[01:01] <jelmer> tro, I don't recall seeing that error before - any chance you can file a bug?
[01:01] <jelmer> tro, are you on Mac OS X?
[01:02] <tro> jelmer: ubuntu
[01:04] <tro> jelmer: should i file a bug in the standard bzr place? https://bugs.launchpad.net/bzr
[01:04] <tro> or is there a bzr-svn specific place too?
[01:04] <jelmer> launchpad.net/bzr-svn
[01:05] <jelmer> tro, is this a public repository?
[01:05] <tro> jelmer: no, sorry
[01:06] <tro> it's using http basic
[01:07] <tro> i pointed bzr branch to a working copy. should i have pointed it to the repository instead?
[01:10] <tro> jelmer: i'll try with a public repo as well
[01:11] <tro> works fine with a public  repository on the same server
[01:12] <jelmer> tro, it's hard to do anything about it if I can't reproduce it :-/
[01:15] <tro> jelmer: i understand. i'll try a few things here. i'll see if i can create a new private repo where the problem occurs. then i could just give you a password to that
[01:25] <tro> jelmer: works fine with a simple project in a private repo. darn.
[01:26] <jml> lifeless: did I return your umbrella?
[01:27] <tro> the one i'm trying to branch has lots of renames/moves and additions/deletions
[01:28] <tro> jelmer: bug for this: https://bugs.launchpad.net/bzr-svn/+bug/275643
[01:28] <jelmer> tro, This shouldn't be related to that
[01:28] <jelmer> tro, The error comes from within the Subversion layer
[01:29] <tro> jelmer: do you think downgrading to subversion 1.4 would help?
[01:30] <lifeless> jml: I think not
[01:31] <jelmer> tro: it could - I'm not sure what's triggering this error
[01:31] <tro> meanwhile, i've got an svnadmin dump file. can i create branches out of that?
[01:31] <jml> lifeless: ok. thanks.
[01:31] <jelmer> tro, not with bzr-svn (it will just create a repository from the dump file and access that like it is currently)
[01:32] <jelmer> tro, what you may want to try though is to access the repository locally
[01:32] <jelmer> tro, specify a file:// url rather than a http:// url
[01:34] <tro> jelmer: the remote svn repository is hosted. i'm not sure if i'll be able to install the dev svn libraries there
[01:34] <tro> oh, but i can certainly recreate the repo locally
[01:34] <jelmer> yeah
[02:14] <alperkanat> hey there.. anyone here using nginx with bazaar ?
[02:20] <tro> jelmer: i recreated the remote repository locally from a "svnadmin dump". i can create a branch now, but not all revisions are there. many were skipped.
[02:21] <jelmer> tro, skipped in what sense?
[02:21] <jelmer> hi alperkanat
[02:21] <tro> the revnos don't map 1:1. bzr revision 1 started at svn revision 7
[02:21] <alperkanat> jelmer: hi ?
[02:22] <jelmer> tro, that's correct - see the FAQ
[02:23] <jelmer> alperkanat, just replying to your "hey there..."
[02:23] <alperkanat> oh ok :)
[02:23] <tro> jelmer: ah. in that case it worked fine
[02:25] <tro> i wonder what was wrong, though. i'm sorry, i can't make that repo public, but maybe i can help you gather some more debug data?
[02:45] <poolie> hello lifeless
[03:09] <lifeless> hi poolie
[03:09] <lifeless> hey, tomorrow, want to spend the day together, your place?
[03:09] <poolie> that would be great
[03:09] <lifeless> cool, midmorning start?
[03:10] <lifeless> s/start/arrival/ (clarity FTW)
[03:11] <poolie> hm
[03:12] <poolie> i'm just imagining you saying "so i woke up at 5am therefore midmorning is 7:10, so get out of bed"!
[03:12] <poolie> :)
[03:12] <lifeless> :>
[03:12] <poolie> but about 9:30-11:30 would be fine :)
[03:35] <lifeless> mmmm pie
[04:01] <dlee> Apologies, I probably missed this:  Which is the right 1.7 release Windows installer bzr version now?
[04:02] <poolie> dlee, i think there's no 1.7.rc1 installer yet
[04:02] <poolie> so 1.7 would be the way to go
[04:03] <dlee> The "Windows installer(s_
[04:03] <dlee> installer(s)" page shows an rc1, but I thought that was older than 1.7 release.
[04:05] <poolie> this one -> https://edge.launchpad.net/bzr/+download ?
[04:06] <poolie> yes that is kind of confusing
[04:07] <dlee> Yes that one
[04:07] <poolie> you want bzr-setup-1.7-1.exe, second from the top
[04:07] <poolie> i'm just going to file a bug that this table is hard to understand :)
[04:08] <dlee> The Instructions link, after Windows installer(s), still only lists 1.6.1.  I seem to have gotten a developer interested in Bazaar, but I've been having him wait for the 1.7 installer.  Thanks for the bug; I didn't think of filing that.
[04:13] <dlee> Thanks much
[04:13]  * dlee goes to update some systems...
[04:14] <poolie> dlee, it's bug 275677 if you'd like to add anything
[04:54] <poolie> spiv, i just noticed you have 6 approved patches...
[06:36] <poolie> markh: i was going to try making a 1.7.1rc1 exe soon
[06:36] <poolie> unless you're doing it at the moment, in any case the practice and making sure it's documented might be useful...
[06:55] <vila> hi all!
[06:55] <poolie> hello vila
[07:11] <poolie> spiv, ping?
[07:13] <spiv> poolie: pong
[07:17] <poolie> spiv, how's it going?
[07:17] <poolie> want any reviews?
[07:19] <markh> poolie: I haven't started yet.  By all means have a go and see if the wiki is up to date.  It is fairly complicated though - eg, you need c compilers, etc
[07:19] <poolie> is it complicated to do, or just to set it up?
[07:20] <markh> just setup really
[07:20] <markh> sourcing and installing the various packages etc - but once the environment is setup it is easy
[07:21] <poolie> i was thinking about getting a shared virtual server for us somewhere
[07:21] <poolie> and we could set it up on that, then just turn the crank when a release comes out
[07:22] <markh> the setup process could do with some work to make it more reliable though - eg, the "official" setup process should know exactly which "optional" components it wants and fail if they don't exist.  Nothing will prevent a build going out without paramiko, for example.
[07:22] <markh> that would be fine with me.  You will need MS Visual Studio on it
[07:22] <markh> well
[07:23] <markh> the freebie one might work to actually :)
[07:29] <vila> poolie: is http://paste.ubuntu.com/51983/ ok as a NEWS entry for python-2.6 ?
[07:30] <poolie> vila, i think 'works with python2.6' is a new portability feature
[07:31] <vila> http://paste.ubuntu.com/51985/
[07:31] <vila> :)
[07:32] <poolie> and the notes to developers about how to support it should be separate
[07:32] <poolie> if you see what i mean
[07:32] <vila> ok
[07:33] <vila> so that part should stay in INTERNALS right ?
[07:33] <poolie> right
[07:35] <vila> Overall, thins have evolved in the right direction, with recent modifications on python, less of my modifications are needed. Since you voted 'tweak', I'll submit the good bits to pqm and reply to your review to explain the differences
[07:35] <vila> s/thins/things/
[07:35] <poolie> ok, great
[07:36] <vila> oh, and my patch about proxies has been merged in python too ;-)
[07:36]  * vila grab some coffee
[07:54] <lifeless> poolie: see you tomorrow
[07:54] <poolie> see you
[08:29] <poolie> spiv, are you still around?
[09:10] <poolie> vila, i have some reservations about triaging bugs for the sake of it
[09:11] <poolie> at the end of the day would you rather classify 20 bugs or fix one?
[09:11] <vila> I'm all ears
[09:11] <poolie> (the proportion may vary)
[09:12] <poolie> i guess i'd say that reading them is good
[09:12] <vila> I think I should begin fixing when the new queue is low enough. The rationale being that duplicates can be avoided doing so and people will be more responsive if their bugs are triaged when there are still hot
[09:12] <poolie> but, if you're not going to act on it now, is recategorizing it really useful
[09:13] <vila> but if you think that's counter productive I'll stop doing that
[09:14] <vila> my main motivation is that I find too many 'New' bugs depressing :-/ More than to many 'Triaged' bugs
[09:14] <vila> s/to/too/
[09:17] <vila> Having bugs triaged and/tagged means, to me, that fixing them is therefore more organized. And also that reading the 'New' bugs doesn't have to done again
[09:17] <vila> s/to done/to be done./
[10:00] <beuno> james_w, congrats on your MOTUship. Long overdue ;)
[10:01] <james_w> thanks beuno
[10:12] <jml> markh: have you filed a bug about those failed uploads?
[10:19] <vila> PQM blocked at 'merge successful' again, I /msged mthaddon, but I'm not sure he's online...
[10:30] <thumper> Odd_Bloke: ping
[10:32] <Odd_Bloke> thumper: Pong, for something brief.
[10:32] <Odd_Bloke> I'm at work ATM.
[10:45] <jml> Odd_Bloke: that never stops us from talking on IRC! :P
[10:46] <Odd_Bloke> Yeah, but your boss is much less likely to walk into the room in which you're working. ;)
[10:46] <jml> Odd_Bloke: he's on most of the IRC channels though :)
[10:47] <Odd_Bloke> Touche.
[10:49] <rawler_> does anyone know a nice way to rebase and drop a revision..
[10:49] <rawler_> basically, I have two branches, whereas HEAD@A is the branch-point of branch B..
[10:50]  * thumper stabs config-manager
[10:50] <thumper> lifeless: oi
[10:50] <thumper> lifeless: how am I supposed to run "make check" for pqm on a clean hardy machine?
[10:50] <rawler_> I have a bunch of revisions on top of the branch-point in branch B, but would like to drop one close to the branch-point.. any ideas?
[10:50] <thumper> lifeless: config-manager says it needs pybaz, and pybaz says "isn't installable"
[10:52] <Odd_Bloke> thumper: You can move the imports for config-manager to where they are actually used.
[10:52] <thumper> Odd_Bloke: got a branch for that?
[10:54] <james_w> thumper: you are using config-manager from the hardy package?
[10:54] <thumper> james_w: config-manager: Depends: pybaz but it is not installable
[10:54] <james_w> sucks
[10:54] <thumper> james_w: that is what I get if I try to install config-manager
[10:55] <james_w> bug 235952
[10:55]  * thumper stabs unsupported packages
[11:00] <Odd_Bloke> thumper: I don't think so, no.
[11:00] <Odd_Bloke> It's quite obvious.
[11:00]  * thumper throws in the towel for today
[11:08] <thrope> hi - i'm trying to checkout a google code svn repository using bzr-svn
[11:08] <thrope> but I'm having toruble authenticating
[11:10] <thrope> ah ok - got it sorry for the noise
[11:10] <Odd_Bloke> thrope: Google Code is a PITA, don't worry about it.
[11:12] <james_w> erm, I didn't think config-manager worked with other systems as well.
[11:13] <james_w> It only ships an arch implementation though
[11:13] <Odd_Bloke> james_w: It has a bzr implementation.
[11:15] <james_w> Odd_Bloke: ah yeah, it's just hidden. Thanks.
[11:22] <Odd_Bloke> james_w: It's basically a mess. :p
[12:15] <thrope> oh - turns out it didnt remember my password on the google code svn checkout... also I have to enter it 3 times
[12:15] <thrope> any idea whats going on there?
[12:18] <jelmer> thrope, bzr's authentication layer doesn't cache passwords yet
[12:18] <thrope> oh
[12:19] <thrope> any idea why I need to enter it 3 times?
[12:20] <thrope> http://pastebin.com/m7c5b0229
[12:22] <jelmer> three connections are made to the server
[12:22] <jelmer> but since bzr doesn't cache the password, you have to re-enter it each time it needs the password
[12:22] <thrope> oh
[12:22] <thrope> any idea when the caching feature migth be added?
[12:23] <thrope> it makes it a bit of a pain to work with obviously
[12:23] <jakobb> thrope: http://tinyurl.com/4zl6ae
[12:24] <thrope> great thanks
[12:30] <thrope> having trouble getting it to work actually
[12:30] <thrope> is there an example anywhere for use with googlecode?
[12:31] <thrope> http://pastebin.com/m39dadb2a
[12:36] <thrope> I tried with and without path specified but it doesnt seem to work
[12:39] <ryanhaigh> is there some way to compact a bzr branch or to remove files from previous revisions, i have a branch which i was using locally which has a lot of images in it that are regularly modified, i have since removed those files and added them to the ignored files but they are still in previous revisions
[12:39] <bob2> there's no ui for it atm
[12:39] <thrope> in fact - even if I take the password out of the authentication.conf and enter it by hand - I can't authenticate if there are any settings in authencation.conf
[12:40] <thrope> it seems to be the user setting in authentication.conf that prevents it from working even typing the password in by hand
[12:41] <thrope> has anyone used bzr-svn with googlecode svn repository?
[12:41] <jelmer> thrope, yes, people have used it with google code before
[12:42] <thrope> jelmer: any idea what the settings in authentication.conf should be?
[12:42] <jakobb> thrope: what's the full url to the repository you're trying to access?
[12:42] <thrope> https://pyentropy.googlecode.com
[12:42] <thrope> https://pyentropy.googlecode.com/svn/trunk i guess
[12:43] <jakobb> so... why did you put 'project' in the host then?
[12:43] <thrope> sorry i replaced the name of the project in the config files i was pasting
[12:43] <jakobb> aah, oke.....
[12:44] <thrope> if i have scheme=https and host=pyentropy.googlecode.com in the file, then I can still log in typing in my password
[12:44] <thrope> as soon as I add the extra line user=user
[12:44] <thrope> then I can't log in anymore
[12:45] <jakobb> I have a suspicion...... let me check......
[12:45] <thrope> bzr: ERROR: Permission denied: ".": OPTIONS of 'https://robince@pyentropy.googlecode.com/svn/trunk': authorization failed (https://pyentropy.googlecode.com)
[12:45] <jakobb> thrope: what's the error you get?
[12:45] <jakobb> right... that's what I wanted to know
[12:45] <jakobb> what command do you give??
[12:45] <thrope> bzr up
[12:46] <thrope> it is a checkout in a shared repository
[12:46] <thrope> (ie following the manual for svn use
[12:46] <jakobb> hmmm.... that kills my suspicion
[12:47] <thrope> if I remove the user line it is fine... with the user line I get the error
[12:47] <thrope> i'm pasting the password so thats the same every time
[12:48] <thrope> maybe its becuase I checked out with https://user@host):
[12:48] <thrope> .//branch/branch.conf:bound_location = https://robince@pyentropy.googlecode.com/svn/trunk
[12:51] <jakobb> it would be surprising if that were the problem
[12:52] <ryanhaigh> so is there no way to do what i asked about, compacting the branch/removing files from previous revs?
[12:53] <jakobb> ryanhaigh: i don't think there are standard ways of doing this
[12:53] <ryanhaigh> ok thanks for the response anyway
[12:54] <jakobb> but there may be some tricks; i'm not familiar enough with version control stuff to think of something
[12:58] <jakobb> ryanhaigh: maybe there is a possibility to create a seperate branch, with the images removed??
[12:59] <jakobb> and then continue with that branch
[13:01] <jakobb> thrope: how do things work for a clean checkout? does that work with your auth.conf set?
[13:21] <thrope> jakobb: clean checout: bzr: ERROR: Invalid http response for https://pyentropy.googlecode.com/svn/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
[13:31] <jelmer> thrope, that's bug 256612
[13:34] <thrope> jelmer: ah ok - it's a bit confusing that svn+https has a deprecation warning, but is actually still required for accessing https repositories
[13:35] <thrope> in any case - trying a fresh checkout authentication still fails if I have user set in authentication.conf
[13:35] <jelmer> vila, ping
[13:36] <vila> jelmer: pong
[13:36] <vila> oh, 256162 ?
[13:36] <jelmer> any idea what could be going wrong there? ^^
[13:36] <jelmer> vila, Well, that too :-)
[13:37] <jelmer> thrope, what happens if you don't set a user in authentication.conf ?
[13:37] <thrope> it works
[13:38] <thrope> but i have to entter the password each time
[13:38] <jelmer> vila, any idea what could cause that?
[13:38] <thrope> ah actually it doesn't work
[13:38] <vila> jelmer: It would be easier for me if I could reproduce :-/ But when I try to install libsvn-dev I get:libsvn-dev:
[13:38] <vila>  Depends: libaprutil1-dev but it is not going to be installed
[13:39] <thrope> with no user, and password option it still doesn't work - i enter the password 3 times just like when it it is working then I get the permission denied
[13:39] <jelmer> what if you explicitly install libaprutil1-dev ?
[13:39] <jelmer> ah, ok - so that's no different
[13:40] <vila> ibaprutil1-dev:
[13:40] <vila>  Depends: libpq-dev but it is not going to be installed
[13:40] <jelmer> vila, and what if you install that explicitly ?
[13:41] <vila> chasing
[13:41] <vila> ibpq-dev:
[13:41] <vila>   Depends: libpq5 (=8.3.3-0ubuntu0.8.04) but 8.3.3-1~gutsy1 is to be installed
[13:41] <vila> lipq5 *is* installed 8-/
[13:42] <jelmer> what about apt-get install libpq5=8.3.3-0ubuntu0.8.04 ?
[13:42] <jelmer> or is there a reason it's still at that older version?
[13:42] <thrope> i'm on a mac incidently - but I don't think that should make any difference here
[13:44] <vila> jelmer: no idea, I never played with those
[13:45] <vila> jelmer: roughly, regarding these 401, will it help if bzr-svn get a AuthError inheriting from ConnectionError instead of InvalidHttpResponse (really unfortunate)
[13:45] <jelmer> vila: The problem is, it fails before bzr-svn is involved
[13:46] <jelmer> bzr needs to continue probing with other formats even when the first fails
[13:49] <vila> hmm
[13:55] <vila> jelmer: the problem is that if we catch the 401 then nobody will see it (if bzr-svn is not used) :-/
[13:56] <jelmer> vila: we should catch the 404 and store it, try the other backends and if they fail as well, raise the first error
[13:58] <vila> no, look at bzr.dir.find_format, the final error is already NotBranchError(path=transport.base)
[13:59] <vila> so the 401 should somehow becomes a NotBranchError, catching ConnectionError may fit
[14:00] <vila> bzrdir.probe_transport may be too restrictive or asking too much by catching only NoSuchFile
[14:01] <jelmer> vila, we should catch *any* errors that happen during probing
[14:02] <jelmer> and later raise the error raised by the first format
[14:03] <vila> imagine  a server handling format2, we try format1 (NoSuchFile), format2(bad password), format3 (blah), the user will have a hard time understanding why we say NoSuchFIle when he mistype his password...
[14:04] <vila> damned if you do, damned if you don't
[14:05] <jelmer> ah, true
[14:05] <jelmer> but that assumes the servers errors are correct
[14:06] <jelmer> while some servers return incorrect errors
[14:07] <vila> let's start with correct errors :) But yes, there is a weakness here
[14:08] <vila> The error is correct here, we use HTTP and we don't provide the right credentials so we fail
[14:09] <vila> In that case only bzr-svn knows the right credentials, but that's not the ideal answer either :-/
[14:10] <vila> May be we should collect *all* the errors and display them if no format can be found (that will be correct but ugly...)
[14:13] <vila> jelmer: the simplest solution seems to be that bzr-svn provides the credentials to bzr (so that bzr can happily fail (still ugly but nobody sees it :-( ))
[14:14] <vila> that should also address the "i enter the password 3 times"
[14:17] <awilkins> Hmm, while on the general subject, I couldn't do an anonymous branch of an SVN repo because it insisted on asking me fo auth which I didn't have
[14:18] <awilkins> Does it really need to ask for write-access to branch, or it this a peculiarity of the repo in question forcing https?
[14:19] <jelmer> vila, yeah
[14:19] <jelmer> vila, except bzr has to support prompting for Basic auth passwords then :-)
[14:20] <vila> It does prompt for passwords, it doesn't prompt for users
[14:27] <vila> all right, libsvn-dev is happy now, don't now what happened with libpq5 there, it looks like some gutsy dependency was still active
[14:27] <vila> jelmer: so what version should I get ? lp:bzr-svn ?
[14:28] <jelmer> vila, lp:~jelmer/bzr-svn/0.4
[14:29] <vila> jelmer: wil I be able to run it from linux and OSX from the same source directory ?
[14:29] <strk_away> bzr: ERROR: Cannot commit to branch BzrBranch6('file:///usr/src/gnash/gnash-head/'). It is bound to BzrBranch6('file:///usr/src/gnash/bzr/trunk/'), which is bound to sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/.
[14:29] <vila> strk_away: only one level of bind is allowed
[14:30] <strk_away> so unbind and then update ?
[14:31] <vila> unbind and then push I'd say
[14:32] <strk_away> uhm.. I was used to 'commit' for an automatic push, what am I doing wrong
[14:32] <strk> supposedly my workin tree is a checkout of bzr/trunk (local) which is bound to the remote one
[14:33] <awilkins> A checkout is a bound branch
[14:33] <strk> so what's the deal with max one level of bind allowed ?
[14:34] <awilkins> I'd imagine it's there to hedge against both complexity and the possibility of making an circular bind
[14:35] <strk> gah.. well, I committed these changes and have NO idea how to push upstream now :/
[14:35] <awilkins> strk: bzr push <my upstream branch>   ?
[14:36] <Prodoc> Good afternoon
[14:39] <Prodoc> This might be a dumb question but is it possible to use bzr in a portable manner on e.g. a USB stick under Windows? I was only able to find an installer.
[14:39] <beuno> Prodoc, sure, you can run from source
[14:39] <awilkins> Prodoc: The "exe" version should be runnably portably
[14:39] <awilkins> Prodoc: The "source" version needs python to be installed (or a portable python?)
[14:40] <Prodoc> awilkins: by the 'exe' you mean just copy the folder to a usb stick after the installation?
[14:41] <awilkins> Prodoc: AFAIK that will work ; you might also want to set up a quick batch file or something to start a command prompt with the binary on the PATH
[14:42] <awilkins> Or maybe just start "bzr shell"
[14:42]  * awilkins thinks about trying this also
[14:42] <awilkins> Sounds good for adjusting server config, etc, in a versioned way impromptu-stylee
[14:43] <Prodoc> I was wondering if it'll start complaining about the .conf file located in '\Documents and Settings\*user*\Application Data\bazaar\2.0'
[14:43] <awilkins> Hmm.
[14:43]  * awilkins moves folder
[14:45] <awilkins> It seems to recreate it, but not whine about it's absence
[14:45] <strk> I feel like I'm about to loose all my changes
[14:45] <strk> keep getting errors on every operation
[14:45] <strk> push: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/".
[14:46] <strk> trying to bind to the remote branch directly now
[14:46] <Prodoc> The file only contains the user info (name+email). Not something you want to loose though. Maybe it'll accept the file if it's located in the same folder as bazaar?
[14:48] <awilkins> Prodoc: If you also set BZR_HOME in your "start me up" file, it will take the conf from there  http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#environment-variables
[14:49] <Prodoc> ah, cool
[14:50] <Prodoc> let's see if it accepts relative paths
[14:51] <Prodoc> ow, darn...just realized that I'll probably don't have the proper rights to set the PATH
[14:51] <awilkins> Prodoc: You should be able to set PATH for your current user
[14:52] <awilkins> There's a system and  user PATH ; user PATH is often not set be default though
[14:52] <awilkins> Windows appends user PATH to system PATH
[14:53] <awilkins> It's not permanent anyway ; you're only setting the ENV variable in the context of the shell you open
[14:55] <awilkins> Create a shortcut to %comspec% /k <batch file>
[14:55] <Prodoc> yeah, but that'll get lost as soon as you start a different process, so using it in combi with eclipse isn't going to work
[14:55] <awilkins> It might still work if you start the eclipse instance from the shell
[14:56] <awilkins> That's all you're doing for bzr anyway ; starting it from an environment
[14:56] <awilkins> Which is why it get the ENV vars from that environment
[14:57]  * Prodoc wonders if it's possible to set this stuff in eclipse itself...
[14:57]  * Prodoc goes and check
[14:57] <awilkins> Isn't the email addy of the user in Eclipe a pref in bzr-eclipse?
[14:58] <Prodoc> you can set it by bzr whoami
[14:58] <awilkins> Prodoc: It's a pref in the Eclipse plugin too
[14:58] <Prodoc> ah
[14:59] <Prodoc> problem solved then :D
[15:01] <robsta> hiya
[15:01] <robsta> seems i encountered something, bzr bails out on a "diff" operation
[15:02] <robsta> what can i do to make the bugreport most useful?
[15:07] <Prodoc> darn, the latest eclipse plugin has problems
[15:08] <awilkins> Prodoc: What kind of problems?
[15:08] <Prodoc> If you try to go to the settings you'll get a big 'The current displayed page contains invalid values' error
[15:09] <awilkins> Prodoc: But you can't set the values?
[15:09] <Prodoc> nope
[15:09] <awilkins> Prodoc: Which version are you using ; that should be fixed in the latest dev snapshots
[15:10] <Prodoc> 1.1.0
[15:10] <Prodoc> with bzr-xmloutput 0.8 and eclipse 3.4.1
[15:11] <Prodoc> fixed it
[15:11] <awilkins> Hmm. That version should work. I've been using source, because I'm on Callisto and the UI stuff isn't compatible ; I've got a patched branch
[15:12] <Prodoc> I managed to set the 'Executable' value after a couple of tries
[15:12] <Prodoc> that seems to be the cause of the problems
[15:12] <Prodoc> now everything is available again without the errors
[15:13] <Prodoc> it shouldn't be a requirement though, if it's available in the PATH
[15:14] <awilkins> Prodoc: It's because it defaults to "bzr" and I don't think java applies PATHEXT
[15:14] <awilkins> And Windows knoweth not what to do with #!/bin/python
[15:25] <pcc1> hello, after upgrading from 1.3 to 1.5, htttp transport no longer works for me (seems to be trying to use the smart server): "bzr: ERROR: Transport error: Server refuses to fullfil the request" how can I force it to use the dumb server?
[15:25] <Peng_> pcc1: "bzr branch nosmart+http://example.com/..."
[15:26] <Peng_> pcc1: You should fix your web server too.
[15:26] <pcc1> unfortunately I don't run it
[15:26] <Peng_> Well...you should yell at whoever does. :P
[15:29] <Peng_> Bazaar will try to POST to http://.../your/branch/.bzr/smart. If the server returns a 404, it will gracefully fall back to using dumb HTTP, but your server seems to be doing something weird instead.
[15:30] <pcc1> it looked like it was returning a 403
[15:30] <Peng_> Oh
[15:31] <pcc1> perhaps bzr should downgrade if it gets anything other than 200
[15:52] <Prodoc> awilkins: too bad, the Eclipse plugin doesn't allow you to specify a relative path for the bzr executable. Would have solved all problems in one go, no config problems and no need to set the PATH for Windows
[15:53] <Prodoc> I'll file a RFE
[15:53] <Verterok> Prodoc: I'm out of context (just reading the backlog), a relative path?
[15:53] <Prodoc> aye, in Eclipse
[15:54] <Prodoc> here you can specify the location of bzr.exe
[15:54] <Prodoc> by being able to specify a relative path you can have a portable setup of bazaar with eclipse without any additional hassle
[15:55] <Verterok> Prodoc: ok, that wouldd be nice. but relative to what? :) the eclipse install?, the workspace?
[15:55] <Prodoc> since the prefs are not related to the workspace I'd say the eclipse folder
[15:56] <Verterok> Prodoc: actually, the prefs are stored in the workspace.
[15:57] <Prodoc> hmm...
[15:57] <Prodoc> still I'd go for the eclipse folder I think, the most stable factor
[15:58] <Verterok> Prodoc: ok, I'll take a look about how to do that, please file that RFE ;)
[15:58] <Verterok> Prodoc: Just to note, I've been playing with bzrlib.config, to add support in eclipse (i.e: to allow default username, per branch config, etc)
[15:59] <Prodoc> so if you use the browse feature to find the exe you'd get an absolute path, if you fill in the location by hand (which isn't possible at the moment) and no drive letter is specified it'll be treated as a relative path
[16:00] <Prodoc> Verterok: does that mean that a portable solution won't be working for long unless the feature to specify the config folder's location is added?
[16:01] <Verterok> Prodoc: sure, I'll check about this relative-path thingy, it sound easy to implemente :)
[16:01] <Verterok> Prodoc: not at all :)
[16:02] <Verterok> Prodoc: the preference page 'll be exactly the same
[16:02] <Verterok> Prodoc: the only difference is that bzr-eclipse 'll use the config facilities provided by bzrlib
[16:03] <Verterok> Prodoc: so, if you have a per branch config of your email (in branch.conf or in locations.conf), it 'll use that instead of the global config
[16:03] <Prodoc> (if you missed the previous bit of the portable discussion: the config file is stored in  '\Documents and Settings\*user*\Application Data\bazaar\2.0', which isn't available anyone if you go portable)
[16:04] <Prodoc> ah, cool
[16:05] <Verterok> Prodoc: my idea was to fallback to global config, but provided a preference page (in the project properties) to allow the customization of it :)
[16:05] <Verterok> s/provided/provide
[16:10] <robsta> jelmer: is there any way to work around missing ghost revs?
[16:11]  * robsta had been wondering why svn and bzr were showing different rev# for some time anyway ...
[16:15] <Prodoc> Verterok: just wondering, does the ID value in the eclipse prefs overwrite the global whoami setting of bzr at the moment?
[16:15] <Verterok> Prodoc: yeap, it uses the BZR_EMAIL env var
[16:17] <jelmer> robsta, the rev numbers being different is independent - see the FAQ
[16:17] <jelmer> robsta, I'm not sure if there's a good workaround, lifeless/abentley/jam may be able to comment better
[16:17] <Prodoc> Weird, I thought I never set that value before in Eclipse, and the value differs from the value I set by whoami. Just have made a mistake.
[16:22] <Verterok> Prodoc: it default to the current user name, but you should change that :)
[16:22] <Verterok> Prodoc: take a look for a use case for the config improvements: https://bugs.edge.launchpad.net/bzr-eclipse/+bug/264378
[16:23] <Verterok> Prodoc: in that bug, Luis comment about his problem with the global-only config, and request the per branch config :)
[16:24] <Prodoc> Ah, I was starting to think you send me the wrong link ;-)
[16:24] <Prodoc> RFE submitted by the way
[16:24] <Verterok> Prodoc: thanks!ç
[16:28] <robsta> jelmer: well, sigh, thanks anyway
[17:30] <james_w> beuno: hey, was there a bug about the plugin installer stuff you were working on?
[17:31] <james_w> I want to dupe bug 275207 to it if there was
[17:34] <jfroy|work> vila: https://code.launchpad.net/~jeanfrancois.roy/bzr/keychain-auth-rdonly *very* experimental
[17:37] <vila> jfroy|work: ok. I'll look at it
[17:38] <beuno> james_w, there should be. Let me find it...
[17:38] <jfroy|work> vila: it's really a hack at this point, but I wanted to prototype things. I need to port my _keychain module tests to the bzr test infrastructure
[17:38] <jfroy|work> although I'm guessing by things I saw that it has issues on OS X?
[17:39] <jfroy|work> I might have to rewrite the _keychain module using Pyrex as well >.>
[17:39] <vila> what ? Your proto ?
[17:40] <vila> Things will be easier if you do that in a plugin, I'll look at what you did to see what is needed
[17:43] <jfroy|work> yeah, I think a plugin + refactoring in bzr is the way to go
[17:45] <jfroy|work> Roughly, I'm thinking AuthConfig should provide authentication configuration information, such as a default user name for a particular set of domains, or servers, and then have a list of credential providers capable of giving back a password given a set of connection parameters (host, port, scheme, path, user, etc.)
[17:45] <jfroy|work> Then plugins can export or register credential providers, and we can add one for the conf file itself as well.
[17:49] <vila> That's the idea and the user decides in auth.conf, no need to register a 'plain text' credentials provider :)
[17:50] <vila> jfroy|work: I'm off, I'll try to mail you tomorrow
[17:50] <jfroy|work> I'd rather avoid the "user decides explicitly" model, in the sense that installing the keychain authentication plugin should be considered as an indication of intention by the user for bzr to check the keychain for credentials when it needs them
[17:51] <beuno> james_w, actually, seems there's no bug
[17:51] <james_w> beuno: thanks for looking, I'll open a bzr task on that one
[17:51] <jfroy|work> vila: np, I'll continue to play around in the branch until I figure out a design that seems to work and scale
[18:23] <rockstar> jelmer, ping
[18:35] <jelmer> rockstar, pong
[18:38] <abeaumont> hi, trying to push to a svn repo i got an error, because the svn repo was tagged. I solved the problem with a svn-push, but now when i try to do a pull i get the same error: 'Conflicting tags:'. How can i solve that? is svn-import the command to solve that?
[18:39] <jelmer> abeaumont, did you change any tags before you pushed?
[18:40] <abeaumont> jelmer: in svn repo? yes
[18:42] <jelmer> abeaumont, remove the tags locally and pull again
[18:44] <abeaumont> jelmer: ok, it worked, i'll have to do this everytime a new tag is done in svn or i did something wrong?
[18:45] <jelmer> abeaumont, yes
[18:45] <jelmer> abeaumont, the same thing would happen if the remote branch was a native bzr branch
[18:45] <jelmer> abeaumont, bzr tags aren't versioned
[18:45] <abeaumont> jelmer: oh, I see
[18:45] <abeaumont> jelmer: ok, thanks!
[19:27] <LeoNerd> Does bzr have an equivalent of tla/baz's "sync-tree"..? I.e. just pretend a I have some foreign merge?
[19:28] <LeoNerd> I've tried merge ; revert  but the revert even forgets the pending merges. I want to revert all the file changes -except- the pending merge.. since I know it's actuall been done anyway
[19:29] <LeoNerd> Ohwait... merge -c   doesn't actually mark it, does it?
[19:32] <luks> `bzr revert .` ?
[19:33] <luks> I don't know what sync-tree does, but revert . revers all the changes but not the pending merges
[19:33] <LeoNerd> That's not helping... it turns out   merge -c   and   merge -r 340..341   don't actually mark the mrge
[19:33] <LeoNerd> This is ... annoying
[19:33] <LeoNerd> 'bzr st' doesn't list it in pending merges
[19:33] <luks> isn't that documented on bzr help merge?
[19:34] <uws> LeoNerd: No merge tracking for cherry picking, unfortunately
[19:34] <luks> bzr doesn't track cherrypicks
[19:34] <LeoNerd> Oh...
[19:34] <uws> but at least it doesn't generate conflict if you cherry pick the same change twice (checks the ancestor and the resulting file contents, and if they match nothing happens)
[19:34] <luks> it doesn't fit the "the history is a DAG" scheme
[19:35] <LeoNerd> uws: Ah OK... that's... probably sufficient
[19:35] <uws> luks: everyone knows that history repeats itself!
[19:35] <LeoNerd> OK.. this is a bit annoying.. I've just moved the entire revision control system out of tla/baz into bzr because it's generally nicer.
[19:35] <uws> LeoNerd: yeah, it sort of works for me
[19:35] <LeoNerd> Only.. I kinda rely on those cherrypics :P
[19:45] <nosklo> hello!
[19:56] <nosklo> I am having trouble using bzr-svn could someone help me?
[19:56] <nosklo> here is the traceback: http://dpaste.com/81248/ Is it related to using a proxy? Does it support proxies?
[19:58] <jelmer> nosklo, can you reproduce this? It looks like google code is messing up
[19:58] <nosklo> jelmer, yes, it happens every time I try.
[19:59] <nosklo> jelmer, I am now trying it in a machine with a direct connection to see if it is proxy-related
[20:00] <jelmer> nosklo, bzr-svn uses the same library for network access as the svn command-line client, so a proxy in the middle shouldn't make a difference
[20:00] <nosklo> this seems proxy-related, since with a direct connection it worked out fine.
[20:01] <jelmer> ok, strange
[20:01] <nosklo> jelmer, checking proxy logs now
[20:31] <alperkanat> anyone here using bzr with mac os x leopard ?
[20:56] <thrope> jelmer: is there anyway to disable the "The svn+ syntax is deprecated, " message - it comes with every operation and I think it shouldn't be deprecated anyway, since the svn+ syntax is the only way I can access my repository
[20:56] <jelmer> thrope, Nothing other than commenting it out in the source
[20:57] <jelmer> thrope, It's correct it's deprecated - it's a bug in bzr that causes it to not work for you
[20:57] <thrope> ok - it's just its a bit like the message the python interpreter gives you when you type quite
[20:57] <thrope> *quit
[20:58] <nosklo> it is a proxy issue. It works with a direct connection. It seems to stop at random revision number - not sure what is happening yet.
[20:58] <jelmer> nosklo: what sort of request / path is failing?
[21:01] <nosklo> jelmer, PROPFIND http://formalchemy.googlecode.com/svn/!svn/vcc/default HTTP/1.1
[21:01] <nosklo> jelmer, I think (by looking at the proxy logs) that this was the last request before fail
[21:02] <jelmer> nosklo, do you still have the backtrace you got up somewhere?
[21:02] <nosklo> http://dpaste.com/81248/
[21:03] <jelmer> nosklo, can you try running something like this:
[21:03] <jelmer> svn proplist --revprop -r42 http://formalchemy.googlecode.com/svn/trunk
[21:03] <jelmer> (on the machine with the proxy)
[21:04] <nosklo> jelmer, you mean on the proxy server?
[21:06] <nosklo> jelmer, I ran it on both machines, the one behind the proxy and the one with direct connection. Both returned this: http://dpaste.com/81267/
[21:09] <jelmer> hmm, so I wonder if the proxy broke on a particular revision
[21:11] <nosklo> jelmer, problem is revision number disappears from the screen when the traceback is printed
[21:11] <johan> I'm doing a bzr checkout of a bzr+ssh:// branch, but when I do a checking the remote working tree is not updated
[21:11] <johan> s/checking/check-in/
[21:12] <uws> johan: That is intended.
[21:12] <johan> is it possible to remotely update a working tree?
[21:12] <uws> the idea is that you don't have a working tree at the remote end
[21:12] <johan> I want the working tree, this is for a website.
[21:12] <uws> there's a plugin for that I think, bzr-upload  or something like that
[21:12] <uws> others in here will know
[21:13] <johan> looks good, thanks
[21:13] <uws> johan: or the rspush stuff from bzrtools might help (doesn't work with checkouts i think)
[21:15] <jelmer> nosklo, if you set BZR_PDB=1 when running that command it should put you in a debugger
[21:15] <jelmer> nosklo, after that, run "up" followed by "print self.revnum"
[21:17] <nosklo> jelmer, *** AttributeError: 'SvnBranch' object has no attribute 'revnum'
[21:17] <jelmer> nosklo, you're running "bzr checkout http://formalchemy.googlecode.com/svn/trunk/ formalchemy" again?
[21:17] <nosklo> jelmer, yes.
[21:18] <nosklo> jelmer, weird, it seems to stop at random revisions, now the command you gave me returned "1"
[21:20] <alperkanat> how can i populate a remote directory tree ? should i do checkout then commit ?
[21:20] <alperkanat> if i branch and then push the changes, how can i populate the mainline ?
[21:23] <jelmer> nosklo, google code seems to not always be very reliable
[21:24] <jelmer> not sure how the proxy complicates that though
[21:39] <hash_g> Hi
[21:39] <hash_g> Is there a way to configure bzr to commit on change in a period of time ?
[21:39] <thumper> hash_g: ??? cron?
[21:40] <hash_g> in the bzr itself I mean
[21:41] <hash_g> I'm on win xp and don't want to write bat ;]
[21:44] <nosklo> jelmer, strange that I made thru it to the end 3 times without the proxy. Made a loop trying it behind the proxy and it is still trying, although the error is always on a random revision
[21:44] <nosklo> jelmer, I will make some tests with non-google repositories
[21:46] <uws> hash_g: You don't want to commit at random intervals. Commits are intended to mark PROGRESS, not just CHANGES. You may accidently commit broken stuff
[21:48] <nosklo> jelmer, I think I found out
[21:49] <nosklo> jelmer, it was some kind of proxy limit issue. Thanks for helping me figuring it out, sorry for the raising a bzr non-issue.
[21:49] <jelmer> nosklo: Any chance you can file a bug explaining this issue so we can add an entry to the FAQ?
[21:50] <jelmer> nosklo, (or perhaps just a patch to the FAQ?)
[21:50] <nosklo> jelmer, of course. I am just trying to fix it, and as soon as I have some full definition, I will do it.
[21:51] <hash_g> it is a web-design project html/css/png/svg so I want to see progress in time
[21:51] <hash_g> because some ideas come and gone, it all changes and I want to see how it evolved
[21:51] <nosklo> jelmer, But I was able to do the entire checkout without problems behind the proxy by stopping the entire network and not using the proxy to anything else.
[21:51] <nosklo> jelmer, anyway bzr should not die in a traceback
[21:52] <jelmer> nosklo,
[21:53] <davidstrauss> I'm getting "bzr: ERROR: Cannot lock LockDir" errors. But when I ssh directly, I have no trouble "touch"ing the file.
[21:53] <jelmer> there's not a lot it can do
[21:53] <davidstrauss> I'm running Bazaar 1.7
[21:53] <jelmer> nosklo, it gets the error from the underlying library and that doesn't provide enough information
[21:54] <davidstrauss> This is my traceback http://pastebin.com/m4fb1ee08
[21:54] <hash_g> uws so I want
[21:55] <hash_g> but don't know how
[22:02] <hash_g> and probably I would never know
[22:04] <lifeless> poolie: is 7am, is time to be waking
[22:04] <alperkanat> i've got a questions about bazaar.. i branch a project.. i make some changes and push it to a centralized server.. i guess that the mainline only has the history of changes not the actual tree ? then what happens if someone else wants to branch the mainline ? will he have the changes of mine ?
[22:34] <enobrev> can anyone tell me how to disable tortoisebzr on win32?
[22:38] <trotek> enobrev: try reinstalling and disabling the tortoisebzr option, maybe?
[22:38] <enobrev> trotek: guess i could try that.  seems silly that it can't be turned off otherwise.  thanks.
[22:47] <poolie> hello lifeless
[23:38] <abentley> lifeless: PQM appears hung.  Can you please give it a thump?
[23:45] <markh> are there any plans at all to localize things like help for options?  If not, is it expected that each GUI toolkit for example, will simply copy/paste these strings and localize them independently from each other?
[23:49] <abentley> markh: I think localization just hasn't been a priority so far.
[23:50] <markh> abentley: it looks like qbzr might want to localize some of these strings - it would seem a shame for such localizations to be done provately in its code.
[23:50] <lifeless> markh: The main concern is performance
[23:50] <lifeless> markh: e.g. docstrings are evaluated at class object construction, which is at module load time
[23:51] <lifeless> markh: so if all the command docstrings themselves were localised, we'd process and translate every help text for all commands, just by loading the module.
[23:53] <markh> lifeless: so yeah, clearly that would be bad.  But having 'bzr help foo' show localized info for the options foo takes needn't cause that, should it?
[23:53] <lifeless> markh: noone has put a patch forward without that cost, as yet.
[23:53] <james_w> lifeless: isn't that the use case for N_() ?
[23:53] <lifeless> markh: if someone were to, I'm sure it would be gladly reviewed
[23:55] <markh> lifeless: I guess I'm asking if I should encourage qbzr to try and contribute such localizations to the core rather than keep them private.  That would depend on support and help from bzr though, so I guess I'm asking if that would be forthcoming
[23:56] <lifeless> markh: I wouldn't expect anyone to cut code, if thats what you mean; AFAIK its not near the top of the pile for any of the regular contributors
[23:56] <lifeless> markh: I'm interested in its existing; I can promise to outline my concerns and review patches
[23:57] <lifeless> jam did some testing I think about a year back
[23:57] <lifeless> back online in 90m or so -> poolies
[23:58] <poolie> hello
[23:58] <poolie> see you then lifeless
[23:58] <markh> hrm - I don't think I want to take that burden on all by myself...
[23:58] <jam> lifeless, markh: from what I remember,simply doing "import gettext" was pretty expensive, and doing "gettext.install()" was also a big issue
[23:59] <jam> If we used N_() in lots of places, and then translate on-demand that would probably get us around some of the overhead.
[23:59] <markh> jam: yeah, that might be true.  I'm asking about intent and plans
[23:59] <jam> It also makes the test suite easier to run as you don't have to worry about the translation at all times
[23:59] <markh> ie, if bzr has no interest in localizations for such strings, my question is answered!