[08:04] JPeterson: still there? [08:05] ya [08:05] 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] so bug 248333 shouldn't be relevant [08:05] Launchpad bug 248333 in Bazaar "[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux" [Low,Confirmed] https://launchpad.net/bugs/248333 [08:06] jelmer: i wrote "cygwin /usr/bin/bzr" [08:06] in "tbzrcommand.exe and cygwin /usr/bin/bzr" [08:07] 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] JPeterson: is there a particular reason you're not using the native bzr executable for windows? that wouldn't have this problem. [08:08] is there documentation a tutorial on how to use --development-colo ? [08:09] tbf: there is no reason to use --development-colo anymore, all functionality is present in --2a nowadays [08:10] 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] (without really understanding bzr... but well :-)) [08:11] 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] jelmer, do you know where to look for the current colocated branch, when by-passing "bzr nick" for performance reasons? [08:13] jelmer, oh. it still is in .bzr/branch/location [08:13] tbf: Ah, cool to see that work happening [08:13] just separated by a comma [08:13] 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] JPeterson: sure, but that's a limitation in cygwin [08:15] 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] tbf: the colocated branch support is unfinished, so I don't know if it is all that relevant at the moment [08:15] jelmer, yup. plus plugins messing around there [08:16] jelmer, seems the qtcreator maintainer for that module is using them and wants them support :-/ [08:16] ...the burden of open source contributions... make the gatekeeper happy [08:17] tbf: can you call the python method to get the branch nick? [08:17] (i wish python would just start up more quickly, so that one could directly call "bzr nick") [08:17] tbf: or otherwise, is there a reason you can't call 'bzr nick' ? [08:17] 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] ...but seems they don't like that idea :-/ [08:18] 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] 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] tbf: or if we add extra stuff to the URL after the comma [08:19] the really sad part: bzr.commands.main() invoked from embedded python interpreter only takes about 8 ms [08:20] so all the other overhead are the gazillions of modules, cpython inspects upon start [08:20] 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] 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] JPeterson: what other workaround would you have us suggest? [08:21] bzrlib.commands.main() [08:21] tbf: heh, that would work - even nicer if it was a generic shared library that others could use [08:22] a simple "int bzr_main(const char *argv[])" that hides all the nasty bits of the python API [08:22] jelmer: i mean, i'm reluctant to use the workaround. [08:23] ...that's just crazy enough, that i should try this tonight [08:23] 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] after all I already have a sample implementation on my disc [08:24] probably should just add an out-of-process mode to make the nay-sayers happy [08:24] 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] JPeterson: are you running this under cygwin as well? [08:26] jelmer: yes that refers to cygwin bzr [08:26] JPeterson: because cygwin is probably telling bzr that it has successfully changed the file mode while in practice it hasn't [08:28] JPeterson: I'm not sure how to fix this with cygwin bzr, to be honest [08:30] (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] tbf_: is this over bzr+ssh:// or http:// ? [08:33] jelmer, bzr+ssh://bazaar.launchpad.net/+branch/bzr/ [08:33] tbf_: and with what version of bzr? are you saturating the connection? [08:34] jelmer: git also saves the x bit. replicating cygwin git will therefore fix cygwin bzr. [08:35] 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] JPeterson: since cygwin just pretends that all files are executable [08:36] 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] jelmer: you can use #ifdef __CYGWIN__ for that. [08:38] 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] JPeterson: except that this is not a platform-specific thing, but a filesystem-specific thing [08:39] JPeterson: the same happens if you try to access a FAT filesystem on Linux [08:39] 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] JPeterson: a patch to add an exception for cygwin would be very welcome [08:40] JPeterson: that wouldn't be perfect but still a significant improvement over the current situation [08:51] 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] JPeterson: It would be versioned in one way or another, perhaps there is something wrong with the command? [08:52] what are the files it's listing? [08:57] jelmer: this list http://pastebin.com/eirVksUh [08:57] could the list be too big for the argument buffer? so that it's cut off midway [08:58] JPeterson: are those files actually versioned ? [08:58] JPeterson: and are you running the command in the branch root? [08:59] jelmer. how can they not be? yes. [09:00] JPeterson: and bzr revert errors about all of these files? [09:00] what happens if you run bzr revert manually for one of them? [09:03] 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] jelmer: that is accepted [09:03] JPeterson: it sounds to me like there's something wrong in your shell magic in that case [09:03] 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] jelmer: there is no shell magic involved, it's a string [09:05] JPeterson: it's something in backticks, that's shell magic :) [09:05] JPeterson: what if you add 'head -2' to bit inside of the backticks? [09:06] if that fails too then I'm inclined to blame the shell command, not bzr revert [09:09] 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] JPeterson: it's including the quote signs in the filename [09:12] jelmer, 2.5.1. will check later [09:23] 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 [09:23] Ubuntu bug 248333 in Bazaar "[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux" [Low,Confirmed] [10:53] jelmer: whats the bzr equivalent to "git config core.filemode false"? === yofel_ is now known as yofel [14:07] JPeterson: what does it do in git? [14:07] LarstiQ: what does what do? [14:07] JPeterson: "git config core.filemode false" [14:08] it disables file mode versioning [14:08] aha [14:09] i like what youre trying to say "bzr is so good that i use bzr more than git" [14:10] It's my first {only?} choice for personal things [14:51] wheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list? [14:56] possibly bzr bundle ? [14:57] or bzr send [14:59] thx [14:59] "bzr log -1" return bzr: ERROR: no such option: -1 [15:00] Indeed so. [15:00] what is the intended way to print the last log? [15:00] Perhaps you meant -r -1 ? [15:00] last commit [15:00] ok [15:00] that gives "committer:" but no author [15:00] how do i print the author? [15:01] I don't believe such a distinction exists [15:01] "committer" is just the bzr whoami value from the time of bzr ci [15:01] oh boy [15:02] how do i track the commit for my ohloh account? [15:02] how does ohloh know i authored the patch? [15:03] LeoNerd: that distinction does exist [15:03] JPeterson: bzr commit --author to set it [15:04] LarstiQ: thx. how do i read it? [15:04] JPeterson: for me, it is certainly true that I use bzr almost exclusively over git [15:04] whatever [15:04] JPeterson: it should be included in the log output when set? [15:04] ok [15:04] thx [15:05] JPeterson: but the more general point is that people might not be familiar with what you are talking about [15:05] LarstiQ: an author is someone who write something, kind of [15:06] * LarstiQ was referring to the core.filemode question [15:08] LarstiQ: i know [15:08] ok [15:08] well no id didnt know that for certain, but i was certain you knew what author is [15:13] 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] thx [15:21] 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] I imagine its the bzr merge that complains, yes? [15:24] it's the bundle I think [15:25] JPeterson: I'd use `bzr send upstreambranch -o1.patch` instead [15:25] JPeterson: instead of bzr bundle [15:25] LarstiQ: what does that do? [15:26] can i look at the stuff before i send it? [15:26] JPeterson: yes [15:26] JPeterson: it compares your current branch with 'upstreambranch', and writes a merge directive to 1.patch [15:27] 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] JPeterson: right, you need to have an upstream [15:28] JPeterson: in your case you could try `bzr branch . ../upstream` before the commit [15:28] and refer to that [15:30] LarstiQ: can that be replaced with the "-f ARG, --from=ARG Branch to generate the submission from, rather than" argument? [15:30] JPeterson: -f replaces '.' with the argument to f [15:31] JPeterson: so that is setting the other branch in the (submitfrom, submitto) pair [15:31] JPeterson: doesn't seem like you can specify the submit branch (which is the _to_ location) like that [15:32] JPeterson: what you _can_ do, is not mention it and it will use the remembered location [15:32] JPeterson: so you could set that first and then not mention it [15:33] JPeterson: `bzr config submit_branch=../upstream` [15:34] {{{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] JPeterson: yes, see the `bzr branch . ../upstream` I told you about. Also, after setting the submit_branch, leave out the 'upstreambranch' argument. [15:57] {{{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" [15:57] Ubuntu bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed] [16:04] {{{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] my response is: how is that possible? [16:04] or rather, by what decree? [16:04] it doesn't seem to be by my will, so by who's will is there " Already a branch: "../remote".""? [16:07] oh, ok i get it [16:07] (i read it as ./remote) [16:22] can bzr merge update bzr log? [16:23] 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] is the author saved in the patch? [16:25] why intention with asking "[16:51] 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] (and commit message) [16:44] whoever added the "use 'bzr push :parent'" suggestion to the 'bzr push' error message in a fresh checkou^Wbranch: THANK YOU! [16:51] Ooh, nice [16:57] mgedmin: you're welcome! [22:59] i've been using bzrlib in one of my scripts for a little bit now and it's 'mostly' working smoothly. [22:59] it occationally hangs, though, and right now it's hanging on WorkingTree.open() [22:59] is there a way i can tell what its doing or how its failing? [23:00] bjp: hit ctrl-\ [23:00] that will drop you into a debugger [23:00] if you've installed the post mortem hook [23:00] if you haven't, you may want to , its super useful [23:00] failing that, check ~/.bzr.log, or whereever you are logging output to, its probably opening a network branch/repository [23:01] yea it's a lightweight checkout [23:01] i haven't installed any hooks [23:03] i don't see any bzr logs (i'm on windows) [23:06] weird [23:06] it's a batch job, it kept hanging on the 6th branch [23:28] bjp: bzrlib.breakin contains the postmortem hook [23:28] bjp: I believe it works on windows - have a look at pydoc bzrlib.breakin - [23:30] 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] *be trying to contact [23:31] it is, the branches are on a server on the LAN [23:32] so i just called hook_debugger_to_signal() to get the hook? [23:36] yeah [23:36] then if it hangs hit the magic key [23:36] and you should find yourself in pdb [23:36] k, i put it in, now i just gotta wait till it hangs again