| jdong | can someone tell me what bzr-rebase does exactly, or smack me and tell me to just get the plugin and play with it? | 00:00 |
|---|---|---|
| jdong | it sound intriguing but I guess I don't completely understand what it's doing from the wiki's description | 00:00 |
| lifeless | its a tool for discarding history | 00:00 |
| lifeless | and making it hard to merge with people | 00:00 |
| jdong | ok tell me about why not to use it after telling me what it does :) | 00:01 |
| beuno | or making it linear, not having nested commits | 00:01 |
| lifeless | but can be used to make the 'revision graph' look 'clean', and some projects consider this more important than good merging and collaboration. | 00:01 |
| lifeless | jdong: what it does is transcribe the content of commits to a new revision graph | 00:01 |
| lifeless | beuno: you don't need rebase to do that | 00:01 |
| jdong | lifeless: so it essentially extracts the patch associated with each commit in a child branch and linearly commits it to the parent branch? | 00:01 |
| beuno | lifeless, you don | 00:02 |
| beuno | er, you don't? | 00:02 |
| lifeless | beuno: merge; bzr revert --forget-merges; bzr commit | 00:02 |
| lifeless | jdong: no, bzr is not patch based. | 00:02 |
| beuno | lifeless, ah, right, but that's on a per-commit basis | 00:02 |
| beuno | though it's interesting to know, I've needed that a few times | 00:03 |
| jdong | lifeless: the operation that it rebase does is similar to a merge in end result, but not in history, correct? | 00:03 |
| lifeless | beuno: concurrency is endemic to collaboration; trying to hide it is a lie. | 00:03 |
| jdong | wow I can't type coherently today | 00:03 |
| lifeless | jdong: no, because it _discards history_ | 00:04 |
| jdong | lifeless: in what way? | 00:04 |
| jdong | (ok I think I should just play with bzr-rebase to find out for myself) | 00:04 |
| lifeless | jdong: anyone following the branch that has been rebased can no longer follow it; they have to start over | 00:04 |
| jdong | lifeless: oh.... ouch. | 00:04 |
| lifeless | jdong: the revision graph is what gives you the ability to do merges at all | 00:04 |
| beuno | lifeless, assuming that you always have non-conflicting merges, it shouldn't actually loose any useful history, no? | 00:04 |
| beuno | aaaaaaaah, interesting... | 00:05 |
| lifeless | beuno: it always loses history | 00:05 |
| === jamesh_ is now known as jamesh | ||
| beuno | _not_ what I need then :D | 00:05 |
| lifeless | beuno: if you are a leaf node in the contributor graph, then the impact of this loss is minor or even trivial. | 00:05 |
| beuno | it should be stressed that i's more of a cosmetic thing | 00:05 |
| lifeless | beuno: if you are not a leaf node in the contributor graph, then every node following you has pointers to revisions that your branch no longer refers to | 00:06 |
| lifeless | beuno: imagine if linus rebased the linux mainline to insert a new commit a few days ago, which he'd done on a 'private mainline' or something | 00:06 |
| jdong | eep, what does a KeyError on a pack during commit mean? | 00:07 |
| jdong | bzr: ERROR: exceptions.KeyError: 'sftp://linerva/%7E/docs/.bzr/repository/upload/zq5x7hmwfonjtr1jgpd9.pack' | 00:07 |
| lifeless | beuno: so - if you want to encourage a strict hub and spoke merge graph, rebase may fit the leaf nodes only | 00:07 |
| lifeless | beuno: but if there are no leaf nodes, noone can use rebase without impact | 00:07 |
| beuno | lifeless, I see. I understand why you're so pesimistic about it now :D | 00:08 |
| lifeless | jdong: no idea; what bzr version? try it again ? | 00:08 |
| jdong | 1.0 locally, 1.1.0rc was used a bit remotely, seems to happen consistently with this commit (9 pngs) | 00:09 |
| lifeless | file a bug | 00:09 |
| lifeless | get the backtrace from ~/.bzr.log | 00:09 |
| jdong | will do | 00:10 |
| ubotu | New bug: #191402 in bzr "bzr resolve fails on files with certain strings" [Undecided,New] https://launchpad.net/bugs/191402 | 00:10 |
| ubotu | New bug: #191409 in bzr "commit on bound branch yields KeyError" [Undecided,New] https://launchpad.net/bugs/191409 | 00:21 |
| jdong | lifeless: ^^ filed. Let me know if any more information would be helpful | 00:24 |
| jdong | lifeless: odd, looked like bzr+ssh:// worked fine (remote smartserver is 1.1.0~rc) | 00:28 |
| mtaylor | anyway to find out in which revision a file was removed? | 00:42 |
| mtaylor | or to get a log of a file not currently in a working tree? | 00:43 |
| jdong | mtaylor: probably not best way, but bzr log -v shows all the add/modify/deletes associated with each commit.... | 00:44 |
| jdong | mtaylor: so you can pipe that to less and search through it for a filename | 00:44 |
| jdong | the first catch should be the deleted revision | 00:44 |
| rolly | there are two grep plugins, aren't there? Maybe one of those can help | 00:45 |
| mtaylor | cool. that worked | 00:46 |
| mtaylor | so now if I want to revert the deleted file to that rev... ? | 00:47 |
| mtaylor | I actually want to restore that file and another, and then revert two other files to the state they were in that rev | 00:47 |
| beuno | mtaylor, you can: bzr cat dir/file -r revno | 00:47 |
| mtaylor | hm | 00:47 |
| beuno | cat it to a file | 00:47 |
| mtaylor | yeah | 00:47 |
| beuno | and there you have it | 00:47 |
| beuno | bzr cat dir/file -r revno > new_file | 00:48 |
| mtaylor | well hot-damn, look at that | 00:48 |
| lifeless | mtaylor: please file a bug | 00:48 |
| mtaylor | lifeless: against what? | 00:48 |
| jdong | mtaylor: probably against log deleted_file_name not working | 00:48 |
| lifeless | mtaylor: using revert to reinstate a deleted file to an old version | 00:49 |
| mtaylor | ah. ok | 00:49 |
| lifeless | mtaylor: because you want to restore the file id too | 00:49 |
| jdong | lifeless: shouldn't there be a way to log old_file_name too? | 00:49 |
| lifeless | mtaylor: I think there is one for deleted-way-back file names not working. we need a syntax for saying 'this file in that revision' | 00:49 |
| jdong | that doesn't involve a long grep | 00:49 |
| lifeless | mtaylor: also, for your case, to restore the file name I suggest you do: | 00:50 |
| lifeless | bzr merge -r 0..before:DELETEDIN ./path/to/filename | 00:50 |
| lifeless | mtaylor: rather than playing games with cat | 00:50 |
| mtaylor | lifeless: can I give that a list of filenames? | 00:52 |
| lifeless | mtaylor: no, not yet. there is a bug about that ;) | 00:52 |
| lifeless | mtaylor: OTOH you can give it a directory :) | 00:52 |
| lifeless | if a directory was deleted | 00:52 |
| mtaylor | well, I actually do want to cherry pick file from the dir... | 00:53 |
| mtaylor | but that's why bash has for! | 00:53 |
| jdong | for file in..... | 00:53 |
| lifeless | beuno: jdong: for reference, 'revert' is an alias for a special form of merge. So problems with revert can usually be addressed by using merge in a clever way. | 00:54 |
| lifeless | this matters because you get better results with log afterwards. | 00:54 |
| lifeless | and with merge | 00:54 |
| jdong | lifeless: thanks. I should put this channel in my autojoin. I've learned more here the past 20 minutes than my entire day :) | 00:54 |
| beuno | lifeless, but won't you have to manage conflicts for a file you actually want to overwrite with a previous version? | 00:56 |
| lifeless | beuno: rarely | 00:56 |
| lifeless | beuno: anyhow, note that this is the exception, normally just revert will DTRT | 00:57 |
| beuno | lifeless, interesting. Thanks for the tip | 00:57 |
| jdong | lifeless: interesting, it seems like the problem is pushing over sftp onto an OpenAFS filesystem causes all kinds of blowups that I didn't notice before | 01:04 |
| jdong | bzr: ERROR: Generic path error: 'x5mcow4qnooegj14jua7.fetch': Failure: unable to rename to '../packs/e99efc4177e3d29106b0219514f8c3c4.pack') | 01:04 |
| jdong | that's a new one | 01:04 |
| jdong | lifeless: is there any way to get paramiko or whatever the SFTP backend is to give more debugging info? | 01:05 |
| poolie | jdong, there may not be a debug option, but there is a debug setting in paramiko | 01:16 |
| poolie | i'm just not sure how it's exposed | 01:16 |
| poolie | it may be an environment variable | 01:16 |
| poolie | separately, the failure i have at the moment is bzrlib.tests.blackbox.test_bundle_info.TestBundleInfo.test_bundle_info | 01:17 |
| poolie | i'm planning to fix bug 189771 by keeping a record of plugins that failed to load, | 02:11 |
| ubotu | Launchpad bug 189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771 | 02:11 |
| poolie | and having the test suite fail if that list is nonempty | 02:11 |
| spiv | poolie: that sounds good to me | 02:15 |
| poolie | i think the other dirstate thing is now merged | 02:15 |
| poolie | god and pqm willing | 02:15 |
| lifeless | poolie: I don't know that the launchpad plugin fails to load | 02:26 |
| lifeless | poolie: it may be that the tests for it fail to load, but that that is a soft error. | 02:27 |
| poolie | true | 02:27 |
| lifeless | poolie: if its the plugin failing to load, perhaps a test that all present plugins load ? | 02:27 |
| lifeless | (said test disabled by --no-plugins of course) | 02:28 |
| poolie | ok actually it does load | 02:28 |
| lifeless | if its the tests for it failing to load; then I think failing to load a test containing module should be a hard error not a soft error | 02:29 |
| lifeless | I've always thought this :) | 02:29 |
| lifeless | as in - don't run any tests, just stop cold | 02:29 |
| poolie | right | 02:33 |
| poolie | and it'd be a simple way to fix it | 02:33 |
| poolie | if you don't like it, you can always use --no-plugins | 02:33 |
| lifeless | poolie: can you land the 1.3 NEWS sections etc asap | 03:16 |
| lifeless | poolie: its a blocker for doing merges to mainline, unless you're going to fixup NEWS for us :) | 03:16 |
| lifeless | hmm, well not 1.3, but at least the markers for what is 1.2 | 03:17 |
| poolie | lifeless, sure | 03:17 |
| lifeless | (this is why its in the release process docs) | 03:17 |
| poolie | i have not got up to that part of the process yet | 03:18 |
| lifeless | ah | 03:19 |
| lifeless | so technically I can land something in mainline still. _cool_ | 03:19 |
| lifeless | :> | 03:19 |
| poolie | lifeless, i'm submitting that patch now | 03:26 |
| poolie | the static declarations in symbol_versioning are a bit ugly | 03:26 |
| poolie | remember to check you merges to NEWS go into the right place | 03:26 |
| lifeless | which patch? | 03:26 |
| poolie | to call it 1.3dev | 03:26 |
| lifeless | oh the release stuff | 03:26 |
| lifeless | yes | 03:26 |
| lifeless | I'll hold off this merge then | 03:27 |
| lifeless | I suspect your release process is somewhat difference in internal nature than mine | 03:27 |
| lifeless | thumper: so why did you add test_lp_registration when there is test_register already ? | 03:30 |
| thumper | lifeless: test_register was testing the register branch command | 03:31 |
| lifeless | and the rpc | 03:31 |
| thumper | lifeless: whereas test_lp_registration was testing the launchpad xmlprc bits | 03:31 |
| poolie | lifeless, also your change to use edge seems to break the tests, now that they're running, but probably in a straightforward way | 03:31 |
| lifeless | poolie: well, when my change landed all the tests passed :) | 03:32 |
| lifeless | thumper: for instance, test_register has test_mock_server_registration, testing the service directly | 03:32 |
| thumper | lifeless: I was pairing with abentley to do this | 03:33 |
| thumper | lifeless: and he suggested it and it seemed reasonable at the time | 03:33 |
| lifeless | thats fine, I am worried that we either have duplication, or confusion. | 03:33 |
| lifeless | if there is no duplication then its at best confusing to me | 03:33 |
| poolie | i think i will merge the files and dedupe | 03:33 |
| lifeless | because test_register is just blackbox tests | 03:33 |
| lifeless | thanks poolie | 03:34 |
| thumper | the tests in test_lp_registration are very simple and explicit, I don't think there is any duplication | 03:34 |
| lifeless | is *not* | 03:34 |
| thumper | I don't have a strong opinion one way or the other | 03:34 |
| thumper | the tests could be moved if that would help unconfuse you | 03:34 |
| lifeless | poolie has already said he will | 03:35 |
| abentley | poolie: But using --no-plugins means I can't use gselftest to run my tests... | 03:35 |
| poolie | ! i didn't know of gselftest | 03:35 |
| lifeless | abentley: | 03:35 |
| lifeless | abentley: tests that fail to load are still broken; I _really_ want hard errors on all such things | 03:36 |
| lifeless | abentley: I don't really care if its expressed as a failing test ('all test scripts loaded'), or as an earlier error ('failed to create test suite') | 03:36 |
| abentley | lifeless: I think I agree. | 03:36 |
| abentley | There are some plugins I don't run because their test suites don't pass. | 03:37 |
| poolie | abentley, so you mean you want it shown as a failure, but other tests should run? | 03:37 |
| abentley | poolie: I think that would be fine. | 03:38 |
| lifeless | I think its unneeded complexity though | 03:39 |
| poolie | note that this is only when the plugin's tests can't even be imported | 03:39 |
| lifeless | as failing to run any tests is much easier to signal | 03:39 |
| poolie | hopefully that's rare | 03:39 |
| abentley | I think mainly I was saying that --no-plugins is not a panacea. | 03:40 |
| abentley | But the plugin should be fixed, and I have a low tolerence for broken plugins. | 03:41 |
| abentley | I have a very big ~/.bazaar/plugins/inactive directory | 03:41 |
| poolie | lifeless, re indenting of news, you want the asterisks in column 5? | 03:48 |
| lifeless | poolie: yes | 03:50 |
| * igc bbl | 04:00 | |
| poolie | lifeless, spiv: patch for 189771 sent, would appreciate if someone could look at it | 04:05 |
| poolie | i'm going out for a bit | 04:05 |
| ubotu | New bug: #191449 in bzr-gtk "tests should skip if there's no $DISPLAY" [Undecided,New] https://launchpad.net/bugs/191449 | 04:05 |
| === Verterok is now known as Verterok_ | ||
| lifeless | bleh what a day of little-tasks | 04:43 |
| lifeless | time for some coding | 04:46 |
| i386 | lifeless: im getting another me here at work | 04:53 |
| i386 | so they can do those sorts of things :) | 04:53 |
| lifeless | didn't they break the mold? | 04:53 |
| === asac_ is now known as asac | ||
| i386 | haha | 04:55 |
| i386 | urgh | 04:55 |
| i386 | large PNG is large | 04:55 |
| mwhudson | hee: AttributeError: '_PreviewTree' object has no attribute 'get_symlink_target' | 05:09 |
| mwhudson | i guess we didn't think that code was complete | 05:10 |
| abentley | mwhudson: nopes. | 05:19 |
| ubotu | New bug: #191466 in bzr "bzr update on missing file does nothing. svn update brings back file." [Undecided,New] https://launchpad.net/bugs/191466 | 05:50 |
| poolie | lifeless, what do you mean "5 spaces rather than 2"? | 06:35 |
| lifeless | rather than 4 | 07:35 |
| lifeless | from | 07:36 |
| lifeless | here | 07:36 |
| lifeless | from | 07:36 |
| lifeless | here | 07:36 |
| lifeless | thats what the diff shows | 07:36 |
| poolie | thought so | 07:36 |
| poolie | did you have an objection to vila's patch other than the trace thing? | 07:36 |
| lifeless | vila? or alexander? | 07:37 |
| poolie | vila | 07:43 |
| poolie | regarding setup.py | 07:43 |
| * igc dinner | 07:44 | |
| === aadis_ is now known as aadis | ||
| lifeless | poolie: oh right the test cleanup one? | 08:45 |
| lifeless | poolie: note vs info ? | 08:45 |
| poolie | yes | 08:50 |
| lifeless | poolie: I hadn't seen his follow up | 08:52 |
| lifeless | iz fine | 08:52 |
| poolie | i have a tarball | 08:53 |
| poolie | night all | 09:15 |
| === zmanuel is now known as z-man | ||
| rolly | yay, rc1 | 09:32 |
| johnny | if i do a cvsps-import, what exactly do i have ? layoutwise? | 10:51 |
| cropalat | hi, i need some help with bzr. Any body??? | 11:09 |
| garyvdm | There are lots of people here. Go ahead an ask. | 11:10 |
| cropalat | since yesterday, i try to use "bzr branch http://bazaar.launchpad.net/~canonical-training/ubuntu-desktop-course/ubuntu-desktop-course-beta", and the transmission stop as you can see with this part of tcpdump output. | 11:10 |
| cropalat | 08:04:52.496764 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: P 2615850:2616810(960) ack 6326 win 8416 <nop,nop,timestamp 1084713278 39394400> | 11:11 |
| cropalat | 08:04:52.496852 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394531 1084713216,nop,nop,sack 2 {2598570:2616810}{2561450:2592810}> | 11:11 |
| cropalat | 08:04:52.510477 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2616810:2618250(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713278 39394400> | 11:11 |
| cropalat | 08:04:52.510582 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394535 1084713216,nop,nop,sack 2 {2598570:2618250}{2561450:2592810}> | 11:11 |
| cropalat | 08:04:52.524143 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2618250:2619690(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713279 39394403> | 11:11 |
| cropalat | 08:04:52.524272 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394538 1084713216,nop,nop,sack 2 {2598570:2619690}{2561450:2592810}> | 11:11 |
| cropalat | 08:04:52.537799 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2619690:2621130(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713279 39394403> | 11:11 |
| cropalat | 08:04:52.537903 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394541 1084713216,nop,nop,sack 2 {2598570:2621130}{2561450:2592810}> | 11:11 |
| cropalat | 08:04:52.551418 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2621130:2622570(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713280 39394406> | 11:11 |
| cropalat | 08:04:52.551511 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop,timestamp 39394545 1084713216,nop,nop,sack 2 {2598570:2622570}{2561450:2592810}> | 11:11 |
| cropalat | 08:04:52.565075 IP 91.189.94.254.www > 20150197157.user.veloxzone.com.br.35472: . 2622570:2624010(1440) ack 6326 win 8416 <nop,nop,timestamp 1084713281 39394410> | 11:11 |
| cropalat | 08:04:52.565177 IP 20150197157.user.veloxzone.com.br.35472 > 91.189.94.254.www: . ack 2558570 win 3530 <nop,nop, | 11:11 |
| garyvdm | Please use http://pastebin.org/ | 11:11 |
| beuno | please :D | 11:11 |
| cropalat | my screnn show this "| [= ] Transferring 0/4" | 11:12 |
| cropalat | sorry | 11:12 |
| beuno | cropalat, does bzr output an error? | 11:12 |
| cropalat | beuno, no | 11:12 |
| cropalat | but it get out with timeout | 11:12 |
| beuno | cropalat, doesn't seem bzr-related than | 11:12 |
| beuno | what version of bzr are you using? | 11:13 |
| cropalat | Bazaar (bzr) 1.0.0 | 11:13 |
| beuno | cropalat, seems good enough. It's probably related to some problem with your ISP | 11:14 |
| beuno | you can try updating to the latest bzr if you want to try _something_ on your end | 11:14 |
| beuno | 1.1 es the latest release | 11:14 |
| cropalat | i will get the traffic to see. Thanks | 11:14 |
| cropalat | my distro are working with 1.0 | 11:15 |
| beuno | cropalat, what distro would that be? | 11:15 |
| cropalat | Ubuntu 7.10 | 11:15 |
| beuno | cropalat, you can get the lastest from: https://launchpad.net/~bzr/+archive | 11:16 |
| beuno | either add the ppa to your sources.list, or just plain download and install the deb | 11:16 |
| cropalat | beuno, what is new in this version? | 11:16 |
| beuno | cropalat, nothing significant enough that would fix your timeout, but it won't hurt :D | 11:17 |
| cropalat | beuno, thanks | 11:19 |
| beuno | cropalat, np | 11:20 |
| cropalat | beuno, where the bzr put the temp files? | 11:23 |
| garyvdm | cropalat: yourbranch/.bzr/ | 11:24 |
| cropalat | garyvdm, any specia name? | 11:26 |
| garyvdm | cropalat - sorry - I don't understand | 11:27 |
| garyvdm | What are you looking for> | 11:27 |
| garyvdm | *? | 11:27 |
| cropalat | garyvdm, how can i identify where the bzr are storing the download data at this time? | 11:29 |
| garyvdm | yourbranch/.bzr | 11:29 |
| garyvdm | where yourbranch is the dir you are creating the branch in | 11:29 |
| cropalat | ok | 11:32 |
| garyvdm | If you bzr branch mybranch and it stop half way you can cd mybranch then bzr pull and it will carry on from where it stopped | 11:33 |
| mikeX | hello, this is somewhat OT, but is it possible for your patiencediff to output only the *characters* that differ, not the whole line? | 12:05 |
| luks | you can split the input on characters, not lines | 12:06 |
| luks | but then it will be very slow, obviously | 12:06 |
| mikeX | how would that work? | 12:06 |
| luks | list("foobar") -> ['f', 'o', ...] | 12:06 |
| mikeX | well actually i don't wont characters, just the subsets that differ | 12:06 |
| mikeX | hello world vs hell0_world, in such a case 0_ | 12:07 |
| lifeless | mikeX: yes the algorithm can do this | 12:08 |
| lifeless | mikeX: and our internal code too | 12:08 |
| mikeX | can you point me to the files that require modification for changing the output then? | 12:08 |
| lifeless | mikeX: but its much more expensive (if each line was 80 characters, and it was a linear cost, 80 times slower, but its > linear, upto quadratic worst case) | 12:08 |
| lifeless | mikeX: what you could do is something slightly different, and on the differing lines run the more expensive algorithm | 12:09 |
| lifeless | bzrlib.diff has the bulk of the diff high level logic | 12:09 |
| mikeX | thanks a lot | 12:10 |
| lifeless | gnight | 12:10 |
| lifeless | oh also | 12:10 |
| lifeless | check out bzrlib.tests - there is a thing in there -assertEqualDiff that does a character level diff output | 12:11 |
| luks | mikeX: PatienceSequenceMatcher(None, "hello world", "hell0_world").get_opcodes() | 12:12 |
| mikeX | that's greak, thanks luk | 12:18 |
| mikeX | s | 12:18 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| jdong | is there a bzr plugin yet that can act like a "branch aggregrator" | 13:46 |
| jdong | i.e. check X different branch locations for new commits | 13:46 |
| awilkins | jdong: Even if there was, would there be any difference between that and a shell script? | 13:51 |
| jdong | awilkins: well other than from a UI perspective, no. | 13:51 |
| jdong | that would be a final fallback if there weren't a plugin AND I wasn't willing to write one :) | 13:52 |
| awilkins | Sort of like a branch manager GUI? | 13:52 |
| awilkins | Keeps track of all your branches and such? | 13:52 |
| jdong | kind of like let's say "foobar" has a large developer community, with 20+ branches | 13:53 |
| jdong | right now, if I want to check for new commits from one of the developers, I'd have to keep track of 20 branch URLs by hand | 13:54 |
| jdong | or edit aliases by hand in a text editor... both of which are kind of annoying | 13:54 |
| jdong | I'd love to be able to do like "cd foobar; bzr check-related-branches" | 13:54 |
| jdong | and get a quick summary of type "Branch $foo has $n new revisions" | 13:55 |
| === aadis_ is now known as aadis | ||
| === asak_ is now known as asak | ||
| ignas | hi | 14:40 |
| ignas | if i have 5 branches and want to put them into a shared repository that i have just created using "bzr init-repo" what would be the command to use? | 14:40 |
| LeoNerd | Just push them there | 14:41 |
| luks | bzr branch | 14:41 |
| ignas | i want to pull 1 branch as a trunk, and put other 4 in branches/ | 14:41 |
| luks | oh, or push | 14:41 |
| ignas | LeoNerd: thanks | 14:41 |
| mikeX | hmm, PatienceSequenceMatcher seems to yield very bad results for unicode strings | 14:41 |
| ignas | hmm I get bzr: ERROR: No WorkingTree exists for "file:///home/ignas/src/schooltool.devtools/.bzr/checkout/" if I try bzr mkdir branches in the central repository | 14:45 |
| fullermd | You just want to use mkdir for branches/... | 14:46 |
| ignas | oh | 14:46 |
| === asak_ is now known as asak | ||
| ubotu | New bug: #191569 in bzr "Cannot set "whoami" at a repository level" [Undecided,New] https://launchpad.net/bugs/191569 | 14:55 |
| ubotu | New bug: #191572 in bzr "KeyError when pulling from svn repo." [Undecided,New] https://launchpad.net/bugs/191572 | 15:00 |
| ubotu | New bug: #191576 in bzr "TypeError when using `bzr branch` on an svn repository" [Undecided,New] https://launchpad.net/bugs/191576 | 15:10 |
| dato | abentley: hi. do you think `shelf show` could use colors like `shelve` itself does, and maybe gain a --no-color switch? | 15:23 |
| abentley | dato: I don't remember what shelf show does. | 15:24 |
| dato | display the contents of a patch from the shelf | 15:24 |
| dato | basically `cat $topofshelf` | 15:25 |
| abentley | Yeah, I think that's reasonable. | 15:25 |
| dato | would you like a bug? I'm afraid time doesn't allow me to offer anything else =) | 15:26 |
| abentley | dato: Launchpad actually provides for feature requests as "blueprints". | 15:27 |
| * dato guesses he has the "wishlist bug" concept very hard wired in his brain | 15:28 | |
| * abentley doesn't like it when people say his software has bugs just because it doesn't have a feature they want :-) | 15:29 | |
| === maw is now known as mw | ||
| abentley | I actually prefer the Trac approach of "Issues" being "Bugs", "Enhancements" and "Tasks". | 15:30 |
| schierbeck | fuck | 15:32 |
| schierbeck | had a network outage, now the bzr-gtk trunk is locked, and break-lock ain't working | 15:32 |
| abadger1999 | Any packagers of bzr & company for Ubuntu/Debian/etc around? | 15:32 |
| dato | abadger1999: yes | 15:32 |
| abadger1999 | Do you guys do anything out of the ordinary to manage the large number of bzr plugins? | 15:33 |
| abentley | schierbeck: Pastebin us a traceback, and I can take a look. | 15:34 |
| dato | abadger1999: yes: most of them are not packaged | 15:34 |
| dato | personally I wanted to create a big package with a selection of the most useful ones | 15:34 |
| dato | but several core people disliked the idea | 15:34 |
| abadger1999 | dato: Yeah, that would make my day as well :-) | 15:34 |
| dato | and I'm afraid I'm not going to spend my time in creating 10 or 12 different packages for such tiny stuff | 15:35 |
| abentley | dato: Isn't that what I do? ;-) | 15:35 |
| schierbeck | abentley: well, the only thing i get which resembles an error is "Disconnecting: Received extended_data after EOF on channel 0." | 15:35 |
| schierbeck | right after using break-lock on the remote branch | 15:35 |
| dato | abentley: hehe | 15:35 |
| abadger1999 | abentley: That's why bzrtools is packaged for Fedora but bzr-{dbus,avahi,bisect} is not :-) | 15:36 |
| abentley | schierbeck: That resembles a bug we had with old versions of Paramiko. | 15:37 |
| abentley | But it was a harmless message | 15:37 |
| schierbeck | maybe, but the locks are not released | 15:37 |
| schierbeck | actually, it just resets the lock time | 15:37 |
| abentley | schierbeck: Okay, so you probably have a couple of "bzr serve" processes running on the server. | 15:38 |
| === asak_ is now known as asak | ||
| abadger1999 | If there was an effort to get things into a single upstream product (like bzrtools) and make releases as part of that product then there'd be more uptake of the individual utilities. | 15:38 |
| abentley | You should be able to run break-lock several times. | 15:38 |
| schierbeck | abentley: yeah, it seems like it | 15:39 |
| schierbeck | i'll try | 15:39 |
| * abadger1999 resigns himself to asking for more bzr related packagers on the fedora lists | 15:39 | |
| abentley | Each time you break-lock, a bzr process should stop. | 15:39 |
| schierbeck | abentley: that worked! thanks! | 15:39 |
| abentley | schierbeck: No problem. | 15:40 |
| dato | abadger1999: and what do the packagers say? they'll do more packages? | 15:42 |
| schierbeck | i've drunk an unhealthy amount of coffee today... | 15:42 |
| abadger1999 | dato: I'm guessing I'll get a bunch of people telling me to use git :-/ | 15:42 |
| dato | abadger1999: heh | 15:42 |
| abadger1999 | dato: I don't think the overlap between packagers and bzr users is very high in Fedora ATM. | 15:43 |
| dato | abadger1999: there are a lot of git fanboys in debian as well | 15:43 |
| abentley | abadger1999: Could you post something to the list? If the authors are amenable, I'd be happy to incorporate more stuff into bzrtools. | 15:43 |
| dato | damn, abentley was faster about the list bit | 15:43 |
| abadger1999 | abentley: I sure can. | 15:43 |
| dato | :) | 15:43 |
| abentley | And that's not exclusive with shipping the plugins separately. | 15:44 |
| abadger1999 | Anything to help me scale more effectively :-) | 15:44 |
| ignas | how do I do a push without being in the branch, like bzr push /path/to/some-repo sftp://place-for-push ? | 15:45 |
| abadger1999 | abentley: Oh? Meaning you'd help manage releases as separate tarballs from the bzrtools tree? | 15:45 |
| abentley | abadger1999: Meaning that bzr-dbus can be provided as a standalone plugin and as part of bzrtools. | 15:46 |
| abadger1999 | abentley: okay. that would be awesome for packagers. | 15:46 |
| * dato bbl | 15:47 | |
| abentley | I suppose the converse also applies, if people think bzrtools is getting too big. | 15:47 |
| * awilkins sulks because there is no dbus on Windows | 16:02 | |
| LeoNerd | There were rumours of a port | 16:02 |
| awilkins | Cursory searching reveals one | 16:03 |
| awilkins | I mean, it wouldn't be hard, windows is thick with IPC methods it could wrap | 16:03 |
| awilkins | Only wanted to see if commit-notifier worked | 16:03 |
| awilkins | It puts an icon in the toolbar then dies :-) | 16:04 |
| * Debolaz has a dbus-daemon.exe running on his Windows XP box. | 16:09 | |
| Debolaz | At least according to task manager. :) | 16:09 |
| orospakr | Hey, can I get bzr diff to do colour diffs with paging like git can do? | 16:35 |
| awilkins | Right, I've switched from svk to bzr for my working-at-home needs from the SVN repo | 16:35 |
| orospakr | awilkins, do you have issues where bzr eats all available ram (due to a bug in libsvn) when doing a big svn checkout? | 16:36 |
| awilkins | orospakr: Yes, I have that problem, esp on my big repo | 16:36 |
| orospakr | awilkins, it's been ongoing for years. | 16:37 |
| awilkins | orospakr: Alas, it's now failing on something else, having successully converted about 7900 / 9000 revisions | 16:37 |
| orospakr | recently I finally saw some activity on the svn bug tracker about this issue. | 16:37 |
| orospakr | harsh. | 16:37 |
| awilkins | You can at least resume it after it MemoryErrors you | 16:38 |
| awilkins | But now it's the same KeyError on a pack each time | 16:38 |
| awilkins | It's in the upload folder which makes no sense to me because it's PULLING not pushing | 16:38 |
| awilkins | Go figure. | 16:38 |
| awilkins | There's a bug in for it | 16:38 |
| awilkins | #191572 | 16:39 |
| === Mez__ is now known as Mez | ||
| awilkins | I think increasingly SVN is going to end up as the nice, safe, steady backend for roving teams of developers using wild and crazy new VCS tools | 16:42 |
| awilkins | Despite all the effort they put in for v 1.5 | 16:43 |
| awilkins | And when TortoiseBzr or TortoiseGit are done, SVN will really start to die. | 16:44 |
| awilkins | Tortoise<DVCS> ought to be possible - just use the common idiom and a plugin backend | 16:45 |
| awilkins | Should cover bzr, mtn, hg, git ; there aren't too many radical differences there. | 16:46 |
| === LarstiQ_ is now known as LarstiQ | ||
| awilkins | cd .. | 16:51 |
| awilkins | oops | 16:51 |
| === bigdo1 is now known as bigdog | ||
| === awilkins is now known as awilkins_away | ||
| abentley | orospakr: "bzrtools" provides cdiff. You can also use diff --using colordiff. The pager side is generally done using |less -R. | 17:10 |
| zurgutt | folks, help me understand something: apparently i can commit just one subdir of branch by "bzr commit dir" but how to update just some file/subdir? "bzr update dir" updates whole branch. | 18:56 |
| kiko | for general reading and comments: http://news.launchpad.net/general/the-great-source-code-supermarket | 18:57 |
| kiko | zurgutt, I'm not sure that's actually possible | 18:57 |
| zurgutt | bzr help update says "bzr update [DIR]" | 18:57 |
| fullermd | That should probably say "bzr update [BRANCH]" instead... | 18:58 |
| zurgutt | what would [BRANCH] mean in this case ? | 18:59 |
| fullermd | "bzr update foo" instead of "cd foo ; bzr update" | 18:59 |
| dato | kiko: 'three or more of the words: "foo"' <-- the foo stuff is screaming for commas, otherwise you try to read it as a sentence and choke | 18:59 |
| kiko | that's kind of the point ;) | 19:00 |
| zurgutt | ah.. but no way to update one file? | 19:00 |
| fullermd | No, that's not a sensible operation. Files aren't versioned, whole branches are. | 19:01 |
| dato | kiko: well, suit yourself. IMHO it sucks, but it's not my problem. :-) | 19:01 |
| zurgutt | in respect to this, how does committing just one file make sense? | 19:01 |
| fullermd | You can create constructs like "a branch at rev6, with this file at rev3", but what you'll end up with is a branch at rev6 with one altered file; that it happens to have the same content as the file did at rev3 is periphal and of no interest to bzr. | 19:02 |
| fullermd | In that you're implicitly creating a branch state that only partly corresponds to what's on disk. | 19:02 |
| zurgutt | should be ok to update (well, get) one file to working tree from central repo without updating local status.. someone used to svn is asking for it, i myself am not familiar with svn | 19:06 |
| fullermd | Well, "central" is kinda question-begging. | 19:08 |
| fullermd | You can use 'revert' to throw a file's contents to some arbitrary rev. | 19:08 |
| ubotu | New bug: #191651 in bzr "bazaar.conf::editor line quoting is not preserved correctly" [Undecided,New] https://launchpad.net/bugs/191651 | 19:20 |
| === kiko is now known as kiko-afk | ||
| n[ate]vw | what's the best way to send another coder a repo over, say, email? just tarring the project folder up can leave "dangling pointers" to other branches on my machine | 19:33 |
| fullermd | Does that matter? | 19:33 |
| n[ate]vw | it doesn't hurt, I suppose. It's not like "merge" would have a better reference given that mode of transportation | 19:34 |
| n[ate]vw | so that's not a bad way to do do a lo-fi share without involving an HTTP server or opening ports for ssh? | 19:35 |
| fullermd | I s'pose you could just push it to /tmp somewhere and tar that up. Then it wouldn't have those cosmetic issues. | 19:36 |
| dato | right | 19:36 |
| dato | push /tmp/foo | 19:36 |
| dato | remove-tree /tmp/foo if you'd like | 19:36 |
| fullermd | That would also take care of issues you might have with it being in a repo, too. | 19:36 |
| n[ate]vw | ok, that makes sense. the push would let bzr know it's a distinct branch, which is basically what I was wanting. and the remove-tree would help the other guy get familiar with basic usage :-) | 19:39 |
| luks | hm, would be nice to have an option to do this from bzr export | 19:40 |
| n[ate]vw | yeah, I'd looked into export, but it didn't seem to be quite what I was looking for (a complete branch, but able to go wherever a .tgz can) | 19:42 |
| abentley | n[ate]vw: bzr send is a good choice for sending a branch to someone. | 19:42 |
| n[ate]vw | abentley: that's not just for patches? | 19:43 |
| luks | that would involve creating an empty target branch, no? | 19:43 |
| abentley | n[ate]vw: It preserves all data except tags. | 19:43 |
| fullermd | I thought bundles were a wildly inefficient means of bulk rev moving... | 19:43 |
| abentley | luks: yes, it would | 19:43 |
| abentley | fullermd: They are actually more efficient, because they use MPdiff and don't have any fulltexts. | 19:44 |
| abentley | And they use bzip. | 19:44 |
| fullermd | Interesting. | 19:45 |
| abentley | The previous bundle format was much more inefficient, in terms of both storage and speed. | 19:46 |
| dato | n[ate]vw: there is --no-patch, in case you want that if you use send | 19:47 |
| dato | (that'd be the equivalent of the remove-tree above :) | 19:47 |
| fullermd | D'oh, you moved bzrtools to launchpad... | 19:49 |
| abentley | Something wrong with that? | 19:49 |
| fullermd | Not as such, really. Just the URL's for the download files are unfriendly. | 19:50 |
| fullermd | Are you planning to keep using the 'stable' release series? | 19:50 |
| fullermd | (i.e., for 1.3.0 and 1.4.0 and such) | 19:50 |
| abentley | Yes, that's the plan. | 19:50 |
| n[ate]vw | dato: so I would "bzr send --no-repo -o ../sendable_repo", and then the other developer would need to create an empty branch and "bzr merge sendable_repo"? | 19:51 |
| fullermd | 'k. I think I can get away with using the 1.x.y version for that bit of the path too, and not have to update the base URL for every upgrade then... | 19:51 |
| * fullermd is trying to get a head start on port updates for the next release while he waits for a phone call. | 19:51 | |
| abentley | I can't really keep hosting stuff on panoramicfeedback.com now that I don't work there. | 19:52 |
| fullermd | Some places are funny like that. | 19:52 |
| dato | n[ate]vw: sorry, gotta run, but : `bzr send --no-patch -o ../sendable ../empty-branch` <-- *you* create the empty branch | 19:52 |
| dato | leaving now, but I leave you in good company ;) | 19:52 |
| n[ate]vw | thanks, I'll keep experimenting! | 19:53 |
| fullermd | Hm. I guess I should add LP as a backup source for bzr too, as long as I'm here... means I need to get creative on that anyway. Blah. | 19:56 |
| fullermd | Heck with it, I'll just change it by hand for every release series. | 19:58 |
| n[ate]vw | can someone explain what the function of the PUBLIC_BRANCH argument is on bzr send? | 20:00 |
| fullermd | It's the location of a public mirror of your branch (assuming one exists) | 20:00 |
| n[ate]vw | how can I "unremember" it? I was playing with it, and now I can't play *without* it | 20:00 |
| fullermd | You can edit the branch.conf manually. Don't think there's a UI for it. | 20:01 |
| appcine | Hi! I've been using svn for a project about a year. Is it possible to preserve revision history somehow when switching to bzr? I'm not likely to revert as the system is quite stable, but it's fun to check out oooold stuff to see what you had back then :) | 20:03 |
| n[ate]vw | fullermd: ok. so by setting it, it would cause the branch to push changes to submit_branch? | 20:05 |
| n[ate]vw | hmm, but that role seems to be fulfilled by push_location already | 20:05 |
| fullermd | No, it's not used for push. | 20:05 |
| fullermd | I'm not sure if it's used for anything except send. Maybe some of the PQM stuff? | 20:06 |
| abentley | appcine: Check out bzr-svn. It provides lossless import from svn and export to svn. | 20:06 |
| appcine | abentley: Ah, sweet | 20:06 |
| n[ate]vw | fullermd: so I guess I'm confused as to what happen's when I specify dato's ../empty-branch | 20:07 |
| abentley | fullermd: Yes, it's used by PQM-submit also. | 20:07 |
| abentley | I can't think of anything else that uses it offhand. | 20:08 |
| fullermd | n[ate]vw: 'send' can include the revisions inline, or it can refer to an external branch ("Get these revs from there"). The public loc is used for the latter. | 20:08 |
| fullermd | (it may be used in the former too, if the person trying to do the merge needs other revs you didn't include) | 20:09 |
| n[ate]vw | ok, so if I specify a public branch, the ../sendable file won't actually include the history? | 20:09 |
| fullermd | No, you need --no-bundle to cause that. | 20:09 |
| abentley | But if you specify --no-bundle, then a public branch is required. | 20:10 |
| n[ate]vw | ok | 20:11 |
| abentley | The important thing to note is that dato's commandline specifies only one branch: the empty one | 20:12 |
| n[ate]vw | I guess I don't see why you would specify a "public_branch" on your local machine when sending to another developer | 20:12 |
| abentley | What you are sending is a requst to pull or merge your changes. If you have a public mirror, there's no need to include a bundle, and that's what public_branch is for. | 20:14 |
| n[ate]vw | ok, so the public_branch usually goes with --no-bundle, so that you can send some changes to somebody who already has a branch or can grab one from the public repo | 20:15 |
| abentley | Yes. | 20:15 |
| n[ate]vw | cool. then for a one-off "here's my code, and also please play around with bazaar", it looks as though my options are: A) push+remove-tree+tar on my side, untar+co for the receiver, or B) send on my side, init+pull on the receiver | 20:17 |
| n[ate]vw | in this case, A seems preferable given that I'm a little more familiar with bazaar than the other developer | 20:17 |
| johnny | so, what exactly do i get when i run cvsps-import on a repo | 20:19 |
| johnny | is it a repository already? | 20:19 |
| === Gwaihir_ is now known as Gwaihir | ||
| lifeless | johnny: 'bzr info' :) | 20:45 |
| johnny | lifeless, it says repository branch: . | 20:53 |
| johnny | in each area | 20:53 |
| lifeless | sounds like each has been converted separately, which is what I would have expected if you didn't create a repository yourself | 20:55 |
| lifeless | you can create a repository and bzr branch them into it all at once via bzr multi-pull (from bzrtools) | 20:55 |
| johnny | i only have 1 branch | 20:55 |
| johnny | HEAD | 20:55 |
| lifeless | no tags? | 20:56 |
| fullermd | Eh? If it says "repository branch", it's in a repo... | 20:56 |
| lifeless | fullermd: but a path of . ? | 20:57 |
| lifeless | johnny: perhaps I'm confused | 20:57 |
| lifeless | fullermd: unless 'repository branch' means 'the shared bit is on' | 20:57 |
| fullermd | I didn't say it's a great UI :p | 20:59 |
| fullermd | You're in the root of the branch, so it gives the branch path as '.' | 20:59 |
| johnny | it doesn't matter where i am | 21:00 |
| fullermd | The line after it gives the location of the repo. If it were a standalone branch, it would say "branch root: .", not "repository branch: ." | 21:00 |
| johnny | i have one tag called start | 21:01 |
| fullermd | But anyway, cvsps always puts its stuff in a shared repo. | 21:01 |
| johnny | i just want to shorten the path i think | 21:02 |
| lifeless | fullermd: oh god thats just confusing | 21:03 |
| lifeless | fullermd: surely it should say branch root always; and only sometimes show the repository root | 21:03 |
| fullermd | Well, it could be a checkout, in which case it'll say "repository checkout root: ." :) | 21:03 |
| fullermd | Of course, if you move into a subdir, it calls the branch root (by whatever name) by its full path, instead of relative to $CWD like it does with '.'... | 21:04 |
| abentley | The fact that it says "repository branch" not "standalone branch" means that it's in a shared repo. | 21:04 |
| johnny | any where in here ~/projects/redemmas/infoshopkeeper/branches/HEAD | 21:05 |
| fullermd | Or if you info $DIR from elsewhere, it always uses a path relative to ., unless that path would include a '..'... | 21:05 |
| johnny | it says repository branch: . | 21:05 |
| johnny | under infoshopkeeper thatis | 21:05 |
| fullermd | johnny: I don't think cvsps-import creates working trees in the repo, so there's nowhere you could go inside any of the branches BUT the root. | 21:06 |
| lifeless | abentley: I think it is confusing to have something that is always the same datum labelled differently | 21:06 |
| lifeless | abentley: if I understand what the output is doing correctly that is | 21:06 |
| johnny | aha.. ok | 21:07 |
| johnny | so, i think i'd like to reformat per the recommendations in the user guide | 21:07 |
| lifeless | if they are all under the same repository | 21:07 |
| lifeless | just mv the directories to where you want them (still under the repository) | 21:08 |
| fullermd | I never directly touch the repos/branches cvsps-import creates. I branch them elsewhere and rearrange stuff there. | 21:08 |
| fullermd | (that leaves them pristine for future incremental conversions, for one thing) | 21:08 |
| johnny | good recommendation | 21:09 |
| abentley | lifeless: Well, you've got a point. When I worked on "info", it was mostly to make it handle more cases show more paths. I didn't want to make too many changes at once. | 21:09 |
| abentley | ...handle more cases AND show more LOCATIONS... | 21:09 |
| johnny | now i just need to make loggerhead work | 21:11 |
| === AndyP_ is now known as AndyP | ||
| RainCT | Hi | 21:24 |
| lifeless | hi | 21:24 |
| james_w | hi | 21:24 |
| RainCT | is it possible to force a merge with uncommited changes? | 21:24 |
| lifeless | yes | 21:24 |
| lifeless | --force | 21:24 |
| lifeless | but its usually a bad idea; why do you want to? | 21:24 |
| RainCT | lifeless: because I have some changes that are not intended for commiting (local changes to get the code working on my machine) | 21:27 |
| lifeless | RainCT: merging with them present will result in you committing them | 21:28 |
| lifeless | RainCT: its definitely not what you want to do. | 21:28 |
| lifeless | RainCT: bzr shelve --all | 21:28 |
| lifeless | RainCT: then merge | 21:28 |
| lifeless | RainCT: commit | 21:28 |
| lifeless | RainCT: bzr unshelve --all | 21:28 |
| lifeless | RainCT: (but have you considered having a branch where the changes to make it work are committed) | 21:29 |
| RainCT | it's database password, path locations and such stuff.. | 21:31 |
| RainCT | lifeless: thanks | 21:31 |
| james_w | lifeless: won't that be a problem if the changes you merge affect the same area that your local changes do? | 21:31 |
| james_w | (as I recall shelve currently only does two way, and doesn't handle diffs that don't apply). | 21:32 |
| lifeless | james_w: shelve --force | 21:32 |
| lifeless | james_w: its less of a problem than a commingled tree with stuff you don't want to commit and a merge you need to commit | 21:32 |
| mwhudson | james_w: it's not worse than having conflicts in your tree where some changes are from the merge and some from your uncommitted changes is it? | 21:32 |
| james_w | no, it's not worse at all. | 21:33 |
| lifeless | RainCT: sounds like that stuff should not be altering versioned files; I'd consider making a branch that adds an include facility or some such, then you can have an ignored file with that local stuff | 21:33 |
| james_w | It's just not the perfect solution in all cases. | 21:33 |
| lifeless | RainCT: or you could still have a branch called 'machineX' that you commit them too, but never ever merge from it. | 21:34 |
| lifeless | james_w: for the given scenario --force is never the right thing | 21:34 |
| RainCT | it doesn't commit: http://paste.ubuntu.com/4565/plain/ (had an error like that some days ago too) | 21:35 |
| lifeless | james_w: (merge --force) I mean | 21:35 |
| james_w | it would be great to have a shelve that could do 3 way merges to avoid all of this. | 21:35 |
| lifeless | bb crashing on the resubmit tab :( | 21:39 |
| james_w | RainCT: I think that is the name of one of the directories in the path that is causing the problem. | 21:40 |
| james_w | I can't find the bug report at the moment. | 21:40 |
| lifeless | abentley: the containing dir? | 21:40 |
| lifeless | meh | 21:40 |
| lifeless | james_w: ^ the containing dir? | 21:40 |
| lifeless | RainCT: have you committed in other projects under programació ? | 21:40 |
| RainCT | lifeless: yes, all my branches are there and they work fine | 21:41 |
| james_w | lifeless: yeah, Programació | 21:41 |
| james_w | RainCT: do you have versioned symlinks in the other branches? | 21:41 |
| lifeless | RainCT: please try the commit with BZR_PDB=1 (BZR_PDB=1 bzr commit ....) | 21:41 |
| lifeless | RainCT: when it stops you'll be in a python debugger | 21:41 |
| lifeless | RainCT: and able to example the path it fails on | 21:42 |
| RainCT | james_w: Programació is a symlink to another hard disk | 21:42 |
| RainCT | beside that there is no other symlink I think | 21:42 |
| james_w | ah, but if it is that then it would be odd to only fail in this branch. | 21:43 |
| RainCT | lifeless: ok I'm there, what now | 21:43 |
| james_w | RainCT: p abspath | 21:43 |
| RainCT | ? | 21:43 |
| RainCT | u'/media/sdb2/rainct/Programaci\xf3/Python/revu/bin' | 21:43 |
| lifeless | ok thats wrong | 21:43 |
| lifeless | :) | 21:43 |
| lifeless | whats os.getfilesystemencoding() | 21:44 |
| abentley | lifeless: bb restarted. | 21:44 |
| lifeless | thanks | 21:44 |
| james_w | RainCT: also "p path" please. | 21:45 |
| RainCT | lifeless: in an interactive python console? | 21:45 |
| RainCT | u'bin' | 21:45 |
| lifeless | RainCT: where you are right now :) | 21:45 |
| james_w | RainCT: and "p self.basedir" please. | 21:46 |
| lifeless | jam: ping | 21:46 |
| RainCT | lifeless: *** AttributeError: 'module' object has no attribute 'getfilesystemencoding' (and the some with python -c "import os; print os.getfilesystemencoding()") | 21:46 |
| RainCT | u'/media/sdb2/rainct/Programaci\xf3/Python/revu' | 21:47 |
| james_w | it's sys.getfilesystemencoding() I think. | 21:47 |
| lifeless | print bzrlib.osutils._fs_enc | 21:47 |
| dato | yes | 21:47 |
| RainCT | james_w: 'UTF-8' | 21:47 |
| RainCT | lifeless: UTF-8 | 21:47 |
| luks | os.readlink doesn't seem to like unicode strings | 21:49 |
| lifeless | >>> '/media/sdb2/rainct/Programaci\xf3/Python/revu'.decode('utf8') | 21:49 |
| lifeless | Traceback (most recent call last): | 21:49 |
| luks | lifeless: u'/media/sdb2/rainct/Programaci\xf3/Python/revu/bin' already is unicode | 21:50 |
| lifeless | and giving it the u and encoding to utf8 fails too | 21:50 |
| lifeless | luks: yes I know | 21:50 |
| lifeless | luks: I am probing for what particular mis-interpretation has occured | 21:50 |
| luks | if I make a file 'á' on utf-8 filesystem, os.readlink(u'á') fails, but os.stat(u'á') works | 21:50 |
| lifeless | luks: which thanks to the entire lack of structure (its all bytes, HAI), is mainly trial and error | 21:50 |
| lifeless | oh foo, misread the output. | 21:52 |
| lifeless | ok, so its valid unicide | 21:52 |
| luks | yeah | 21:52 |
| james_w | so abspath = os.path.pathjoin(posixpath.realpath(safe_unicode(basedir)) , u'bin') | 21:52 |
| lifeless | right, we need a readlink wrapper | 21:52 |
| luks | but it's encoding it in ascii, not the FS encoding | 21:52 |
| lifeless | a) file a bug on python | 21:52 |
| lifeless | b) wrap readlink and do the fs_encoding ourselves | 21:53 |
| lifeless | RainCT: please file a bug on bzr | 21:53 |
| lifeless | RainCT: to work around this, cd to where the symlink points first | 21:53 |
| lifeless | RainCT: or if the symlink is in the tree you are committing; you'll have to patch bzr | 21:53 |
| luks | hm, from http://svn.python.org/projects/python/trunk/Modules/posixmodule.c it looks like it should be using the FS encoding | 21:54 |
| luks | but maybe it's a recent bugfix | 21:55 |
| awilkins_away | Hmm, shame you can't have bug dependencies in launchpad | 21:55 |
| === awilkins_away is now known as awilkins | ||
| lifeless | awilkins: we can't depend on python being fixed anyway | 21:55 |
| awilkins | No, but it would be nice to unpick the fix if it is ? | 21:57 |
| RainCT | ok, thanks :) | 21:57 |
| lifeless | awilkins: its a C module; we're not going to monkey patch with a new build of that at runtime :) | 21:57 |
| mwhudson | pff, ctypes! | 21:57 |
| * mwhudson hides | 21:58 | |
| james_w | http://svn.python.org/view?rev=52415&view=rev | 21:58 |
| lifeless | mwhudson: I know where you live | 21:58 |
| * RainCT renamed /media/sdb2/rainct/Programació to something without special chars (but the symlink still has them) and now it works | 21:58 | |
| lifeless | RainCT: what python version are you using ? | 21:58 |
| RainCT | 2.5.1-5ubuntu5 | 21:59 |
| * RainCT is away for a while | 21:59 | |
| lifeless | RainCT: please file a bug on ubuntu's python then; this is a regression from the look of it | 22:00 |
| awilkins | Looks like you need a test case for this anyway | 22:01 |
| lifeless | oh yeah, we have to change bzr | 22:01 |
| lifeless | someone has this in the field :( | 22:01 |
| james_w | lifeless: that fix isn't in 2.5 | 22:03 |
| james_w | it wasn't also fixed in the 2.5 branch as far as I can see. | 22:04 |
| lifeless | james_w: its from 2006 ! | 22:04 |
| james_w | yeah, but 2 months after the 2.5 branch was created. | 22:05 |
| lifeless | ekk | 22:06 |
| lifeless | anyhow, all moot; we support 2.4 | 22:06 |
| schierbeck | you guys know of a generic patching library for python? i just need to be able to apply a patch | 22:18 |
| lifeless | schierbeck: application is really trivial, the main issue is actually parsing | 22:19 |
| lifeless | schierbeck: if you mean patches created by 'diff -u' I *think* there is a parser in bzrtools. | 22:20 |
| RainCT | lifeless: so, what should I report? | 22:20 |
| lifeless | RainCT: the error and original backtrace | 22:20 |
| schierbeck | lifeless: okay | 22:20 |
| lifeless | RainCT: for bzr itself. For python, that os.readlink in 2.5 barfs on unicode paths. | 22:21 |
| schierbeck | just checking to see if there's anything obvious, i'm not that well-versed in python libraries | 22:21 |
| schierbeck | and searching for "patch library" yields quite a bit of noise... | 22:21 |
| lifeless | RainCT: and point at the fix in svn :) - this should be an ubuntu bug, because we can cherry pick that fix from svn | 22:21 |
| lifeless | schierbeck: yeah I can imagine | 22:21 |
| foom | surely it should be filed against upstream python so they backport it into the 2.5 branch... | 22:24 |
| lifeless | foom: well they presumably already know that 2.5 doesn't have it, they committed it solely to trunk after all | 22:26 |
| foom | lifeless: if they know 2.5 doesn't have it, and explicitly didn't backport it, I (as a python software developer) would be very unhappy to see it appear only in ubuntu python 2.5 | 22:27 |
| lifeless | foom: why? | 22:27 |
| foom | going against the explicit stable release policy decision of upstream for no particularly good reason. | 22:28 |
| lifeless | distros are more than a build engine | 22:29 |
| foom | it's not like anyone writing software could ever depend upon that fix existing, seeing as how no other python 2.5 will have it. | 22:29 |
| foom | so it provides no value | 22:29 |
| lifeless | I would be very unhappy if ubuntu didn't carry patches in advance of huge numbers of upstreams | 22:29 |
| foom | in advance is one thing, in opposition to is another | 22:29 |
| lifeless | -> #ubuntu-policy or something | 22:29 |
| igc | morning | 22:30 |
| lifeless | I've got some code to write, sorry. | 22:30 |
| foom | me too. | 22:30 |
| RainCT | bug 191694 reported | 22:30 |
| ubotu | Launchpad bug 191694 in bzr "bzr crashes commiting a branch from a directory with special characters" [Undecided,New] https://launchpad.net/bugs/191694 | 22:30 |
| foom | my only point was: it should be filed against upstream python to make sure they're aware. didn't want to get into an argument. :P | 22:30 |
| lifeless | foom: my point was file it against ubuntu where the bug was observed; doko will do something sane from there. | 22:30 |
| RainCT | (the title is not very good but I couldn't think of anything better..) | 22:30 |
| lifeless | RainCT: thanks | 22:31 |
| foom | lifeless: great. we can agree to that point. :) | 22:31 |
| luks | ouch, some tests are failing is readlink returns unicode strings | 22:32 |
| RainCT | lifeless: np | 22:34 |
| * RainCT thinks that it would be better if some of you reported the bug in python as he isn't really understanding what's going on :P | 22:35 | |
| luks | using %r in diff output is probably not a good idea, anyway | 22:35 |
| RainCT | well, good night | 22:35 |
| lifeless | night | 22:35 |
| ubotu | New bug: #191694 in bzr "bzr crashes commiting a branch from a directory with special characters" [Undecided,New] https://launchpad.net/bugs/191694 | 22:36 |
| abentley | schierbeck: Actually, the patch parsing / applying code lifeless was referring to is in Bazaar: bzrlib/patches.py | 22:39 |
| schierbeck | abentley: thanks! | 22:55 |
| hipertracker | Is there any Baazar plugin for Eclipse, Netbeans6 or TextMate? | 23:04 |
| igc | poollie, jam, spiv: call? | 23:05 |
| mwhudson | hipertracker: there's at least something for eclipse | 23:06 |
| === jml` is now known as jml | ||
| jam | igc: I don't want to talk to you, I just want to listen to the pretty music | 23:07 |
| igc | it's prettier today than normal for some reason :-) | 23:07 |
| igc | it's even bearable | 23:07 |
| jam | igc: I'll just enter the leader code, and we'll get done with it | 23:07 |
| pickscrape | Hi, does anyone know of a quick way to publish a fresh branch to a remote host? | 23:51 |
| LeoNerd | bzr push ? | 23:51 |
| pickscrape | The working copy is 384M, and the .bzr direcotry of my shared repo (containing just this branch) is 228M. | 23:52 |
| pickscrape | It's taking *ages*. | 23:52 |
| pickscrape | Well, it's taken about 40 minutes so far and the remote shared repo has reached 63M in size. Does that sound about right? | 23:53 |
| pickscrape | I'm using bzr+ssh. I'm just wondering if there's a way to speed it up. For example, tarring it up and using scp would be much quicker, but I doubt that it would put things in the right place. | 23:53 |
| LeoNerd | It should do | 23:54 |
| pickscrape | Even taking into account the shared repository? | 23:55 |
| LeoNerd | Oh.. hrm.. possibly not | 23:55 |
| LeoNerd | bzr push it locally to another local dir, then tar/scp that | 23:56 |
| pickscrape | Yeah, I'm thinking it's probably quicker to scp the raw WC to the server, and import and then branch locally to kick things off. | 23:57 |
| pickscrape | Thanks for the idea :) | 23:57 |
| pickscrape | My other question is, is it possible to do something like bzr branch <remote_url> <remote_url> to create a new branch remotely? | 23:57 |
| mwhudson | hard to beat tar.bz2 + scp for the initial transfer | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!