[08:04] <jelmer> JPeterson: still there?
[08:05] <JPeterson> ya
[08:05] <jelmer> JPeterson: not sure if I follow your question, if you're running tbzrcommand then you're not accessing the win32 filesystem from Linux?
[08:05] <jelmer> so bug 248333 shouldn't be relevant
[08:06] <JPeterson> jelmer: i wrote "cygwin /usr/bin/bzr"
[08:06] <JPeterson> in "tbzrcommand.exe and cygwin /usr/bin/bzr"
[08:07] <jelmer> JPeterson: that has the same limitaion though - cygwin pretends that the FS supports the X bit whereas it doesn't, and then makes it up on the fly
[08:07] <jelmer> JPeterson: is there a particular reason you're not using the native bzr executable for windows? that wouldn't have this problem.
[08:08] <tbf> is there documentation a tutorial on how to use --development-colo ?
[08:09] <jelmer> tbf: there is no reason to use --development-colo anymore, all functionality is present in --2a nowadays
[08:10] <tbf> jelmer, ok. good to know. basically fighting with the details to get this qt-creator patch accepted: https://codereview.qt-project.org/#change,37680
[08:10] <tbf> (without really understanding bzr... but well :-))
[08:11] <JPeterson> jelmer: as you can see in this http://cygwin.com/packages/ and this ftp://sourceware.org/pub/cygwinports/portslist.txt lsit there are cygwin builds of programs that there also exist windows builds for. one reason for this is that when a program is build for cygwin1.dll it understands cygwin paths.
[08:11] <tbf> jelmer, do you know where to look for the current colocated branch, when by-passing "bzr nick" for performance reasons?
[08:13] <tbf> jelmer, oh. it still is in .bzr/branch/location
[08:13] <jelmer> tbf: Ah, cool to see that work happening
[08:13] <tbf> just separated by a comma
[08:13] <JPeterson> jelmer: this applies to bzr too, using a windows build of bzr.exe is not equivalent to using a cygwin build of it.
[08:14] <jelmer> JPeterson: sure, but that's a limitation in cygwin
[08:15] <jelmer> tbf: in most cases, that's true but it might be in a different location or use a different format in the future
[08:15] <jelmer> tbf: the colocated branch support is unfinished, so I don't know if it is all that relevant at the moment
[08:15] <tbf> jelmer, yup. plus plugins messing around there
[08:16] <tbf> jelmer, seems the qtcreator maintainer for that module is using them and wants them support :-/
[08:16] <tbf> ...the burden of open source contributions... make the gatekeeper happy
[08:17] <jelmer> tbf: can you call the python method to get the branch nick?
[08:17] <tbf> (i wish python would just start up more quickly, so that one could directly call "bzr nick")
[08:17] <jelmer> tbf: or otherwise, is there a reason you can't call 'bzr nick' ?
[08:17] <tbf> jelmer, it's all C++ code. already suggested embedding the python interpreter in the plugin, to directly use bzrlib.commands.main() instead of invoking the command line tool
[08:18] <tbf> ...but seems they don't like that idea :-/
[08:18] <jelmer> tbf: looking in .bzr/branch/location is a good way of making sure the plugin breaks in the future though, if formats change
[08:18] <tbf> jelmer: that information is shown in the project tree view. synchronous code. "bzr nick" needs about 2 seconds to run on cold start and still 200 ms on warm start. way too long for ui code
[08:19] <jelmer> tbf: or if we add extra stuff to the URL after the comma
[08:19] <tbf> the really sad part: bzr.commands.main() invoked from embedded python interpreter only takes about 8 ms
[08:20] <tbf> so all the other overhead are the gazillions of modules, cpython inspects upon start
[08:20] <JPeterson> jelmer: my point is, i object to the argument "as a workaround use a windows build of bzr instead of a cygwin build". also, my first question in the post is "How do I fix the repo when this has occurred?".
[08:21] <tbf> heh... crazy idea... wondering if it'd make sense to ship shared library, that embeds the python runtime and provides direct access to libbzr.commands.main()
[08:21] <jelmer> JPeterson: what other workaround would you have us suggest?
[08:21] <tbf> bzrlib.commands.main()
[08:21] <jelmer> tbf: heh, that would work - even nicer if it was a generic shared library that others could use
[08:22] <tbf> a simple "int bzr_main(const char *argv[])" that hides all the nasty bits of the python API
[08:22] <JPeterson> jelmer: i mean, i'm reluctant to use the workaround.
[08:23] <tbf> ...that's just crazy enough, that i should try this tonight
[08:23] <jelmer> JPeterson: 'bzr revert' will change the executable bits back to the last committed revision (and will wipe all other changes since the last committed revision)
[08:23] <tbf> after all I already have a sample implementation on my disc
[08:24] <tbf> probably should just add an out-of-process mode to make the nay-sayers happy
[08:24] <JPeterson> jelmer: this contradicts what i wrote that "after "bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`" the first command still return 888"
[08:25] <jelmer> JPeterson: are you running this under cygwin as well?
[08:26] <JPeterson> jelmer: yes that refers to cygwin bzr
[08:26] <jelmer> JPeterson: because cygwin is probably telling bzr that it has successfully changed the file mode while in practice it hasn't
[08:28] <jelmer> JPeterson: I'm not sure how to fix this with cygwin bzr, to be honest
[08:30] <tbf_> (seeing how long it takes to download lp:bzr the first time on a 50 mbit line, i wonder if bzr requests data in too small chunks)
[08:32] <jelmer> tbf_: is this over bzr+ssh:// or http:// ?
[08:33] <tbf_> jelmer, bzr+ssh://bazaar.launchpad.net/+branch/bzr/
[08:33] <jelmer> tbf_: and with what version of bzr? are you saturating the connection?
[08:34] <JPeterson> jelmer: git also saves the x bit. replicating cygwin git will therefore fix cygwin bzr.
[08:35] <jelmer> JPeterson: bzr also saves the X bit in its dirstate file; comparing the X bit in the dirstate file to the X bit on the filesystem is what causes the problem
[08:35] <jelmer> JPeterson: since cygwin just pretends that all files are executable
[08:36] <jelmer> the bug you linked is about bzr checking what the filesystem actually supports, and just ignoring the X bit on the fs if it doesn't support it
[08:38] <JPeterson> jelmer: you can use #ifdef __CYGWIN__ for that.
[08:38] <JPeterson> jelmer: what i wrote before also applies to '/cygdrive/c/Program Files (x86)/Bazaar/bzr' revert `bzr diff|grep 'properties changed'|awk '{print $4}'`
[08:39] <jelmer> JPeterson: except that this is not a platform-specific thing, but a filesystem-specific thing
[08:39] <jelmer> JPeterson: the same happens if you try to access a FAT filesystem on Linux
[08:39] <JPeterson> the question "How do I fix the repo when this has occurred?" therefore is not answered by using /cygdrive/c/Program Files (x86)/Bazaar/bzr
[08:40] <jelmer> JPeterson: a patch to add an exception for cygwin would be very welcome
[08:40] <jelmer> JPeterson: that wouldn't be perfect but still a significant improvement over the current situation
[08:51] <JPeterson> jelmer: "bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`" return "bzr: ERROR: Path(s) are not versioned: ... [list of files]". how can a file from bzr diff not be versioned?
[08:52] <jelmer> JPeterson: It would be versioned in one way or another, perhaps there is something wrong with the command?
[08:52] <jelmer> what are the files it's listing?
[08:57] <JPeterson> jelmer: this list http://pastebin.com/eirVksUh
[08:57] <JPeterson> could the list be too big for the argument buffer? so that it's cut off midway
[08:58] <jelmer> JPeterson: are those files actually versioned ?
[08:58] <jelmer> JPeterson: and are you running the command in the branch root?
[08:59] <JPeterson> jelmer. how can they not be? yes.
[09:00] <jelmer> JPeterson: and bzr revert errors about all of these files?
[09:00] <jelmer> what happens if you run bzr revert manually for one of them?
[09:03] <JPeterson> jelmer: yes. bzr diff|grep 'properties changed'|wc -l return 883 and bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'` 2>&1|tr " " "\n"|wc -l 889, so it's for all files.
[09:03] <JPeterson> jelmer: that is accepted
[09:03] <jelmer> JPeterson: it sounds to me like there's something wrong in your shell magic in that case
[09:03] <JPeterson> it used to be 888 files, and a bzr revert for one or two files at a time has reduced it to 883
[09:04] <JPeterson> jelmer: there is no shell magic involved, it's a string
[09:05] <jelmer> JPeterson: it's something in backticks, that's shell magic :)
[09:05] <jelmer> JPeterson: what if you add 'head -2' to bit inside of the backticks?
[09:06] <jelmer> if that fails too then I'm inclined to blame the shell command, not bzr revert
[09:09] <JPeterson> jelmer i updated the paste with the cat -A output http://pastebin.com/eirVksUh. it's "'manual/custom.py'$". i believe that should be valid.
[09:10] <jelmer> JPeterson: it's including the quote signs in the filename
[09:12] <tbf_> jelmer, 2.5.1. will check later
[09:23] <JPeterson> jelmer: thx. i updated my post at https://bugs.launchpad.net/bzr/+bug/248333 with the answer to the question about fixing the repo that i previously wrote
[10:53] <JPeterson> jelmer: whats the bzr equivalent to "git config core.filemode false"?
[14:07] <LarstiQ> JPeterson: what does it do in git?
[14:07] <JPeterson> LarstiQ: what does what do?
[14:07] <LarstiQ> JPeterson: "git config core.filemode false"
[14:08] <JPeterson> it disables file mode versioning
[14:08] <LarstiQ> aha
[14:09] <JPeterson> i like what youre trying to say "bzr is so good that i use bzr more than git"
[14:10] <LeoNerd> It's my first {only?} choice for personal things
[14:51] <JPeterson> wheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list?
[14:56] <LeoNerd> possibly   bzr bundle   ?
[14:57] <LeoNerd> or  bzr send
[14:59] <JPeterson> thx
[14:59] <JPeterson> "bzr log -1" return bzr: ERROR: no such option: -1
[15:00] <LeoNerd> Indeed so.
[15:00] <JPeterson> what is the intended way to print the last log?
[15:00] <LeoNerd> Perhaps you meant  -r -1 ?
[15:00] <JPeterson> last commit
[15:00] <JPeterson> ok
[15:00] <JPeterson> that gives "committer:" but no author
[15:00] <JPeterson> how do i print the author?
[15:01] <LeoNerd> I don't believe such a distinction exists
[15:01] <LeoNerd> "committer" is just the  bzr whoami  value from the time of  bzr ci
[15:01] <JPeterson> oh boy
[15:02] <JPeterson> how do i track the commit for my ohloh account?
[15:02] <JPeterson> how does ohloh know i authored the patch?
[15:03] <LarstiQ> LeoNerd: that distinction does exist
[15:03] <LarstiQ> JPeterson: bzr commit --author to set it
[15:04] <JPeterson> LarstiQ: thx. how do i read it?
[15:04] <LarstiQ> JPeterson: for me, it is certainly true that I use bzr almost exclusively over git
[15:04] <JPeterson> whatever
[15:04] <LarstiQ> JPeterson: it should be included in the log output when set?
[15:04] <JPeterson> ok
[15:04] <JPeterson> thx
[15:05] <LarstiQ> JPeterson: but the more general point is that people might not be familiar with what you are talking about
[15:05] <JPeterson> LarstiQ: an author is someone who write something, kind of
[15:06]  * LarstiQ was referring to the core.filemode question
[15:08] <JPeterson> LarstiQ: i know
[15:08] <LarstiQ> ok
[15:08] <JPeterson> well no id didnt know that for certain, but i was certain you knew what author is
[15:13] <LarstiQ> JPeterson: programmatically, if you have a Revision object, .get_apparent_authors() will give you the names of the authors if set, or the committer otherwise
[15:14] <JPeterson> thx
[15:21] <JPeterson> this {{{rm -rf .bzr; rm *; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"test" --author "test"; bzr log; bzr bundle -r-1 -o1.patch && bzr uncommit && bzr merge 1.patch}}} returns "bzr: ERROR: No submit branch known or specified". whats' the right command?
[15:24] <LeoNerd> I imagine its the  bzr merge  that complains, yes?
[15:24] <LarstiQ> it's the bundle I think
[15:25] <LarstiQ> JPeterson: I'd use `bzr send upstreambranch -o1.patch` instead
[15:25] <LarstiQ> JPeterson: instead of bzr bundle
[15:25] <JPeterson> LarstiQ: what does that do?
[15:26] <JPeterson> can i look at the stuff before i send it?
[15:26] <LarstiQ> JPeterson: yes
[15:26] <LarstiQ> JPeterson: it compares your current branch with 'upstreambranch', and writes a merge directive to 1.patch
[15:27] <JPeterson> LarstiQ: it {{{rm -rf .bzr; rm *; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"test" --author "test"; bzr log; bzr send upstreambranch -o1.patch && bzr uncommit && bzr merge 1.patch}}} returns bzr: ERROR: Not a branch: "C:/Users/User/Downloads/bzr/upstreambranch/".
[15:28] <LarstiQ> JPeterson: right, you need to have an upstream
[15:28] <LarstiQ> JPeterson: in your case you could try `bzr branch . ../upstream` before the commit
[15:28] <LarstiQ> and refer to that
[15:30] <JPeterson> LarstiQ: can that be replaced with the "-f ARG, --from=ARG    Branch to generate the submission from, rather than" argument?
[15:30] <LarstiQ> JPeterson: -f replaces '.' with the argument to f
[15:31] <LarstiQ> JPeterson: so that is setting the other branch in the (submitfrom, submitto) pair
[15:31] <LarstiQ> JPeterson: doesn't seem like you can specify the submit branch (which is the _to_ location) like that
[15:32] <LarstiQ> JPeterson: what you _can_ do, is not mention it and it will use the remembered location
[15:32] <LarstiQ> JPeterson: so you could set that first and then not mention it
[15:33] <LarstiQ> JPeterson: `bzr config submit_branch=../upstream`
[15:34] <JPeterson> {{{rm -rf *; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"test" --author "test"; bzr log; bzr config submit_branch=../upstream && bzr send upstreambranch -o1.patch && bzr uncommit && bzr merge 1.patch && bzr log}}} return bzr: ERROR: Not a branch: "C:/Users/User/Downloads/bzr/upstreambranch/".
[15:39] <LarstiQ> JPeterson: yes, see the `bzr branch . ../upstream` I told you about. Also, after setting the submit_branch, leave out the 'upstreambranch' argument.
[15:57] <JPeterson> {{{rm -rf * .*; bzr init; printf '0'>'test.py'; bzr add; bzr commit -m"m0" --author "a0"; bzr log; bzr config submit_branch=../remote && bzr send -r-1 -o1.patch && bzr uncommit --force && bzr revert && bzr merge 1.patch && bzr log}}} return "bzr: ERROR: Merging into empty branches not currently supported, https://bugs.launchpad.net/bzr/+bug/308562"
[16:04] <JPeterson> {{{rm -rf * .*; bzr init; printf 'test'>'test.py'; bzr add; bzr commit -m"m9" --author "a0"; bzr branch . ../remote}}} return "bzr: ERROR: Already a branch: "../remote"."
[16:04] <JPeterson> my response is: how is that possible?
[16:04] <JPeterson> or rather, by what decree?
[16:04] <JPeterson> it doesn't seem to be by my will, so by who's will is there " Already a branch: "../remote".""?
[16:07] <JPeterson> oh, ok i get it
[16:07] <JPeterson> (i read it as ./remote)
[16:22] <JPeterson> can bzr merge update bzr log?
[16:23] <JPeterson> the reason i'm asking is because {{{rm -rf * .* ../remote; bzr init; printf '0'>'test.py'; bzr add; bzr commit -m"m0" --author "a0"; bzr branch . ../remote && bzr config submit_branch=../remote && printf '1'>'test.py'; bzr add; bzr commit -m"m1" --author "a1"; bzr log; bzr log ../remote; bzr send -o1.patch && bzr uncommit --force && bzr revert && bzr merge 1.patch && bzr log; bzr log ../remote;}}} return revno: 1 instead of revno: 2
[16:25] <JPeterson> is the author saved in the patch?
[16:25] <JPeterson> why intention with asking "[16:51] <JPeterson> wheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list?" was how to write author to the patch
[16:28] <JPeterson> (and commit message)
[16:44] <mgedmin> whoever added the "use 'bzr push :parent'" suggestion to the 'bzr push' error message in a fresh checkou^Wbranch: THANK YOU!
[16:51] <LeoNerd> Ooh, nice
[16:57] <jelmer> mgedmin: you're welcome!
[22:59] <bjp> i've been using bzrlib in one of my scripts for a little bit now and it's 'mostly' working smoothly.
[22:59] <bjp> it occationally hangs, though, and right now it's hanging on WorkingTree.open()
[22:59] <bjp> is there a way i can tell what its doing or how its failing?
[23:00] <lifeless> bjp: hit ctrl-\
[23:00] <lifeless> that will drop you into a debugger
[23:00] <lifeless> if you've installed the post mortem hook
[23:00] <lifeless> if you haven't, you may want to , its super useful
[23:00] <lifeless> failing that, check ~/.bzr.log, or whereever you are logging output to, its probably opening a network branch/repository
[23:01] <bjp> yea it's a lightweight checkout
[23:01] <bjp> i haven't installed any hooks
[23:03] <bjp> i don't see any bzr logs (i'm on windows)
[23:06] <bjp> weird
[23:06] <bjp> it's a batch job, it kept hanging on the 6th branch
[23:28] <lifeless> bjp: bzrlib.breakin contains the postmortem hook
[23:28] <lifeless> bjp: I believe it works on windows - have a look at pydoc bzrlib.breakin -
[23:30] <jelmer> bjp: note that if the working tree has a remote branch or a bound remote branch, it might try to be contacting that server
[23:30] <jelmer> *be trying to contact
[23:31] <bjp> it is, the branches are on a server on the LAN
[23:32] <bjp> so i just called hook_debugger_to_signal() to get the hook?
[23:36] <lifeless> yeah
[23:36] <lifeless> then if it hangs hit the magic key
[23:36] <lifeless> and you should find yourself in pdb
[23:36] <bjp> k, i put it in, now i just gotta wait till it hangs again