| jelmer | JPeterson: still there? | 08:04 |
|---|---|---|
| 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:05 |
| ubot5 | 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:05 |
| JPeterson | jelmer: i wrote "cygwin /usr/bin/bzr" | 08:06 |
| JPeterson | in "tbzrcommand.exe and cygwin /usr/bin/bzr" | 08:06 |
| 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:07 |
| tbf | is there documentation a tutorial on how to use --development-colo ? | 08:08 |
| jelmer | tbf: there is no reason to use --development-colo anymore, all functionality is present in --2a nowadays | 08:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| jelmer | JPeterson: sure, but that's a limitation in cygwin | 08:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| jelmer | JPeterson: are you running this under cygwin as well? | 08:25 |
| 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:26 |
| jelmer | JPeterson: I'm not sure how to fix this with cygwin bzr, to be honest | 08:28 |
| 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:30 |
| jelmer | tbf_: is this over bzr+ssh:// or http:// ? | 08:32 |
| 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:33 |
| JPeterson | jelmer: git also saves the x bit. replicating cygwin git will therefore fix cygwin bzr. | 08:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:51 |
| 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:52 |
| 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:57 |
| jelmer | JPeterson: are those files actually versioned ? | 08:58 |
| jelmer | JPeterson: and are you running the command in the branch root? | 08:58 |
| JPeterson | jelmer. how can they not be? yes. | 08:59 |
| 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:00 |
| 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:03 |
| JPeterson | jelmer: there is no shell magic involved, it's a string | 09:04 |
| 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:05 |
| jelmer | if that fails too then I'm inclined to blame the shell command, not bzr revert | 09:06 |
| 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:09 |
| jelmer | JPeterson: it's including the quote signs in the filename | 09:10 |
| tbf_ | jelmer, 2.5.1. will check later | 09:12 |
| 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 | 09:23 |
| ubot5 | 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] | 09:23 |
| JPeterson | jelmer: whats the bzr equivalent to "git config core.filemode false"? | 10:53 |
| === yofel_ is now known as yofel | ||
| 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:07 |
| JPeterson | it disables file mode versioning | 14:08 |
| LarstiQ | aha | 14:08 |
| JPeterson | i like what youre trying to say "bzr is so good that i use bzr more than git" | 14:09 |
| LeoNerd | It's my first {only?} choice for personal things | 14:10 |
| JPeterson | wheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list? | 14:51 |
| LeoNerd | possibly bzr bundle ? | 14:56 |
| LeoNerd | or bzr send | 14:57 |
| JPeterson | thx | 14:59 |
| JPeterson | "bzr log -1" return bzr: ERROR: no such option: -1 | 14:59 |
| 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:00 |
| 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:01 |
| JPeterson | how do i track the commit for my ohloh account? | 15:02 |
| JPeterson | how does ohloh know i authored the patch? | 15:02 |
| LarstiQ | LeoNerd: that distinction does exist | 15:03 |
| LarstiQ | JPeterson: bzr commit --author to set it | 15:03 |
| 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:04 |
| 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:05 |
| * LarstiQ was referring to the core.filemode question | 15:06 | |
| 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:08 |
| 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:13 |
| JPeterson | thx | 15:14 |
| 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:21 |
| LeoNerd | I imagine its the bzr merge that complains, yes? | 15:24 |
| LarstiQ | it's the bundle I think | 15:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| LarstiQ | JPeterson: `bzr config submit_branch=../upstream` | 15:33 |
| 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:34 |
| LarstiQ | JPeterson: yes, see the `bzr branch . ../upstream` I told you about. Also, after setting the submit_branch, leave out the 'upstreambranch' argument. | 15:39 |
| 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" | 15:57 |
| ubot5 | Ubuntu bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed] | 15:57 |
| 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:04 |
| JPeterson | oh, ok i get it | 16:07 |
| JPeterson | (i read it as ./remote) | 16:07 |
| JPeterson | can bzr merge update bzr log? | 16:22 |
| 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:23 |
| 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:25 |
| JPeterson | (and commit message) | 16:28 |
| mgedmin | whoever added the "use 'bzr push :parent'" suggestion to the 'bzr push' error message in a fresh checkou^Wbranch: THANK YOU! | 16:44 |
| LeoNerd | Ooh, nice | 16:51 |
| jelmer | mgedmin: you're welcome! | 16:57 |
| 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? | 22:59 |
| 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:00 |
| bjp | yea it's a lightweight checkout | 23:01 |
| bjp | i haven't installed any hooks | 23:01 |
| bjp | i don't see any bzr logs (i'm on windows) | 23:03 |
| bjp | weird | 23:06 |
| bjp | it's a batch job, it kept hanging on the 6th branch | 23:06 |
| 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:28 |
| 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:30 |
| bjp | it is, the branches are on a server on the LAN | 23:31 |
| bjp | so i just called hook_debugger_to_signal() to get the hook? | 23:32 |
| 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 | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!