/srv/irclogs.ubuntu.com/2012/10/23/#bzr.txt

jelmerJPeterson: still there?08:04
JPetersonya08:05
jelmerJPeterson: not sure if I follow your question, if you're running tbzrcommand then you're not accessing the win32 filesystem from Linux?08:05
jelmerso bug 248333 shouldn't be relevant08:05
ubot5Launchpad 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/24833308:05
JPetersonjelmer: i wrote "cygwin /usr/bin/bzr"08:06
JPetersonin "tbzrcommand.exe and cygwin /usr/bin/bzr"08:06
jelmerJPeterson: 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 fly08:07
jelmerJPeterson: is there a particular reason you're not using the native bzr executable for windows? that wouldn't have this problem.08:07
tbfis there documentation a tutorial on how to use --development-colo ?08:08
jelmertbf: there is no reason to use --development-colo anymore, all functionality is present in --2a nowadays08:09
tbfjelmer, ok. good to know. basically fighting with the details to get this qt-creator patch accepted: https://codereview.qt-project.org/#change,3768008:10
tbf(without really understanding bzr... but well :-))08:10
JPetersonjelmer: 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
tbfjelmer, do you know where to look for the current colocated branch, when by-passing "bzr nick" for performance reasons?08:11
tbfjelmer, oh. it still is in .bzr/branch/location08:13
jelmertbf: Ah, cool to see that work happening08:13
tbfjust separated by a comma08:13
JPetersonjelmer: this applies to bzr too, using a windows build of bzr.exe is not equivalent to using a cygwin build of it.08:13
jelmerJPeterson: sure, but that's a limitation in cygwin08:14
jelmertbf: in most cases, that's true but it might be in a different location or use a different format in the future08:15
jelmertbf: the colocated branch support is unfinished, so I don't know if it is all that relevant at the moment08:15
tbfjelmer, yup. plus plugins messing around there08:15
tbfjelmer, 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 happy08:16
jelmertbf: 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
jelmertbf: or otherwise, is there a reason you can't call 'bzr nick' ?08:17
tbfjelmer, 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 tool08:17
tbf...but seems they don't like that idea :-/08:18
jelmertbf: looking in .bzr/branch/location is a good way of making sure the plugin breaks in the future though, if formats change08:18
tbfjelmer: 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 code08:18
jelmertbf: or if we add extra stuff to the URL after the comma08:19
tbfthe really sad part: bzr.commands.main() invoked from embedded python interpreter only takes about 8 ms08:19
tbfso all the other overhead are the gazillions of modules, cpython inspects upon start08:20
JPetersonjelmer: 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
tbfheh... 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
jelmerJPeterson: what other workaround would you have us suggest?08:21
tbfbzrlib.commands.main()08:21
jelmertbf: heh, that would work - even nicer if it was a generic shared library that others could use08:21
tbfa simple "int bzr_main(const char *argv[])" that hides all the nasty bits of the python API08:22
JPetersonjelmer: i mean, i'm reluctant to use the workaround.08:22
tbf...that's just crazy enough, that i should try this tonight08:23
jelmerJPeterson: '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
tbfafter all I already have a sample implementation on my disc08:23
tbfprobably should just add an out-of-process mode to make the nay-sayers happy08:24
JPetersonjelmer: 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
jelmerJPeterson: are you running this under cygwin as well?08:25
JPetersonjelmer: yes that refers to cygwin bzr08:26
jelmerJPeterson: because cygwin is probably telling bzr that it has successfully changed the file mode while in practice it hasn't08:26
jelmerJPeterson: I'm not sure how to fix this with cygwin bzr, to be honest08: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
jelmertbf_: is this over bzr+ssh:// or http:// ?08:32
tbf_jelmer, bzr+ssh://bazaar.launchpad.net/+branch/bzr/08:33
jelmertbf_: and with what version of bzr? are you saturating the connection?08:33
JPetersonjelmer: git also saves the x bit. replicating cygwin git will therefore fix cygwin bzr.08:34
jelmerJPeterson: 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 problem08:35
jelmerJPeterson: since cygwin just pretends that all files are executable08:35
jelmerthe 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 it08:36
JPetersonjelmer: you can use #ifdef __CYGWIN__ for that.08:38
JPetersonjelmer: 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
jelmerJPeterson: except that this is not a platform-specific thing, but a filesystem-specific thing08:39
jelmerJPeterson: the same happens if you try to access a FAT filesystem on Linux08:39
JPetersonthe question "How do I fix the repo when this has occurred?" therefore is not answered by using /cygdrive/c/Program Files (x86)/Bazaar/bzr08:39
jelmerJPeterson: a patch to add an exception for cygwin would be very welcome08:40
jelmerJPeterson: that wouldn't be perfect but still a significant improvement over the current situation08:40
JPetersonjelmer: "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
jelmerJPeterson: It would be versioned in one way or another, perhaps there is something wrong with the command?08:52
jelmerwhat are the files it's listing?08:52
JPetersonjelmer: this list http://pastebin.com/eirVksUh08:57
JPetersoncould the list be too big for the argument buffer? so that it's cut off midway08:57
jelmerJPeterson: are those files actually versioned ?08:58
jelmerJPeterson: and are you running the command in the branch root?08:58
JPetersonjelmer. how can they not be? yes.08:59
jelmerJPeterson: and bzr revert errors about all of these files?09:00
jelmerwhat happens if you run bzr revert manually for one of them?09:00
JPetersonjelmer: 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
JPetersonjelmer: that is accepted09:03
jelmerJPeterson: it sounds to me like there's something wrong in your shell magic in that case09:03
JPetersonit used to be 888 files, and a bzr revert for one or two files at a time has reduced it to 88309:03
JPetersonjelmer: there is no shell magic involved, it's a string09:04
jelmerJPeterson: it's something in backticks, that's shell magic :)09:05
jelmerJPeterson: what if you add 'head -2' to bit inside of the backticks?09:05
jelmerif that fails too then I'm inclined to blame the shell command, not bzr revert09:06
JPetersonjelmer 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
jelmerJPeterson: it's including the quote signs in the filename09:10
tbf_jelmer, 2.5.1. will check later09:12
JPetersonjelmer: 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 wrote09:23
ubot5Ubuntu 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
JPetersonjelmer: whats the bzr equivalent to "git config core.filemode false"?10:53
=== yofel_ is now known as yofel
LarstiQJPeterson: what does it do in git?14:07
JPetersonLarstiQ: what does what do?14:07
LarstiQJPeterson: "git config core.filemode false"14:07
JPetersonit disables file mode versioning14:08
LarstiQaha14:08
JPetersoni like what youre trying to say "bzr is so good that i use bzr more than git"14:09
LeoNerdIt's my first {only?} choice for personal things14:10
JPetersonwheres format-patch http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html int his list?14:51
LeoNerdpossibly   bzr bundle   ?14:56
LeoNerdor  bzr send14:57
JPetersonthx14:59
JPeterson"bzr log -1" return bzr: ERROR: no such option: -114:59
LeoNerdIndeed so.15:00
JPetersonwhat is the intended way to print the last log?15:00
LeoNerdPerhaps you meant  -r -1 ?15:00
JPetersonlast commit15:00
JPetersonok15:00
JPetersonthat gives "committer:" but no author15:00
JPetersonhow do i print the author?15:00
LeoNerdI don't believe such a distinction exists15:01
LeoNerd"committer" is just the  bzr whoami  value from the time of  bzr ci15:01
JPetersonoh boy15:01
JPetersonhow do i track the commit for my ohloh account?15:02
JPetersonhow does ohloh know i authored the patch?15:02
LarstiQLeoNerd: that distinction does exist15:03
LarstiQJPeterson: bzr commit --author to set it15:03
JPetersonLarstiQ: thx. how do i read it?15:04
LarstiQJPeterson: for me, it is certainly true that I use bzr almost exclusively over git15:04
JPetersonwhatever15:04
LarstiQJPeterson: it should be included in the log output when set?15:04
JPetersonok15:04
JPetersonthx15:04
LarstiQJPeterson: but the more general point is that people might not be familiar with what you are talking about15:05
JPetersonLarstiQ: an author is someone who write something, kind of15:05
* LarstiQ was referring to the core.filemode question15:06
JPetersonLarstiQ: i know15:08
LarstiQok15:08
JPetersonwell no id didnt know that for certain, but i was certain you knew what author is15:08
LarstiQJPeterson: programmatically, if you have a Revision object, .get_apparent_authors() will give you the names of the authors if set, or the committer otherwise15:13
JPetersonthx15:14
JPetersonthis {{{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
LeoNerdI imagine its the  bzr merge  that complains, yes?15:24
LarstiQit's the bundle I think15:24
LarstiQJPeterson: I'd use `bzr send upstreambranch -o1.patch` instead15:25
LarstiQJPeterson: instead of bzr bundle15:25
JPetersonLarstiQ: what does that do?15:25
JPetersoncan i look at the stuff before i send it?15:26
LarstiQJPeterson: yes15:26
LarstiQJPeterson: it compares your current branch with 'upstreambranch', and writes a merge directive to 1.patch15:26
JPetersonLarstiQ: 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
LarstiQJPeterson: right, you need to have an upstream15:28
LarstiQJPeterson: in your case you could try `bzr branch . ../upstream` before the commit15:28
LarstiQand refer to that15:28
JPetersonLarstiQ: can that be replaced with the "-f ARG, --from=ARG    Branch to generate the submission from, rather than" argument?15:30
LarstiQJPeterson: -f replaces '.' with the argument to f15:30
LarstiQJPeterson: so that is setting the other branch in the (submitfrom, submitto) pair15:31
LarstiQJPeterson: doesn't seem like you can specify the submit branch (which is the _to_ location) like that15:31
LarstiQJPeterson: what you _can_ do, is not mention it and it will use the remembered location15:32
LarstiQJPeterson: so you could set that first and then not mention it15:32
LarstiQJPeterson: `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
LarstiQJPeterson: 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
ubot5Ubuntu 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
JPetersonmy response is: how is that possible?16:04
JPetersonor rather, by what decree?16:04
JPetersonit doesn't seem to be by my will, so by who's will is there " Already a branch: "../remote".""?16:04
JPetersonoh, ok i get it16:07
JPeterson(i read it as ./remote)16:07
JPetersoncan bzr merge update bzr log?16:22
JPetersonthe 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: 216:23
JPetersonis the author saved in the patch?16:25
JPetersonwhy 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 patch16:25
JPeterson(and commit message)16:28
mgedminwhoever added the "use 'bzr push :parent'" suggestion to the 'bzr push' error message in a fresh checkou^Wbranch: THANK YOU!16:44
LeoNerdOoh, nice16:51
jelmermgedmin: you're welcome!16:57
bjpi've been using bzrlib in one of my scripts for a little bit now and it's 'mostly' working smoothly.22:59
bjpit occationally hangs, though, and right now it's hanging on WorkingTree.open()22:59
bjpis there a way i can tell what its doing or how its failing?22:59
lifelessbjp: hit ctrl-\23:00
lifelessthat will drop you into a debugger23:00
lifelessif you've installed the post mortem hook23:00
lifelessif you haven't, you may want to , its super useful23:00
lifelessfailing that, check ~/.bzr.log, or whereever you are logging output to, its probably opening a network branch/repository23:00
bjpyea it's a lightweight checkout23:01
bjpi haven't installed any hooks23:01
bjpi don't see any bzr logs (i'm on windows)23:03
bjpweird23:06
bjpit's a batch job, it kept hanging on the 6th branch23:06
lifelessbjp: bzrlib.breakin contains the postmortem hook23:28
lifelessbjp: I believe it works on windows - have a look at pydoc bzrlib.breakin -23:28
jelmerbjp: note that if the working tree has a remote branch or a bound remote branch, it might try to be contacting that server23:30
jelmer*be trying to contact23:30
bjpit is, the branches are on a server on the LAN23:31
bjpso i just called hook_debugger_to_signal() to get the hook?23:32
lifelessyeah23:36
lifelessthen if it hangs hit the magic key23:36
lifelessand you should find yourself in pdb23:36
bjpk, i put it in, now i just gotta wait till it hangs again23:36

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!