[00:13] <jeremy> hi
[00:15] <bullfrog1492> anyone here?
[00:16] <bullfrog1492> the bzreclipse download is down @ the only mirror that still seems to be up: http://verterok.com.ar/bzr-eclipse/update-site/
[00:16] <bullfrog1492> please advise.
[00:23] <jelmer> verterok: ^
[00:34] <mgz> poolie or someone else in charge, do I need to bug for contributor agreement for lp:~zigarn/bzr/440472-string-bugtracker to be merged?
[00:37] <lifeless> I think so
[03:09] <anteru> Hi
[03:09] <anteru> Is there anyone working on the website?
[04:10] <mwhudson> does anyone know what
 this means:
  - either LP team supports the code base
  - or the distro have it in main and support the code base
  - no *new* SPOFs
  - transparent
  - no *slower* than what we have today
  - no *higher* expected maintenance overhead (stability, corruption, robustness)
 you could always migrate the librarian to S3 ...
[04:10] <mwhudson> baaaaa
[04:10] <mwhudson> does anyone know what
[04:10] <mwhudson> AttributeError: 'Tag' object has no attribute 'parents'
[04:10] <mwhudson> implies?
[04:10] <mwhudson> trunk dulwich, git & bzr
[04:13] <fullermd> Seems to me I've heard reports of that, and it was a result of some API slippage among pieces.
[04:13] <fullermd> But I don't remember any details.
[04:13] <mwhudson> reverting to the most recent tags on bzr-git and dulwich gets different errors :(
[04:14] <fullermd> See?  Progress!
[04:54] <mwhudson> i think it might be that imports from local git repos are busticated?
[05:35] <verterok> bullfrog1492: hi, sorry. I'll contact the owner of the server, I can't even login via ssh
[06:05] <verterok> bullfrog1492: fyi, it seems to be a dns problem, should be fixed pretty soon. in the meantime the update site is accesible in a different domain: http://guille.beuno.com.ar/bzr-eclipse/update-site/
[06:12] <johnf> What does "inconsistent parents" mean in a bzr check?
[06:12] <spiv> johnf: short answer: nothing important
[06:13] <spiv> (I'm not really here, hopefully vila or someone can go into more detail if you need it)
[06:13] <johnf> spiv: yeah wondering why it occurs. Related to the bzr repository analysis I'm doing
[06:16] <mwhudson> johnf: i think it means that the file graph and the revision graph don't always specify the parent revids in the same order
[06:24] <lifeless> mwhudson: well, I know what the former means.
[06:24] <bullfrog1492> verterok: thank you very much
[06:24] <mwhudson> it's entirely possible i'm completely wrong
[06:25] <mwhudson> i actually meant to say that before lifeless's comment :)
[07:01] <bullfrog2000> verterok: I tried using http://guille.beuno.com.ar/bzr-eclipse/update-site/, but it seems to be hanging at "Calculating requirements and dependencies"
[07:01] <bullfrog2000> when i try to install
[07:44] <vila> hi all 1
 even there I manage to make typos :)
[07:48] <mwhudson> vila: are you low on caffeine, nicotine or both?
[07:49]  * vila get a needle and does an analysis...
[07:49] <vila> nope, seems correct
[07:49] <vila> ob both counts
[07:49] <vila> on
[07:49] <vila> :-(
[07:49] <vila> :-D
[07:49] <mwhudson> :-)
[07:49] <vila> should be something else then...
[08:22] <johnf> Is it possible to tell which version of bzr a particular commit was made with?
[08:23] <lifeless> its not stamped
[08:23] <lifeless> one can guess depending on how buggy it is :P
[08:23] <johnf> :)
[08:24] <vila> johnf: is it still related to the inconsistent parents ?
[08:24] <johnf> vila: no
[08:24] <vila> ok
[08:24] <johnf> do source downloads of bzr prior to 0.17 exist anywhere?
[08:25] <lifeless> lp I guess
[08:25] <johnf> only goes back to 0.17 in 2007
[08:25] <vila> johnf: if not on lp, there are tags and you may use some VCS to get back at the sources you're interested in ;)
[08:26] <fullermd> I think before that the primary downloads were off the bazaar-ng.org site.
[08:26] <johnf> good poing :)
[08:26]  * vila wonders if it
[08:26]  * vila wonders if it's a typo or pun on 'poing' meaning first in French ;)
[08:26] <fullermd> Doesn't seem accessible any more.  It just redirects itself into the wiki.
[08:26] <vila> fist not first :-(
[08:27] <fullermd> If you have to use a fist, it's best to be first   :p
[08:28] <johnf> heh
[08:30] <johnf> Has "bzr mv" always existed?
[08:30] <fullermd> As long as I've used bzr (sorta)
[08:35] <Jerub> that was one of the selling points wasn' tit?
[08:35] <Jerub> that it could rename and svn couldn't?
[08:44] <johnf> just checked out tag for 0.1 and I can move did indeed exist
[08:45] <johnf> sorry that's 0.0.5
[08:47] <vila> johnf: what kind of archeological stuff are you on ? ;)
[08:48] <johnf> vila: heh I've been asked to perform some analysis on a repository for a client, going back to 2006 :)
[08:49] <vila> johnf: oh, hmm, I hope you will be able to tell us about the interesting bits
[08:50] <vila> johnf: Is the repo public or not ?
[08:50] <johnf> vila: no it isn't
[08:50] <vila> johnf: yeah, I guessed... but better to be sure :)
[08:55] <lifeless> johnf: is this the thing you rang me about ?
[08:55] <johnf> lifeless: yes
[08:55] <lifeless> nice
[08:55] <lifeless> gl
[08:58] <starenka> how can i annotate deleted file (get to know when and who deleted it)?
[09:03] <CcxCZ> starenka: bzr log <file>
[09:04] <CcxCZ> well duh
[09:04] <CcxCZ> but the file is not there
[09:04] <CcxCZ> there was some history grep plugin
[09:05] <lifeless> bzr log -v | less, and search for the path (/PATH0
[09:08] <starenka> lifeless: how come i can't | grep it?
[09:09]  * starenka shots himself in the head (bad file name :) )
[09:11] <starenka> thanks
[09:13] <bialix> heya
[09:13] <bialix> vila, mgs: ping
[09:13] <bialix> vila, mgz: ping
[09:13] <vila> bialix: pong
[09:13] <bialix> https://bugs.launchpad.net/bzr/+bug/631350/comments/11
[09:14] <bialix> vila: I'm very confused
[09:14] <bialix> the only way I can think of is to try to reproduce the same with simple python script
[09:14] <vila> wow, I can understand why, this sounds pretty awful
[09:15] <bialix> and check is this a bug in Python 2.6 or MS dlls
[09:15] <bialix> so, the tip to go back to 2.5 does not sound completely crazy this morning
[09:16] <vila> bialix: long term (and may be even short term), it may be better to diagnose and fix... I don't know what will be required to downgrade to 2.5 on windows...
[09:16] <bialix> vila: and maybe I need to look at the build machine soon. I think I should contact either jam or Garyvdm
[09:17] <vila> bialix: yup, maybe check with mgz first, he seemed to be on something
[09:18] <mgz> ah, bialix, you tried with a standalone 2.6? that was worth doing.
[09:18] <bialix> I'll wait for mgz comments. He hunted that bug very effectively yesterday
[09:18] <bialix> mgz: heya!
[09:18] <vila> bialix: and what output do you have with the 2.2.0 installer ?
[09:18] <bialix> the same as with py 2.6
[09:19] <mgz> how about something even simpler and just do `python26 -c "print 'Тест'"
[09:19] <bialix> added as comment 12
[09:19] <vila> bialix: Ok, borked then. And when you say 2.2 sources which revno ?
[09:19] <mgz> or at least see how minimal we can get a repo without bzr
[09:20] <bialix> vila, mgz: https://bugs.launchpad.net/bzr/+bug/631350/comments/13
[09:20] <vila> bialix: and make sure you have the compiled extensions too, that may be another source of differences if dirstate is involved
[09:20] <mgz> if this is a python upstream bug, great. I couldn't really believe it would be, as it's pretty giant and I found nothing on their tracker.
[09:21] <mgz> one thing to try: locale module in python 2.6
[09:21] <mgz> using the c locale has always been a great way to shoot yourself in the foot on windows
[09:21] <bialix> C:\work\Bazaar\bzr-2a\2.2>C:\Python26\python.exe -c "print u'\u0422\u0435\u0441\u0442'"
[09:21] <bialix> Тест
[09:22] <vila> mgz: works nicely on OSX too (regarding feet)
[09:22] <mgz> okay, how about with import locale;locale.set_locale('') on the front
[09:22] <mgz> (or whatever it is we do in bzr on that front)
[09:22] <bialix> vila: compiled extensions does involved here. it's all about output
[09:22] <bialix> vila: compiled extensions does NOT involved here. it's all about output
[09:23] <vila> bialix: except if they provide a different *input* :)
[09:23] <bialix> if you look at my bug report you can see that *sometimes* bzr produce correct output
[09:23] <mgz> *locale.setlocale(locale.LC_ALL, '')
[09:23] <bialix> vila: I don't think so
[09:24] <vila> bialix: should be easy to prove that it's irrelevant then ;-P
[09:24] <bialix> vila: I don't have VS2008 compiler :-P
[09:24]  * vila bangs head on desk
[09:25] <vila> bialix: waitaminute, you mean you never compile extensions yourself ?
[09:25] <bialix> I can copy pyds from bzr.exe but I'm sure  it's irrelevant
[09:25] <bialix> vila: for Python 2.5 I have VS2003
[09:26] <vila> bialix: eerk, don't do that, if they are out-of-date you'll get all sort of weirds errors
[09:26] <bialix> for Python 2.6 I need VS2008. I don't have it, and not very keen to install it right now
[09:26] <vila> bialix: ha, so you build your own bzr.exe for py25 from sources ?
[09:26] <bialix> and I'm not sure which version of mingw-gcc should support both 2.5 and 2.6
[09:27] <bialix> vila: I *can* build bzr.exe for py25, yes
[09:27] <bialix> but I don't because I prefer to dogfood official installer
[09:27]  * vila cries, we *need* a free (as in speech) versioned dev setup
[09:28]  * bialix cries too
[09:28] <vila> bialix: but how can you test your fixes ?
[09:28] <bialix> I haven't done the changes to compiled extensions yet
[09:29] <bialix> and I'm happy with Python 2.5, so if I need to test something I can build extensions for 2.5
[09:29] <mgz> okay, that repos it for me.
[09:29] <vila> mgz: repro ?
[09:29] <bialix> vila: I don't understand what you can't understand
[09:30] <vila> bialix: I didn't understand how you built extensions, now I do, you use py25 ;)
[09:30] <bialix> YES
[09:30] <vila> bialix: but stay with the installer as much as you can
[09:30] <bialix> yes, excatly
[09:31] <bialix> because somebody should file bugs about installer
[09:31] <vila> bialix: sure, what I wasn't getting was the py25/py26 difference
[09:32] <bialix> py2.3 have used old MSVS v.6; py2.4/2.5 switched to VS2003, py2.6/2.7 switched to VS2008
[09:32] <mgz> http://pastebin.ubuntu.com/489663/
[09:32] <bialix> every time it created pain in the *ss for people
[09:32] <mgz> ^that repo.
[09:33] <bialix> mgz: it's not quite correct; what sys.stdout.encoding says?
[09:33] <bialix> print is not quite correct to use here
[09:33] <mgz> cp866
[09:34] <bialix> mgz: please use unicode for Тест: u'\u0422\u0435\u0441\u0442'
[09:34] <mgz> as does locale.getpreferredencoding *prior* to calling setlocale
[09:34] <bialix> oops
[09:34] <mgz> identical.
[09:34] <bialix> does we call set_locale in bzrlib???
[09:34] <mgz> the problem is it's trying to get to a codepage from the system *language*
[09:34]  * bialix cries
[09:35] <mgz> when both the system codepage and terminal codepage are unrelated
[09:35] <mgz> so... step one, kill the locale module :)
[09:35] <bialix> kiil the chicken
[09:36] <mgz> don't know why the locale setting started mangling streams in msvc 9, but we can avoid it at least.
[09:38] <bialix> so this is either bug in python2.6+ or misfeature in python2.6+
[09:38] <bialix> I think the latter
[09:38] <mgz> well, I think python 2.6 might be able to blame it alternately on us and microsoft
[09:39] <bialix> yes, of course, of course, why not
[09:39] <bialix> I think blaming us is the right choice
[09:40]  * bialix is going crying for the rest of the day
[09:49] <mgz> well, two options I think on the fixing front
[09:50] <mgz> #1 just don't call setlocale on windows, we don't use any of the features it attempts to provide anyway
[09:51] <mgz> #2 do locale.setlocale(locale.LC_ALL, ".%d" % locale.getpreferredencoding())... but that might still mess stuff up
[09:52] <mgz> getting all that crap out of the bzr startup script would be nice, there's already some mac workaround and a giant comment in there
[09:52] <vila> mgz: time for a brzlib.osutils.locale module ?
[09:53] <vila> mgz: yup, I know this comment :-(
[09:53] <vila> mgz: and I'm pretty sure it's not accurate anymore
[09:55] <mgz> well, the flipside of that is it's a process-global setting we really only want to hit once even on platforms that benefit from it
[09:56] <mgz> but packagifying osutils and some serious sanitising is one of the things I've got notes on in case I ever have a free month :)
[09:56] <vila> mgz: all the encodings we use (terminal, output, user) are already cached so we shouldn't set it more than once anyway
[09:57] <vila> mgz: yup, but starting with locale may be a first step
[09:57] <vila> could be overkill for this bug though, just mentioning
[09:57] <vila> bbib
[10:00]  * bialix bbl
[10:54] <bialix> mgz: ping
[10:55] <mgz> pong: http://pastebin.ubuntu.com/489700/
[10:58] <mgz> just reading a confused thread on mingw-users on this too, doesn't help much
[10:59] <bialix> I've just realized I'm testing on native English Windows XP with Russian locale. I have to test on my home notebook with native Russian Windows XP
[10:59] <bialix> but after your paste I'm not sure there will be any difference
[10:59] <bialix> mgz: so this is a bug in msvcrt90.dll?
[10:59] <mgz> I think it will still be broken if the terminal and general codepage are different, unless they've special-cased that somehow
[11:00] <mgz> it's an... odd... behaviour change, at any rate
[11:00] <bialix> why anybody want to re-encode the strings -- I don't understand
[11:00] <mgz> can see why they've done it, the locale dependent c functions need to return a bytestring in some sensible encoding, so languages have a default encoding tagged on
[11:01] <bialix> heh
[11:01] <mgz> somewhere along the line they've had people expecting to be able to change the locale+codepage of the whole process like this,
[11:01] <mgz> as per this post saying "mingw should do it like msvc" <http://lists-archives.org/mingw-users/10242-problem-with-setlocale.html>
[11:01] <bialix> in python everything was easy: if you have unicode then it will be encoded on output
[11:02] <mgz> but Python 2 cheats
[11:02] <bialix> should we still file a bug against python?
[11:02] <mgz> it encodes to bytes itself then wants those kept pristine through the c library byte handling functions
[11:02] <mgz> (not a big requirement, but apparently breakable)
[11:03] <mgz> pretty much, we want to avoid this by not going near LC_CTYPE, which isn't hard because it's strictly less useful than unicodedata anyway
[11:04] <mgz> really, the only thing we *might* be using currently is strftime, for all its other flaws at least the c locale stuff lets to cherrypick categories
[11:05] <bialix> omg
[11:06] <bialix> http://msdn.microsoft.com/en-us/library/tf52y4t1(VS.71).aspx this page says that only putws (unicode version) encode the output
[11:07] <bialix> there is no indication that puts should re-encode the output
[11:07] <mgz> right, this is... talking about different things
 "The category must be either LC_ALL or LC_CTYPE to effect a change of code page."
[11:10] <mgz> That's all I can see in the docs, but the implication is they've bundled chcp-like functionality into setlocale
[11:11] <mgz> I don't quite get it, but... we can avoid this problem.
[11:13] <bialix> mgz: http://pastebin.ubuntu.com/489707/
[11:13] <mgz> yeah, it's pretty dumb.
[11:14] <bialix> but if I run chcp 1251 and repeat the same steps it's anyway borked
[11:14] <bialix> http://pastebin.ubuntu.com/489708/
[11:14] <bialix> crazy
[11:15] <bialix> if you know how to avoid this crazyness I'll +1e6 on the patch
[11:17] <mgz> don't call breakmyprogramrandomly(LC_ALL, "")... ehm, I mean, setlocale
[11:18] <mgz> I'll put up a branch to that effect for review.
[11:20] <bialix> thank you
[12:30] <ddaa> just wondering
[12:31] <ddaa> is there a hack around to provide authentication on plain bzr:// ?
[12:32] <lifeless> ssltunnel ? :P
[12:32] <ddaa> oh
[12:33] <ddaa> yep, bzr serve --port localhost:4155 woud work with tunelling
[12:33] <ddaa> but that's pointless, because then you may as well use bzr+ssh.
[12:34] <maxb> What would be neat, would be SASL auth on top of the smart server protocol
[12:39] <ddaa> I can imagine that stunnel might be easier to setup than sshd in some cases (windows...)
[12:39] <ddaa> Thanks.
[13:24] <mgz> dammit. missplaced apostrophe.
[13:25] <mgz> ...and tyop in the first sentence
[13:25] <mgz> think that's a sign of time to give up on computers and do something else
[13:43] <vila> mgz: ok, got it.
[13:44] <vila> mgz: many regressions about unicode/locale have been introduced in 2.1 when we stopped running LC_CTYPE= LANG=C LC_ALL= ./bzr selftest
[13:44] <vila> well s/in 2.1/since 2.1/
[13:45] <vila> mgz: try it on trunk :-/
[13:46] <mgz> I think this bug might be a bit harder to hit than it appeared, I wouldn't be suprised if on Alexander's all russian, all the time, box no mangling happens even though the basic code page and terminal codepage differ
[13:47] <mgz> but locale things are just a pain, there's actually some benefit on nix though as it controls a bunch of system things as well as the c language stuff
[13:49] <vila> mgz: http://paste.ubuntu.com/489776/ will remind you some things
[13:50] <mgz> yeah, that's the "don't know how to map unicode to the filesystem" joy
[13:51] <vila> mgz: not only, it doesn't *finish*
[13:52] <mgz> the tests falling over is an easier fix, must remember to do that...
[16:12] <dev001> .join #suse
[16:12] <bialix> hi jam
[16:12] <jam> morning bi
[16:12] <jam> bialix (tab fail)
[16:13] <bialix> is it possible to look at build machine? I'm interesting in py2exe.log file and/or in the content of win32_bzr.exe folder
[16:14] <bialix> I suspect we should bundle manifest files for our exe files
[16:14] <bialix> they're not currently installed with standalone installer
[16:14] <bialix> jam: ^
[16:16] <jam> bialix: the build machine is currently stopped, but we can bring it (from scratch) if you want. We'll need to trigger a fresh build to get any interesting output, though
[16:17] <bialix> Gary said he's going to build new installer tonight, maybe I should waut him then
[16:17] <bialix> wait
[17:39] <GaryvdM> Hi jam
[17:40] <GaryvdM> jam: Please may I do a build on the ec2 server
[17:40] <jam> GaryvdM: I'll spin it up
[17:40] <GaryvdM> jam: Thanks
[17:40] <GaryvdM> jam: I started building a vm, but not done yet.
[17:41] <jam> GaryvdM: i was also hoping to get it set up on vila's babune machine, but we haven't done much with that
[17:42] <jam> we should add a startup script that emails me so I know when the instance is actually running :)
[17:42] <GaryvdM> bialix probable on his way home. I read he was just talking to you.
[17:51] <jml> can I use bzrlib to fetch an http page with query parameters?
[17:54] <jam> jml: Transport.get_bytes() talks in URLs, so it should be possible
[17:54] <jml> jam: thanks.
[17:56] <vila> jml: not so sure, that rings a bell around split_url or some other url related function that get rid of the junk (err, sorry, query)
[17:57] <vila> jam: yeah, I know :-/ But clean full test suite first ;)
[17:59] <jam> anyone know the name of the app that pops up the 'enter your password for the keymanager' dialog?
[18:03] <GaryvdM> jam: what os is this on?
[18:03] <jam> GaryvdM: lucid
[18:03] <jam> I'm trying to file a bug
[18:03] <jam> the 'info' areas can take the cursor
[18:04] <jam> so if you click on the dialog to enter your password, it doesn't actually let you type
[18:04] <jam> until you click inside the edit box
[18:04] <jam> it has caught me a few times, seemed bug worthy
[18:05] <jam> I'll just file it in gnome-keyring
[18:35] <jam> jml: some questions about the codehosting stuff if you have time.
[18:36] <jam> I can find the code that starts the 'sftp' server, is that *also* the smart server code?
[18:36] <jam> The best I can find is registering the 'launch_smart_server' adapter
[18:36] <jam> but I have no clue where that actually gets invoked
[18:36] <jml> jam: you mean daemons/sftp.tac? that launches the SSH server which handles both, yes.
[18:36] <jam> jml: specifically I was looking at "make run_codehosting" which starts sftp, and tracks down...
[18:36] <jam> but thanks
[18:36] <jam> that gives me the general location
[18:37] <jml> jam: there's some code somewhere (ExecOnlySession) that makes an SSH session that allows exactly one thing: running commands
[18:37] <jam> jml: yep, I know that code, but I diddn't know what service calls that code
[18:37] <jml> jam: ahh right. it's registered as an adapter somehow, and then conch uses that when the SSH client asks for a session.
[18:37] <jam> the sftp code inherits from an Application that calls itself "sftponly"
[18:37] <jml> yeah, that's legacy, sadly.
[18:38] <jam> jml: I figured it was the only place that looked like it *could* be running it, but it certainly wasn't directly obvious :)
[18:38] <jml> because developers have no idea or control over how scripts are invoked in production, we are generally reluctant to rename them.
[18:48] <jam> jml: 'make run_codehosting' seems to invoke 'bin/run ... codebrowse' which in turn starts codebrowse via 'make run_codebrowse'. It then adds a "stop_at_exit(<make process>)".
[18:48] <jam> Does that mean when running codehosting *make* is actively running
[18:48] <jam> waiting on the exit of the loggerhead script?
[18:48] <jam> (It feels very odd to me that it indirects through make)
[18:49] <jam> (As I'm creating a new long-lived process, I'm trying to determine what the "correct" method is)
[18:49] <jml> I don't know why it indirects through make
[18:49] <jml> I didn't have anything to do with codebrowse.
[18:50] <jml> jam: someone on #launchpad-dev might know about that.
[18:55] <jml> jam: I've got to head out now. Good luck.
[18:55] <jam> np, thanks for your help jml
[19:15] <GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2.0-setup.exe
[19:15] <GaryvdM> Build of lp:~gz/bzr/setlocale_on_posix_only_631350
[19:51] <GaryvdM> For Bug 631350, I'm trying to test if the installer I built of mgz's branch fixes the the bug.
[19:51] <GaryvdM> But I can't paste the unicode into the console.
[19:51] <GaryvdM> When I try paste Тест, it comes out as ????
[19:52] <GaryvdM> Do I maybe have to change the console encoding? How?
[20:09] <HollyRain> when is used "bzr push <url>", where is stored the URL information?
[20:11] <maxb> HollyRain: In .bzr/branch/branch.conf
[20:11] <maxb> Use 'bzr info' to see it in friendly form
[20:11] <HollyRain> thanks
[20:11] <maxb> Use 'bzr push --remember' to update it without needing to edit the file manually
[20:18] <drumm> If I bzr join in something, is there a way to get that root back out so I don't have to remember where it came from for bzr merge .. ?
[21:34] <GaryvdM> :-( The windows installer specific bug are disheartening.
[21:34] <GaryvdM> *bugs
[21:51] <GaryvdM> jam: I'm done with the ec2 server. I don't know if you want to leave it on for bialix so that he can look at Bug 632465 or not.
[21:51] <GaryvdM> jam: Thanks
[21:51] <jam> GaryvdM: np, sorry to hear about the win32 installer stuff, but I'm *very* happy that it isn't me :)
[21:52] <GaryvdM> jam: All the issues seem to fallout from the python / pyqt upgrade...
[21:52] <jam> GaryvdM: I'm sure there are quite a few there, at least they aren't just plugin related :)
[22:33] <JoshBrown> I'm using qbzr and something seems to be converting my symlinked path into an incorrect expanded one:
[22:33] <JoshBrown> Run command: bzr merge ~/.bzr/snakes-game/tail-code --revision 27
[22:33] <JoshBrown> bzr: ERROR: Requested revision: u'27' does not exist in branch: BzrBranch7('file:///mnt/Home/Misc/Mine/Packages/Bazaar/snakes-game/trunk/')
[22:36] <GaryvdM> JoshBrown: I don't think that qbzr is affecting it. I think that if you ran  bzr merge ~/.bzr/snakes-game/tail-code --revision 27 from the terminal, you would get the same result.
[22:36] <maxb> JoshBrown: Can you tell us more about what branches are symlinked to what in your arrangement?
[22:37] <GaryvdM> JoshBrown: What is the output of ls -l ~/.bzr/snakes-game/
[22:38] <JoshBrown> maxb, GaryvdM: ~/.bzr → /mnt/Home/Misc/Mine/Packages/Bazaar
[22:38] <JoshBrown> maxb, GaryvdM: There are no other symlinks inside those subdirectories
[22:39] <maxb> So, um, why is it looking for the stated revnum in ..../trunk when you asked for it in ..../tail-code? :-(
[22:40] <GaryvdM> JoshBrown: what says bzr info ~/.bzr/snakes-game/tail-code
[22:41] <JoshBrown> Repository tree (format: 2a)
[22:41] <JoshBrown> Location:
[22:41] <JoshBrown>   shared repository: .bzr/snakes-game
[22:41] <JoshBrown>   repository branch: .bzr/snakes-game/tail-code
[22:42] <JoshBrown> bzr: ERROR: Parent not accessible given base "file:///home/josh/.bzr/snakes-game/tail-code/" and relative path "../../../../../../../../home/josh/.bzr/snakes-game/trunk/"
[22:43] <JoshBrown> maxb, GaryvdM: It works fine if I give it an exact filepath (i.e. '/mnt/Home/Misc/Mine/Packages/Bazaar/snakes-game/tail-code')
[22:44] <maxb> JoshBrown: Do you have a traceback in ~/.bzr.log corresponding to your original "Requested revision ... does not exist" ?
[22:46] <JoshBrown> maxb: No...
[22:46] <maxb> oh
[22:47] <maxb> I don't suppose executing 'bzr merge -Derror  ~/.bzr/snakes-game/tail-code --revision 27' produces one?
[22:48] <JoshBrown> If it helps, I actually have multiple layers of symlinks: ~/.bzr → ~/.pkg/Bazaar & ~/.pkg → /home/josh/Home/Misc/Mine/Packages
[22:49] <JoshBrown> maxb: It's already merged using an exact filepath, but I can setup a new branch to test it if you want
[22:49] <GaryvdM> Good night all - I have to wake early tomorrow...
[22:50] <maxb> JoshBrown: Well, if you have time, info that leads to finding bugs is always good
[22:56] <Buttons840> when viewing the bzr logs, there is a "branch nick" listed, this appears to default to the name of the folder your working from (forgive my terminology); is there a way to change this branch nick?
[22:56] <dash> bzr nick super-awesome-branch
[22:58] <Buttons840> are the effects retroactive on old logs?  (i'm about to tias, but if anyone wants to answer anyways)
[22:58] <maxb> No, bzr revisions are always immutable once committed
[22:58] <dash> pretty much nothing is retroactive on previous commits
[22:58] <maxb> s/pretty much //  :-)
[22:59] <dash> maxb: well 'uncommit' provides a convincing appearance. :)
[22:59] <Buttons840> is uncommit really just another commit?
[22:59] <dash> it just changes what the tip revision is
[23:00] <maxb> i.e. "these revisions may still exist on your disk, but we're ignoring the fact they once existed in this branch"
[23:12] <JoshBrown> maxb: I think this is a qbzr issue since everything works fine using plain bzr
[23:12] <maxb> that seems rather odd. Possible, but odd
[23:21] <JoshBrown> maxb: Yeah, maybe it's something to do with canonicalization of links or something like that. Anyway I'm off for now, I'll check the differences between the commands I'm running and the ones qbzr is running tomorrow. Bye, and thanks for the help!
[23:53] <ayan> how do you get a list of available branches?  i'm looking for the eqivalent to "git branch -la"
[23:55] <dash> ayan: available where?
[23:56] <ayan> available in a cloned repository.
[23:56] <dash> ayan: 'ls'
[23:57] <ayan> ah!  thank you.
[23:57] <ayan> hm.
[23:59] <ayan> hmm... maybe i should rtfm harder.
[23:59] <dash> ayan: what's wrong?
[23:59] <fullermd> And you don't clone repositories, you clone branches.  So there's not much to list  ;)