| garyvdm | lp offline :-( - Good thing I can commit to my VCS localy :-) | 00:07 |
|---|---|---|
| lifeless | beuno: lp is down? | 00:08 |
| beuno | lifeless, yes, roll out, etc | 00:09 |
| beuno | read only didn't work | 00:09 |
| beuno | so it should down... 40min? | 00:09 |
| lifeless | beuno: I know, you asked for ideas, I'm giving you one. | 00:09 |
| beuno | lifeless, I did? | 00:09 |
| beuno | it's been a long day | 00:09 |
| lifeless | 08:03 < beuno> lifeless, spiv, any ideas ^ | 00:09 |
| beuno | :) | 00:09 |
| rconan | hello... why does bzr commit try to connect to a remote server? | 00:12 |
| rconan | I thought commit was to update the local repository from the working tree | 00:12 |
| beuno | rconan, you probably did a checkout? | 00:12 |
| beuno | instead of a branch? | 00:12 |
| rconan | ah... | 00:13 |
| rconan | that makes sense | 00:13 |
| beuno | you can --reconfigure it into a branch | 00:13 |
| bob2 | or bzr unbind | 00:13 |
| rconan | I assuem that requires the remote repo to be there... | 00:13 |
| bob2 | no | 00:13 |
| rconan | so how do I make it into a branch? | 00:13 |
| bob2 | checkouts are by default heavy (i.e. contain the entire branch history) | 00:13 |
| rconan | $ bzr reconfigure --branch | 00:15 |
| rconan | bzr: ERROR: Working tree "/home/conan/work/sysint/" has uncommitted changes. | 00:15 |
| bob2 | then commit them | 00:15 |
| bob2 | or shelve them | 00:15 |
| beuno | well | 00:15 |
| rconan | but... I can't commit because the remote repo isn't there | 00:15 |
| bob2 | commit --local | 00:15 |
| rconan | ok I did reconfigure --branch now | 00:16 |
| rconan | now it says no working tree exists... | 00:16 |
| rconan | how do I create one? | 00:17 |
| garyvdm | rconan: huh ^ - can you pastebin bzr info | 00:19 |
| garyvdm | did you commit --local or shelve your changes? | 00:20 |
| rconan | http://pastebin.com/f6e6fa4ef | 00:20 |
| rconan | I shelved them | 00:20 |
| garyvdm | ok - "bzr checkout" to recreate the working tree | 00:21 |
| Peng_ | beuno: Releasing Loggerhead sounds good to me. Hmm, should the Dozer memory profiling thing get in? Does it matter? | 00:21 |
| rconan | $ bzr unshelve | 00:21 |
| rconan | bzr: ERROR: No changes are shelved. | 00:21 |
| rconan | hmm... | 00:21 |
| rconan | what happened to them? | 00:22 |
| beuno | Peng_, did it not get it? | 00:24 |
| Peng_ | beuno: It got approved, but nobody ever merged it. | 00:24 |
| beuno | Peng_, can you? :) | 00:25 |
| * beuno abuses Peng_'s awesomeness | 00:25 | |
| Peng_ | Heh, okay. | 00:26 |
| Peng_ | Although I never tested it since I don't have all of Dozer's dependencies installed. | 00:26 |
| Peng_ | And LP is down. | 00:26 |
| garyvdm | rconan: I just tested - and reconfigure --branch causes the shelves to be lost | 00:26 |
| beuno | Peng_, as long as LH runs, it's fine | 00:26 |
| garyvdm | beuno, rconan: The command you were looking for is bzr unbind | 00:27 |
| garyvdm | rconan: What fs are you using? any undelete options? | 00:28 |
| rconan | garyvdm: doesn't matter | 00:28 |
| rconan | I used the patch outputted from shelve to apply them again | 00:29 |
| rconan | sorted now | 00:29 |
| rconan | hoorah | 00:29 |
| rconan | thanks for the help guys | 00:29 |
| garyvdm | That could have been a lot worse.... | 00:29 |
| garyvdm | Why does reconfigure --branch kill the working tree? | 00:30 |
| garyvdm | lp back up :-) | 00:32 |
| spiv | garyvdm: because that's what it is defined to do, see "bzr help reconfigure" | 00:39 |
| Peng_ | Oh, LP is back up? Um, d'you mind if I don't take care of the Dozer thing for an hour or two? | 00:39 |
| beuno | Peng_, any time is good | 00:40 |
| beuno | thanks | 00:40 |
| beuno | :) | 00:40 |
| beuno | I'm off home now! | 00:40 |
| spiv | garyvdm: bzr reconfigure --tree is probably what was wanted. | 00:40 |
| spiv | (I don't much like the labels that reconfigure uses) | 00:40 |
| garyvdm | spiv: reconfigure --branch should stop if there are shelves then. | 00:41 |
| spiv | garyvdm: yeah, probably. File a bug? :) | 00:42 |
| lifeless | remove-tree should error too | 00:44 |
| lifeless | without force | 00:44 |
| lifeless | same root cause I imagine | 00:44 |
| lifeless | spiv: 4 outstanding branches; I'm changing tracks while review catches up | 01:18 |
| igc | morning | 01:32 |
| Peng_ | beuno: ping? | 01:33 |
| Peng_ | beuno: I was just working on merging dozer, and when I run with --memory-profile now, Ctrl+C doesn't cause the process to fully exit anymore, so I'm not going to merge it yet. | 01:34 |
| mwhudson | how insane/hard would it be to access bazaar branches over the plain sftp protocol? | 01:43 |
| mwhudson | (i.e. without ssh being involved) | 01:43 |
| spiv | mwhudson: not so hard, probably. | 01:44 |
| spiv | mwhudson: the bzr test suite may already do that? | 01:44 |
| Peng_ | mwhudson: Oh, hi! Can I bug you about Loggerhead? :) | 01:44 |
| mwhudson | Peng_: sure | 01:44 |
| Peng_ | mwhudson: See above what I said about Dozer. Does it work for you? Do you still think it's okay to merge with that issue? | 01:45 |
| Peng_ | Especially since it's probably not a bug in Loggerhead. | 01:45 |
| mwhudson | spiv: i'll have a look | 01:45 |
| mwhudson | Peng_: mm, probably | 01:45 |
| mwhudson | Peng_: i mean, i hope noone enables dozer in production :) | 01:46 |
| Peng_ | Heh. | 01:46 |
| mwhudson | Peng_: it would be bad if this branch meant that you had to have dozer installed to run loggerhead at all | 01:46 |
| Peng_ | mwhudson: You only need Dozer installed to run with --memory-profile. | 01:48 |
| mwhudson | Peng_: cool | 01:48 |
| Peng_ | mwhudson: So, you think I should still merge it? | 01:49 |
| mwhudson | Peng_: yeah | 01:49 |
| Peng_ | OK. | 01:49 |
| Peng_ | Done. | 01:49 |
| Peng_ | Do you mind if I file a bug to follow up on my Ctrl+C issue? | 01:50 |
| mwhudson | Peng_: that sounds like a good plan | 01:51 |
| Peng_ | OK. | 01:51 |
| * igc offline for a few hours - bbl | 01:59 | |
| spiv | mwhudson: at a glance, you could make a subclass of SFTPTransport that overrides _create_connection to do something other than use "vendor = _get_ssh_vendor(); ... ; vendor.connect_sftp(...)" | 02:04 |
| spiv | mwhudson: probably call it PlainSFTPTransport and register it as plainsftp:// or something? Do you want it to talk via TCP or perhaps via pipes to a subprocess? | 02:06 |
| mwhudson | spiv: tcp | 02:18 |
| mwhudson | spiv: the motivation is wanting to run the bzr serve processes on a different box to that which stores the branches for launchpad | 02:18 |
| mwhudson | spiv: so we can scale # of concurrent connections by plugging in more boxes | 02:19 |
| jml | bzr 1.14 network performance is pretty schmick guys -- well done | 02:35 |
| lifeless | good | 02:36 |
| * jml tries some pushing experiments. | 02:36 | |
| jml | lifeless: no-op push to a stacked 1.9 branch is ~12s from here, ~5s for 'bzr ping'. | 02:39 |
| spiv | no-op push has been pretty good for ages now :P | 02:40 |
| spiv | Hmm, to a stacked branch though... | 02:41 |
| jml | yeah. | 02:41 |
| lifeless | jml: thats still kinda slow | 02:41 |
| lifeless | spiv: likely opening the stacked on branch | 02:41 |
| jml | lifeless: yeah, kind of slow -- 14hpss calls | 02:41 |
| jml | lifeless: but a lot better than I recall. | 02:42 |
| jml | and all the hpss numbers are small | 02:43 |
| jml | hmm. HPSS calls: 66 in ~46s for pushing a new stacked-on branch. | 02:43 |
| jml | stacked, rather. | 02:43 |
| lifeless | jml: thats high | 02:44 |
| lifeless | jml: lots of get_parent_map ? | 02:44 |
| jml | yeah. | 02:44 |
| jml | lifeless: only 4. | 02:46 |
| lifeless | oh | 02:46 |
| lifeless | any vfs calls? | 02:46 |
| jml | lifeless: more stats & gets than I would have expected -- want a copy of the log? | 02:46 |
| lifeless | jml: oh, lp is still running 1.13 right? | 02:46 |
| jml | lifeless: nope. | 02:46 |
| jml | lifeless: 1.14rc2 | 02:46 |
| jml | hmm. | 02:46 |
| lifeless | yes, a log would be good then; I would have expected VFS free push | 02:47 |
| lifeless | you have plugins that might be triggering vfs calls? | 02:47 |
| jml | sent. | 02:48 |
| jml | lifeless: bzrtools, imapclient, loom, ping, pqm, stats. | 02:50 |
| lifeless | 11.029 hpss call: 'BzrDir.get_config_file', | 02:52 |
| lifeless | '~jml/launchpad/has-linked-branch/' | 02:52 |
| lifeless | 11.029 (to | 02:52 |
| lifeless | bzr+ssh://bazaar.launchpad.net/%7Ejml/launchpad/has-linked-branch/) | 02:52 |
| lifeless | 11.372 result: ('UnknownMethod', 'BzrDir.get_config_file') | 02:52 |
| lifeless | upgrade your server :) | 02:52 |
| jml | lifeless: as in, you think our server is not running 1.14rc2 as advertised? | 02:53 |
| lifeless | no | 02:53 |
| lifeless | 1.15 removes more VFS | 02:53 |
| jml | lifeless: ahh, ok. | 02:53 |
| jml | lifeless: well, given that Bazaar hasn't quite managed to release 1.14 yet, I might wait a little before upgrading to 1.15 :) | 02:53 |
| spiv | jml: huh? 1.14 is out. | 02:54 |
| jml | oh, I must have missed the announcement to the mailing list. | 02:54 |
| spiv | Yes, you must have. :P | 02:54 |
| spiv | (not to mention the topic in this very channel) | 02:55 |
| === jml changed the topic of #bzr to: Bazaar version control system | 1.14 released 29 April, 2009 | 1.13.2 released 28 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| jml | spiv: I can explain that! | 02:55 |
| jml | spiv: my eyes stopped when I saw "1.13.2 released" | 02:56 |
| nok5 | i changed the path of a branch, when I do bzr pulling, it will say: Parent not accessible given base blah blah.., should I rebase or reconfigure the branch? | 02:59 |
| lifeless | nok5: just give it the full url to pull from | 03:03 |
| lifeless | and add --remember | 03:03 |
| nok5 | still the same error with url to pull | 03:03 |
| lifeless | thats odd | 03:04 |
| lifeless | can you run with -Derror and pastebin the output please | 03:04 |
| nok5 | even bzr info yields the same erro | 03:04 |
| nok5 | the output is here http://padfly.com/bzr | 03:06 |
| lifeless | thats not for pull | 03:07 |
| nok5 | ok | 03:07 |
| nok5 | sorry, updated, please refresh | 03:08 |
| lifeless | ok | 03:09 |
| lifeless | definitely a bug | 03:09 |
| lifeless | look in .bzr/branch/branch.conf | 03:09 |
| lifeless | edit that file to give it the correct path | 03:09 |
| lifeless | and I'll file a bug | 03:09 |
| nok5 | ok, thank you | 03:10 |
| nok5 | solved | 03:11 |
| nok5 | lifeless: the bug link pls | 03:16 |
| lifeless | nok5: don't have it yet - i filed by email | 03:16 |
| lifeless | https://bugs.edge.launchpad.net/bzr/ will have it soon | 03:17 |
| nok5 | roger that | 03:17 |
| BullHorn | Hi there, Iḿ new to bzr, I installed bzr on windows. I created a folder on external drive and want to check files into it from a folder on my c:. tortoise just allow checkout. Any Idea how to do this. Iḿ only used to cvs & svn | 03:28 |
| bob2 | there's a tortoise thing for bzr, dunno how complete it is | 03:30 |
| nok5 | BullHorn: you mean only checkout is allowed in c:. tortoise ? | 03:33 |
| BullHorn | Ok, I've a download folder on c:. I created a download folder on external. I initialized folder on the external drive and want to move or add the files from the c:/download to the external download. But want to use bzr for eas of use. I need to make space as I want to install linux on my laptop as well | 03:36 |
| BullHorn | I thought it will be better to manage the folder with bzr that just to copy it across | 03:38 |
| davidstrauss | BullHorn: TortoiseBzr works reasonably well | 03:39 |
| BullHorn | how do I book/ add it to the repositry or do I need to copy it across and then just let TortoiseBzr init the folder? | 03:40 |
| davidstrauss | BullHorn: I don't actually use it myself, but I'm pretty sure it just magically works on your checkouts and branches | 03:41 |
| nok5 | BullHorn: it seems what you want is just copy/sync files on C drive to your bzr repo on external drive. but i dont know how can it help to save the space. you may init the original folder as shared repo, then setup a branch on your external drive | 03:52 |
| BullHorn | the idea is to have the external as the parent repositry. I only want to pull what I need. the rest I'll delete on my c:. BUT if someone else add a file/folder to that repositry I want to be able to see it. I know you're suppose to use it with source but sometimes one want to use it with any files. I'm trying to figure out how the distributed vcs model works. | 04:14 |
| nok5 | BullHorn: yes, you can cherrypick (see user guide) from external folder to your c drive | 04:31 |
| lifeless | BullHorn: the way it works is that you have many branches | 04:37 |
| lifeless | BullHorn: you can push or pull from each | 04:38 |
| lifeless | BullHorn: what you want to do is to get up and running with your current folder in bzr, then *push* it to your external drive for backup | 04:38 |
| lifeless | 'checkout' is for wrking like cvs or svnw here your branch is somewhere else, and every 'commit' is immediately propogated | 04:39 |
| lifeless | spiv: ping | 04:44 |
| lifeless | spiv: reviews plox | 04:45 |
| lifeless | nok5: bu 369619 | 04:54 |
| lifeless | nok5: bug 369619 | 04:54 |
| ubottu | Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/369619/+text) | 04:54 |
| nok5 | lifeless: i've already subscribed, thanks for your notice | 04:55 |
| mwhudson | Source format does not support stacking, using format: 'Remote BZR Branch' | 04:55 |
| mwhudson | not so good :) | 04:55 |
| BullHorn | I’m going to leave it for now. I’m just frustrating myself even more on this windows platform while I want to move to Linux asap. It’s not working like TortoiseSvn yet. By the way will bzr logs a directory that has been added? | 05:03 |
| lifeless | yes | 05:04 |
| spiv | lifeless: plox? | 05:21 |
| spiv | (I can guess what you mean, but I'm curious to know precisely...) | 05:21 |
| gotgenes | How does one list all files tracked by a bzr branch? | 05:30 |
| thumper | `bzr ls` I think | 05:31 |
| gotgenes | thumper: ah | 05:31 |
| gotgenes | I was trying bzr list | 05:31 |
| thumper | `bzr help ls` would help | 05:32 |
| thumper | not recursive by default | 05:32 |
| thumper | and -V for versioned files | 05:32 |
| thumper | bzr ls -VR for all versioned files | 05:32 |
| gotgenes | hmm, I'm not sure if I understand what a "Versioned" file is compared to what's output by default via bzr ls. | 05:34 |
| lifeless | gotgenes: a versioned file is one that bzr is tracking | 05:34 |
| lifeless | gotgenes: an unversioned file is one that bzr is not tracking | 05:34 |
| gotgenes | lifeless: I see. So by default, bzr ls does, simply, ls? | 05:35 |
| lifeless | roughly yes | 05:37 |
| gotgenes | Hmm. | 05:37 |
| lifeless | ls -RV will list all the versioned files in the tree recursively | 05:38 |
| gotgenes | lifeless, thumper: Thanks. | 05:44 |
| gotgenes | Okay, so next question. I have a symbolic link that I need to remove, but bzr remove gives "ERROR: Not a branch" | 05:45 |
| gotgenes | It's following the symlink | 05:46 |
| lifeless | just rm it | 05:47 |
| lifeless | then bzr rm the path it had | 05:47 |
| lifeless | we have a bug open on symlink friendliness | 05:47 |
| gotgenes | lifeless: Indeed, some more clever searching got me to the trail of bugs on LP. | 05:47 |
| gotgenes | Hmm, this could be more troublesome because I actually want to retain the symlink. | 05:48 |
| gotgenes | And it's actually many symlinks | 05:49 |
| gotgenes | I guess I should script this. | 05:49 |
| lifeless | python -c 'import bzrlib.workingtree; t= bzlib.workingtree.WorkingTree.open(".").unversion(path)' | 05:50 |
| lifeless | ^ workaround | 05:50 |
| gotgenes | lifeless: No kidding? Ooh! Let me play with that. | 05:50 |
| igc | back | 05:57 |
| gotgenes | lifeless: Any suggestions on how to check whether or not the file is versioned in the first place using the WorkingTree? | 06:26 |
| lifeless | gotgenes: tree.path2id(path) is None -> not versioned | 06:29 |
| gotgenes | lifeless: sure enough | 06:31 |
| gotgenes | Thanks | 06:31 |
| gotgenes | Is there an os.walk equivalent in the WorkingTree, actually? | 06:32 |
| gotgenes | Hmm, there's a WorkingTree._walkdirs() | 06:33 |
| gotgenes | lifeless: ah, it seems unversion accepts file_ids, not paths. | 06:35 |
| gotgenes | Ah, shoot, walkdirs() (sans underscore) does exactly what I want. | 06:40 |
| lifeless | gotgenes: path2id will get you ids | 06:42 |
| gotgenes | lifeless: yeah, it looks like walkdirs() will get me all I need to detect all symlinks and get their ids, actually | 06:42 |
| gotgenes | the only problem is it's complaining the working tree is not locked | 06:43 |
| gotgenes | hrumph | 06:43 |
| lifeless | tree.lock_write()...finally: tree.unlock() | 06:43 |
| gotgenes | lifeless: You're helpful and a half. | 06:43 |
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| gotgenes | lifeless: Your profile image on LP is amusing. | 07:13 |
| lifeless | :> | 07:13 |
| gotgenes | I actually saw it first | 07:13 |
| Peng_ | Hey, that's clever! | 07:13 |
| gotgenes | then was like, "Why the hell... Oh, I wonder if he's in the Southern Hemisp..." Then I looked at the map. | 07:14 |
| vila | hi all | 07:17 |
| gotgenes | vila: Hello. | 07:17 |
| lifeless | gotgenes: :) | 07:24 |
| gotgenes | lifeless: How long have you lived in Sydney? | 07:28 |
| lifeless | ~13 years | 07:29 |
| gotgenes | lifeless: Wow, that's a good stretch. | 07:43 |
| gotgenes | Were you previously in Australia? | 07:43 |
| gotgenes | Also, thanks for taking a look at my bug report. Was poking around that part of the code and just wasn't sure, but figured a report wouldn't hurt. | 07:43 |
| lifeless | no worries | 07:46 |
| lifeless | I'm originally from NZ | 07:46 |
| gotgenes | lifeless: Really? | 07:46 |
| lifeless | yup | 07:47 |
| gotgenes | lifeless: I must get out to that region of the globe some day | 07:49 |
| gotgenes | let "some day" <= 4 years | 07:49 |
| lifeless | :) | 07:50 |
| gotgenes | lifeless: Do you work for Canonical now? | 07:50 |
| lifeless | yes I do; I have since the start | 07:51 |
| gotgenes | lifeless: start being graduation? | 07:52 |
| gotgenes | or start of the company? | 07:52 |
| Peng_ | Since the start of TIME. | 07:53 |
| gotgenes | Wow | 07:54 |
| gotgenes | That's epic. | 07:54 |
| gotgenes | That's like, Chrono Trigger epic. | 07:54 |
| lifeless | technically since before incorporation - I was one of the first employees when Mark started on this venture | 07:55 |
| gotgenes | lifeless: Neato. How did you get tapped or find out about it? | 07:57 |
| lifeless | I was a significant contributor to GNU Arch | 07:58 |
| bob2 | and author of barch! | 07:58 |
| lifeless | bob2: heh; that didn't go far - Tom's translation of larch to C met my porting needs | 07:59 |
| gotgenes | I guess I don't know my history of Bazaar. I should search to find out if it existed before Canonical. | 08:03 |
| gotgenes | Seems not. | 08:04 |
| gotgenes | 2007 vs 2004 | 08:04 |
| bob2 | canonical was founded in 2004 | 08:04 |
| bob2 | bzr (aka bazaar-ng) in 2005 | 08:04 |
| lifeless | http://bazaar-vcs.org/HistoryOfBazaar | 08:04 |
| lifeless | I like how john says I was 'probably the leader' :P | 08:05 |
| lifeless | can be hard to tell in meritocracies ;) | 08:05 |
| gotgenes | lifeless: Haha | 08:06 |
| lifeless | Mark and I called the project Bazaar; I've probably got the IRC log of the decision somewhere | 08:07 |
| lifeless | later all | 08:12 |
| gotgenes | lifeless: night | 08:14 |
| AntoineLafontain | I have a question about merging branches... is there anyone here that would have some time to spare? Thanks | 08:27 |
| spiv | AntoineLafontain: sure, what's the question? | 08:27 |
| AntoineLafontain | I have a question concerning merging a branch with a branch where files have been removed... is there a way to ignore some files from the parent branch so that no conflicts needs to be resolved on those removed files/folder. Or maybe someone could enlighten me on how I should think about this problem in order to solve my issue. I hope this is the right place to ask those kind of questions, thanks for your time. | 08:29 |
| AntoineLafontain | and I have to say I have limited experience with versioning... | 08:30 |
| bob2 | you can't just fix the conflict after the merge, before the commit? | 08:32 |
| spiv | AntoineLafontain: there's not really any way to ignore parts of a merge, but dealing with the conflicts shouldn't be hard. | 08:32 |
| spiv | AntoineLafontain: the closest to ignoring parts is to do the merge and then selectively revert the files you didn't want to change. | 08:33 |
| AntoineLafontain | it's not hard, but it's just all the same files all the time... it just feels redundant to do this every time I merge with the parent, since those files I removed voluntarily. | 08:34 |
| AntoineLafontain | I see, there's no 'convenient' way to just have those 'auto resolve' or something... i'll just write a script to have those files always revert after a merge... | 08:35 |
| AntoineLafontain | how do people go about when they branch from a remote project and then just want to work with a part of it, or remove part of it but still be able to merge back changes made to the remove repository back to the part they work with? | 08:38 |
| AntoineLafontain | Maybe I'm thinking this the wrong way, but I feel this would be a pretty common thing. | 08:39 |
| spiv | There's not (yet) support for breaking a tree into smaller trees. | 08:39 |
| AntoineLafontain | this would be a convenient tool isn't it? | 08:40 |
| spiv | Normally if you expect people to work on parts separately you'd make different branches for those parts. | 08:40 |
| AntoineLafontain | I see | 08:40 |
| spiv | Or, more usually, just not worry about it. For many projects the wasted disk space and bandwidth is pretty insignificant. | 08:41 |
| spiv | i.e. not delete the files at all. | 08:41 |
| AntoineLafontain | I see. I'm more concerned about some files I do not want to upload when using bzr upload | 08:41 |
| spiv | There's work to make this more convenient, part of something called "filtered views". | 08:42 |
| spiv | Ah, sounds like a feature to add to bzr upload then. | 08:42 |
| AntoineLafontain | That could also be a way to go | 08:42 |
| spiv | bzr upload currently assumes you want to upload the whole tree I think, but an exclude list sounds like a reasonable feature for it. | 08:42 |
| AntoineLafontain | if upload could keep a black list | 08:42 |
| AntoineLafontain | yeah, I feel it basically would be better if a merge would consider the ignore list in the child branch... | 08:43 |
| AntoineLafontain | then upload could be kept simple... upload all and it's all good | 08:43 |
| spiv | The existing ignore list is purely about what "bzr status" and "bzr add" will do. | 08:44 |
| AntoineLafontain | yeah, I've tried it a few times to 'experiment' | 08:44 |
| spiv | It intentionally has no effect on files that are versioned (even if their file name matches). | 08:44 |
| AntoineLafontain | or a an option when using remove to keep a special 'flag' if a user would set it to ignore a folder / files when set | 08:45 |
| spiv | bzr upload is a pretty basic mechanism for code deployment, though. | 08:45 |
| AntoineLafontain | well I wouldn't say I have a complete understanding of what versioning is all about, my background is more into design than coding, but for my own sanity, I would like to have some kind of way to do this and once done not have to think about it everytime I merge with the parent repository | 08:47 |
| AntoineLafontain | but I have to say thanks for the insights, it does confirm that I wasn't completly off track when thinking there's no way to achieve this presently | 08:48 |
| spiv | Yeah, you shouldn't need to repeat work. | 08:49 |
| spiv | You're welcome, glad I could help. I think a feature request for bzr-upload is probably the best option. | 08:49 |
| spiv | (Or perhaps just use rsync?) | 08:50 |
| AntoineLafontain | yeah, rsync i prefer over bzr upload... how can I use rsync to achieve what I want? | 08:50 |
| AntoineLafontain | and sorry for my 'basic' questions :) | 08:51 |
| spiv | Use the --exclude option | 08:51 |
| AntoineLafontain | can eclude be used with a file listing the files/folders I want to exclude (only used the command line in the past for oomiting a file or two...) | 08:52 |
| AntoineLafontain | hmm I think I'm starting to see a decent solution now... | 08:52 |
| spiv | AntoineLafontain: yes, rsync has an --exclude-from=FILE option too | 08:53 |
| spiv | AntoineLafontain: read the man page :) | 08:54 |
| AntoineLafontain | yes, I just did it while writing... | 08:54 |
| AntoineLafontain | thx for your patience... it's not often I have someone to just talk about those things around the office -designers hate command line based tools... I'm seen as a freak around the office... | 08:55 |
| AntoineLafontain | thank you again for your time spiv. | 08:58 |
| vila | AntoineLafontain: sorry for coming late in the game, but yes, bzr-upload should allow uploading a partial tree, this is a known limitation | 09:06 |
| === sabdfl1 is now known as sabdfl | ||
| AntoineLafontain | should? shouldn't | 09:07 |
| AntoineLafontain | ? | 09:07 |
| vila | whether this will be achieve by using a filtered view or a by a mean specific to bzr-upload has not yet been decided :) | 09:07 |
| AntoineLafontain | ah! okey, just read you better | 09:07 |
| AntoineLafontain | well my own guts tell me, if possible, it would be 'cleaner' to be able to remove files in a branch and still be able to merge from the parent while ignoring some files/folders from the parent | 09:08 |
| AntoineLafontain | then bzr-upload would just upload the filtered tree | 09:08 |
| AntoineLafontain | maybe there's other considerations that I can't fathom... | 09:09 |
| vila | AntoineLafontain: it's better to version a whole project and then upload only part of it. | 09:10 |
| vila | For example, if you have tests, you may want to *not* upload them, yet, you *want* to version them in sync with the code you're testing | 09:10 |
| AntoineLafontain | well the whole project is keep in the parent branch... the sub branch is my 'filtered' project... removing parts from the parent before publishing | 09:11 |
| AntoineLafontain | allowinf to keep the core intact, complete, but making possible to update the child when the core is updated, modified, but only in the parts that are kept in the child... does this make sense? | 09:11 |
| vila | AntoineLafontain: in that case, nested trees will be more appropriate than filtered views, both are actively being worked on at the momemt | 09:12 |
| LarstiQ | AntoineLafontain: I fail to see why you would do that? | 09:12 |
| vila | AntoineLafontain: yes, that makes sense | 09:12 |
| AntoineLafontain | the core is a project that I do not maintain... | 09:13 |
| * LarstiQ scrolls up for more context | 09:13 | |
| AntoineLafontain | so I just update it when there's updates to it and so on. | 09:13 |
| AntoineLafontain | but I want to clean up some of the files from it, but want to be able to automate the update process for projects spawned from the core | 09:14 |
| AntoineLafontain | vila> could I ask for a bit more insight on nested threes and filtered views? | 09:15 |
| AntoineLafontain | or some links? | 09:15 |
| vila | AntoineLafontain: hmm, so you want both a nested tree (for your sub branch) and a filtered view to upload only the relevant files | 09:15 |
| AntoineLafontain | possibly... I'm not sure what is needed... but if possible I would like to have the workflow I described... or a good idea on a better workflow | 09:16 |
| vila | AntoineLafontain: I think your description fully makes sense, as well as your workflow, but not all the bits are in place in bzr for your exacts needs :-/ | 09:17 |
| AntoineLafontain | the filtered view it seems I could manage with rsync --exlude-from and keeping a versioned exclude file for each projects | 09:17 |
| LarstiQ | I'm glad vila sees it, because I don't :) | 09:17 |
| AntoineLafontain | well sub-projects if I follow my own logic | 09:17 |
| vila | LarstiQ: say you have a branch with 'web-site' as a nested tree and additionally 'web-site' contains some password file, you want to upload 'web-ste' minus passwd | 09:18 |
| vila | AntoineLafontain: Is the above a correct approximation of your needs ? | 09:18 |
| LarstiQ | vila: fair enough, but why can't that be done as a bzr-upload feature? | 09:18 |
| vila | LarstiQ: Ooooh it can ! | 09:19 |
| LarstiQ | vila: and if you don't want it in your regular tree, why isn't `bzr rm; bzr ci; bzr merge` enough? | 09:19 |
| AntoineLafontain | well simply put, it's to be able to work with the drupal project and then have a branch with a selection of contrib modules, then from that branch would spawn the real projects | 09:19 |
| AntoineLafontain | but each project would not have all the same module selection, but for convenience and upgrade, I would like to keep all the main modules I use in one branch | 09:20 |
| vila | LarstiQ: sounds a bit too much like reverting some decisions may be harder than it should | 09:20 |
| AntoineLafontain | and keep my custom code in the 'projectX' branch | 09:21 |
| AntoineLafontain | so updating core would meaning merging it in the module branch, then in all the sub projects | 09:21 |
| AntoineLafontain | updating a module would mean only updating the projects | 09:22 |
| AntoineLafontain | or I'm just making this just all too complicated for nothing... | 09:22 |
| vila | AntoineLafontain: exactly what nested trees are about, using one of them for each module and composing higher level projects from them | 09:22 |
| AntoineLafontain | thx vila, sounds like my reasoning wasn't too far fetched | 09:23 |
| vila | AntoineLafontain: track http://bazaar-vcs.org/NestedTreeProgress | 09:23 |
| LarstiQ | AntoineLafontain: right, that sounds like nested trees | 09:23 |
| AntoineLafontain | and this is not yet supported? | 09:23 |
| vila | AntoineLafontain: this is currently, actively, working on and should be available shortly | 09:25 |
| LarstiQ | AntoineLafontain: the split and join commands exist, by-value trees have been in bzr for a long time, by reference is receiving active developement | 09:25 |
| vila | AntoineLafontain: how many modules do you handle so far ? | 09:26 |
| AntoineLafontain | humm, I'll say i have a selection of about 15 to 20? | 09:26 |
| AntoineLafontain | which I do not use in all projects | 09:26 |
| AntoineLafontain | now I basically keep those in a normal folder | 09:27 |
| vila | ok | 09:27 |
| AntoineLafontain | and cherry pick the ones I want for project X and those for project Y and so on | 09:27 |
| AntoineLafontain | I'm actively trying to figure out a decent workflow using versioning and trying to automate many of those redundant tasks | 09:28 |
| AntoineLafontain | and I have to say that bazaar as been impressively easy to pick up for the basics, but I got stumped when trying to achieve the pattern I'm talking right now | 09:29 |
| vila | AntoineLafontain: right, so nested trees sounds like the silver bullet for that and filtered views (or a closely related mechanism) should address the upload part | 09:29 |
| AntoineLafontain | I will try to take some time to read about those nested threes and see if I can wrap my head around those | 09:30 |
| vila | roughly, in your case, it will mean updating your project and automatically get your modules updated | 09:30 |
| AntoineLafontain | sounds like I get to eat the whole pie after all ;P | 09:31 |
| AntoineLafontain | thanks for all your insights! | 09:32 |
| vila | AntoineLafontain: you're welcome, don't hesitate to come back and share your experiments or other thoughts | 09:32 |
| AntoineLafontain | will do. | 09:34 |
| AntoineLafontain | vila> I hope you're still around. | 09:59 |
| * igc dinner | 10:00 | |
| AntoineLafontain | I've read about split and was wondering If I got it right. Basically, using split, I can make a subfolder of a branch an independent branch on its own. What I'm wondering is, what will happen to the splitted branch if the original branch is merge to its parent branch, which is a remote branch... wouldn't this cause a conflict since the split doesn't exist in the parent branch? | 10:03 |
| LarstiQ | AntoineLafontain: in the container where you split the subbranch out, everything in that subdir is deleted from that point on. | 10:03 |
| dlee | bzr log --long shows timestamps with -0400, but I'm on US Eastern time, which is -0500 afaik. The time is the correct local time. Where should I look for the cause of this? | 10:04 |
| LarstiQ | AntoineLafontain: so if you merge it into something else, you'll get a series of deletions merged. | 10:04 |
| LarstiQ | dlee: looking through bzr.dev log, the timestamps vary. | 10:05 |
| AntoineLafontain | larstiq> I'm not sure I understand the implication of this | 10:05 |
| LarstiQ | dlee: so it seems more to do with the time of recording than displaying. | 10:05 |
| LarstiQ | AntoineLafontain: if you can rule out merging it into the parent, that would make life simpler. | 10:05 |
| LarstiQ | AntoineLafontain: that, or propagating the split to the parent. | 10:06 |
| dlee | Not sure I understand. The time shown is the correct commit time, shown as local time; but the -0400 makes it look like it was recorded with the wrong timezone. Makes me think I should offset the time I see by an hour to get local time of commit, but that would actually be wrong. | 10:07 |
| Kinnison | Is it doing that on fresh commits you're doing now? | 10:08 |
| dlee | Yes. I have v1.10 on this box though. I can try in a later version on another box if that would help. | 10:08 |
| AntoineLafontain | then... lets say theres a parent branch A, I make a local branch of it A'... I want to keep the ability to update A' with any changes made to A (using merge?) but I want to add some files inside a folder of A' and be able to maintain seperate threes of tose subfolders too (each folder is a module added to the core A project). Then I wan to be able to make a B project which will be based on A' plus a selection of modules put ins | 10:10 |
| Kinnison | and if you type 'date' in at a terminal, does it show the right timezone? | 10:10 |
| dlee | Just did: v1.13.1, on MacOS via MacPorts. Time stamp of just-committed commit: "timestamp: Thu 2009-04-30 05:09:23 -0400" | 10:10 |
| dlee | Current time: 5:10 EDT (-0500 I think). I wonder if this is a daylight savings thing or somesuch. | 10:11 |
| AntoineLafontain | In the nested three design document there's the 'Composite tree' description that would maybe suit what I want to achieve... | 10:11 |
| LarstiQ | AntoineLafontain: truncated at 'of modules put ins' | 10:11 |
| AntoineLafontain | a selection of modules put inside A' and some custom code/config files which are only related to B... | 10:11 |
| AntoineLafontain | sorry | 10:12 |
| dlee | date result on Mac: Thu Apr 30 05:11:44 EDT 2009 | 10:12 |
| LarstiQ | dlee: and `date -u`? | 10:12 |
| dlee | date -u: Thu Apr 30 09:12:40 UTC 2009 | 10:12 |
| LarstiQ | dlee: it looks like the correct time to me. | 10:13 |
| LarstiQ | dlee: you're at -4 at the moment. | 10:13 |
| dlee | Then I'm probably being confused by Windows... Windows says we're five hours off of UTC. Are we 4 hours off at this time of year maybe? Hmm... I guess the Windows-displayed offset never changes. Somehow I thought this one would embarrass me. :) | 10:14 |
| gotgenes | lifeless: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html | 10:14 |
| ronny | sup | 11:29 |
| ronny | LarstiQ: who do i need to bug if i need a range of older bzr's to be easy-install-able a gain | 11:29 |
| james_w | what makes them uninstallable? | 11:30 |
| ronny | james_w: easy-install wont find any version but the latest, most likely due to missing links in the related http pages | 11:30 |
| ronny | oh, and can someone please point me to a wiki page/documentation listing the api changes since bzr 1.0 | 11:31 |
| LarstiQ | ronny: I'd look at NEWS for that | 11:31 |
| LarstiQ | ronny: the easy_install issue is that specific releases at pypi have no download link? Like, http://pypi.python.org/pypi/bzr/1.10 | 11:32 |
| james_w | ronny: which page? | 11:32 |
| james_w | # Download URL: http://bazaar-vcs.org/Download | 11:33 |
| james_w | is that the reason? | 11:33 |
| ronny | james_w: i think so | 11:33 |
| ronny | easy_install goes down there till it hits http://www.bazaar-vcs.org/Download | 11:33 |
| ronny | then fails | 11:34 |
| james_w | presumably anyone listed as owner can edit the page | 11:34 |
| LarstiQ | ronny: do you have an example command I could run to test if the changes have the desired effect? | 11:35 |
| * LarstiQ stays away from setuptools mostly | 11:35 | |
| ronny | LarstiQ: make a virtualenv and and do an easy_install bzr==1.something within | 11:35 |
| ronny | (using the virtualenvs easy_install) | 11:35 |
| * LarstiQ tries out virtualenv | 11:36 | |
| ronny | virtualenv rocks | 11:36 |
| LarstiQ | I've been meaning to look at it, and zc.buildout | 11:36 |
| ronny | im currently setting up scripts to test anyvc against multiple versions of bzr, hg and subvertpy | 11:36 |
| LarstiQ | right | 11:37 |
| ronny | whats missing is to wire up py.test to aggregate the cobinations of testruns in virtualenvs propperly | 11:38 |
| LarstiQ | ronny: so, `virtualenv test_env; source test_env/bin/activate; deactivate;` to make one, activate and quit again? | 11:41 |
| ronny | LarstiQ: personnaly i would just directly invoke the bin/easy_install of the virtualenv, seems more simple | 11:41 |
| LarstiQ | and now the easy_install fails, cool | 11:41 |
| LarstiQ | ronny: I have no clue :) | 11:42 |
| * LarstiQ digs a bit to see how it works under the hood | 11:42 | |
| LarstiQ | ronny: but at least I can reproduce and test now, thanks! | 11:42 |
| ronny | LarstiQ: if you invoke test_env/bin/easy_install it will just do the right thing | 11:42 |
| * LarstiQ nods | 11:42 | |
| LarstiQ | ronny: I'm a bit leary it won't mess up my system. Of course the point is that it doesn't, but I don't trust setuptools, at all. | 11:43 |
| ronny | LarstiQ: well, you invoke it as user, so it wont rape ya too bad | 11:43 |
| ronny | i hope virtualenv will get pip instead of easy_install soon | 11:43 |
| LarstiQ | ronny: it hasn't grown exploit code yet? ;) | 11:43 |
| LarstiQ | ronny: what's pip? | 11:44 |
| ronny | LarstiQ: a sane python package installer by ian | 11:44 |
| ronny | btw - in general code by pje seems to be made to cause eye-cancer on reading attepts | 11:45 |
| LarstiQ | ronny: a first glance at pip seems much saner | 11:46 |
| ronny | LarstiQ: it is, ian does quite reasonable and pragmatic things | 11:48 |
| LarstiQ | yay ian :) | 11:48 |
| ronny | LarstiQ: how long will fixing the easy_install stuff take? | 11:52 |
| ronny | (ie the getting urls back) | 11:53 |
| LarstiQ | ronny: I don't know, I don't have access. But I'll make work of it. | 11:53 |
| LarstiQ | ronny: do you know if it is possible to include links in http://bazaar-vcs.org/Download that easy_install could find? | 11:54 |
| ronny | i want the easy things off my todo so i dont have any more excuses for the hard things | 11:54 |
| LarstiQ | right | 11:54 |
| LarstiQ | ronny: since the Download page I _can_ change | 11:54 |
| LarstiQ | there seems to be a 'find_links' method at least | 11:55 |
| ronny | LarstiQ: im not sure if there is a way to delegate easy_install to a listing of older releases | 11:55 |
| ronny | else one would require to put all the older links in | 11:56 |
| ronny | and thats too much work to be worth it and probably confusing, too | 11:56 |
| LarstiQ | ronny: I'm trying to get easy_install to accept https://edge.launchpad.net/bzr/+download | 12:02 |
| LarstiQ | ronny: `easy_install -f https://launchpad.net/bzr/+download bzr==1.12 ` seems to work, although it is picking .zip over .tar.gz | 12:03 |
| jelmer | ok, git in working trees works to some degree \o/ | 12:56 |
| jelmer | blegh | 12:56 |
| jelmer | bzr in git working trees I mean | 12:56 |
| Peng_ | Congrats. :) | 12:57 |
| jelmer | only things left to do are commit and ignores | 12:57 |
| jelmer | thanks :-) | 12:57 |
| jelmer | it's still a tad bit slow ('bzr st' in a samba tree takes a few seconds) | 12:57 |
| james_w | nice | 13:02 |
| james_w | thanks jelmer | 13:02 |
| james_w | does it have any idea of things staged in the index? | 13:03 |
| jelmer | yeah, it uses that to see what files are versioned and which aren't | 13:04 |
| jelmer | 'bzr add' will also update the copy that's in the index | 13:05 |
| james_w | cool, that kind of makes sense | 13:06 |
| james_w | bzr would need some extension to be able to interact with it more fully though I guess? | 13:06 |
| jelmer | james_w: yep, and same goes for colocated branches | 13:07 |
| james_w | yeah | 13:07 |
| jelmer | james_w: right now it "feels" to me like it's a native bzr branch except for the fact that it's a bit slower and reports ".git" as an unknown file :-) | 13:08 |
| james_w | heh | 13:08 |
| james_w | that's what I'd like, so it sounds great | 13:08 |
| jelmer | james_w: btw, I've been meaning to ask you | 13:08 |
| jelmer | james_w: how do you cope with parallel imports for UDD? | 13:09 |
| james_w | would adding ".git" to the runtime ignores thing make sense? | 13:09 |
| james_w | we tend to ignore it | 13:09 |
| james_w | however, as we import most things we re-use file ids, so it tends to not be such a problem | 13:09 |
| james_w | I also want to make it use Aaron's rename detection to improve that some | 13:09 |
| jelmer | james_w: that doesn't work if you have e.g. an upstream that is in bzr though? | 13:10 |
| jelmer | james_w: bzr relies on the fact that control directories are called '.bzr' in some places at the moment, I'd like to get rid of that | 13:11 |
| james_w | ah, so you just make it see .git as the control directory | 13:11 |
| james_w | that makes sense | 13:11 |
| james_w | and you are right, it doesn't work when you have upstream in bzr | 13:12 |
| james_w | when we get to a point where that will be an issue on the large scale then hopefully bzr will have the parallel imports case better addressed | 13:12 |
| jelmer | james_w: Ah, ok | 13:14 |
| jelmer | james_w: Perhaps this would be something useful to discuss during the sprint | 13:14 |
| james_w | yeah | 13:14 |
| james_w | at the recent sprint I learned what path tokens are, and they made sense to me | 13:15 |
| jelmer | they're still magic to me | 13:15 |
| james_w | I've no idea how to make them performant though | 13:17 |
| jelmer | do you know how well Aaron's rename detection performs? | 13:21 |
| james_w | pretty good as I understand it | 13:22 |
| james_w | he tested by doing something like comparing bzr.dev with 1000 revisions back and it got 100% | 13:22 |
| jelmer | but in terms of speed? | 13:23 |
| jelmer | bzr-git doesn't support renames at the moment and rename detection is the only option I have | 13:23 |
| james_w | ah | 13:23 |
| james_w | not sure | 13:23 |
| jelmer | mwhudson: hi | 13:23 |
| james_w | it's an edge match of every added file against every removed file I guess | 13:24 |
| james_w | perhaps with some shortcuts | 13:24 |
| james_w | I think that wouldn't be too slow | 13:24 |
| jelmer | Perhaps at the point somebody renames a top-level directory | 13:25 |
| jelmer | with 1000s of files under it | 13:26 |
| jelmer | (at that point git gives up on renames) | 13:26 |
| james_w | yeah | 13:27 |
| james_w | adding path based detection first would be good I think | 13:27 |
| james_w | should handle that case well, and be quicker than detecting each individual rename | 13:28 |
| jelmer | yeah, that'd make sense | 13:28 |
| gioele | hello | 13:39 |
| gioele | How come bzr 1.13.2 is packaged in PPA as bzr-1.13-2. Doesn't that version number mean bzr 1.13(.0), re-packaged for the second time? | 13:41 |
| beuno | ah | 13:41 |
| beuno | see | 13:41 |
| beuno | that's why people aren't getting updates | 13:41 |
| beuno | gioele, you're right | 13:41 |
| gioele | can I complain about the lack of a 1.14 bzr package in PPA or is it too early? :) | 13:48 |
| beuno | gioele, I think it's in a different PPA | 13:51 |
| beuno | gioele, https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa | 13:52 |
| LarstiQ | gioele: personally, I would be fine with publishing it in the main ppa | 13:52 |
| gioele | beuno: I see, but it out of beta now | 13:52 |
| beuno | gioele, I know. But I guess they chose to put 1.13.2 on the release one | 13:52 |
| LarstiQ | gioele: if you can test the one in the beta-ppa, I'm willing to move it to the main one if you vouch for it ;) | 13:53 |
| beuno | I agree though that 1.14 should go there | 13:53 |
| LarstiQ | actually, johnf uploaded it yesterday to the beta ppa | 13:53 |
| gioele | LarstiQ: I doubt I'll change my list of apt repositories ;) | 13:54 |
| LarstiQ | gioele: you can wget one .deb file if you want. But I'll ask johnf what the policy is on moving to the main ppa. | 13:54 |
| gioele | LarstiQ: seriously, I use bzr for stuff I care about. I'm fine using whatever comes from the official releases. But I have no means to "test" a release except running bzr self-test. | 13:57 |
| gioele | basically I just trust you dev that what is in the PPA is safe and tested enough | 13:57 |
| LarstiQ | aww, shucks. | 13:57 |
| * LarstiQ wanted to recruit more testers. | 13:57 | |
| gioele | LarstiQ: if you give me another test suite to test I'll happily test any new bzr. But is there another non-"bzr selftest" test suite? | 13:59 |
| LarstiQ | gioele: the idea with the beta ppa is to have a time of real world usage in addition to the automated tests. | 14:00 |
| gioele | LarstiQ: but how can I test in real world. I see a catch 22 here. My real data is too precious to use it to test bzr. I could use fake data, or older data with fake commands, but that would not be really representative | 14:01 |
| gioele | and anyway, the latter could be automated | 14:01 |
| gioele | people could submit anonymized repositories and you could test on those, maybe with user supplied sequences of commands | 14:03 |
| LarstiQ | gioele: right, that would exclude you from being a beta tester, which is fine. | 14:03 |
| gioele | can someone despam http://bazaar-vcs.org/Talks/KeheduMujipul and http://bazaar-vcs.org/Talks/NedovHobahit?action=Despam | 14:05 |
| gioele | I don't have enough rights to do that | 14:06 |
| lifeless | gioele: its not enabled on that wiki | 14:25 |
| === nevans1 is now known as nevans | ||
| phinze | survey: ideal commit message for a merge? | 15:27 |
| vila | phinze, one that describe succintly while precisely what is being merged | 15:28 |
| phinze | when coming from a task branch it makes sense like "added feature, fixes issue #1234" | 15:29 |
| phinze | but what about merging into a task branch updated code from shared branch | 15:29 |
| phinze | i'm finding myself flipping between "Merged trunk"; "Merging trunk"; "Merged upstream" and the like | 15:29 |
| SamB | "pulling from trunk"? | 15:30 |
| phinze | wondering if i'm being redundant as that data is stored in metadata of the commit | 15:30 |
| SamB | Well, who cares if you're a bit redundant? | 15:30 |
| phinze | and then there's the question of present tense or past tense | 15:30 |
| phinze | true | 15:30 |
| phinze | and i realize this is totally and completely pedantic and overkill | 15:31 |
| phinze | but just wondered if other people think about this stupid stuff too :) | 15:31 |
| SamB | It's easier to see if it's in the commit message, if you're going down reading the commit messages ;-) | 15:31 |
| phinze | true i like to keep --line nice and readable | 15:31 |
| LarstiQ | phinze: 'Merge bzr.dev r1234' | 15:31 |
| SamB | and it's not like you can leave it blank | 15:32 |
| phinze | LarstiQ: yeah that's not bad... | 15:32 |
| LarstiQ | phinze: that's a bit ambiguous, but I think it's clear enough that you merge bzr.dev inclusive. | 15:32 |
| phinze | though it would show up as [merge] Merge bzr.dev... | 15:32 |
| LarstiQ | otherwise I'd word it as 'cherry pick' | 15:32 |
| LarstiQ | phinze: that's display dependant, but if you worry 'Sync up with' ? | 15:33 |
| phinze | LarstiQ: yeah not a huge deal -- just wanting to be succinct but useful | 15:33 |
| * LarstiQ nods | 15:34 | |
| LarstiQ | phinze: have a look at the bzr.dev merging for inspiration, is what I usually do ;) | 15:34 |
| phinze | LarstiQ: hah, not a bad idea -- look to the logs for enlightenment | 15:34 |
| LarstiQ | phinze: that's also how logs will be used often ime, vcs archeology, finding out when and why a change got introduced, etc. | 15:36 |
| LarstiQ | phinze: for merging trunk that usually matters less, but it's good to keep in mind | 15:36 |
| phinze | LarstiQ: yesh my thoughts exactly | 15:37 |
| phinze | LarstiQ: nice phrase too: 'vcs archeology' | 15:37 |
| vila | vcs *is* software archeology | 15:39 |
| === dereine[OFF] is now known as dereine | ||
| LarstiQ | vila: right, there is probably a better term than prefixing with the means | 15:41 |
| vila | LarstiQ: you're right :) | 15:42 |
| LarstiQ | (I just don't like software archeology) | 15:43 |
| ja1 | morning vila | 15:44 |
| === ja1 is now known as jam | ||
| vila | hey jam ! | 15:44 |
| jam | how's it going? | 15:45 |
| jam | I'm still a little under the weather, and probably not up for a phone call. | 15:45 |
| jam | but we can chat here if you want | 15:45 |
| vila | jam: sure, I'm finishing upgrading all my machines to jaunty, the pain being mainly migrating from parallels to virtualbox for my main WS and finding workarounds for silly bugs | 15:47 |
| vila | including synergy not working anymore to share the mouse, the scrollwheel insisting that the right place to be is top left corner of main screen and otherwise the mouse jumping randomly all over the place | 15:48 |
| jam | ooh, sounds fun | 15:49 |
| vila | all of them being of course unheard by google itself | 15:49 |
| vila | well, that was fun the first hour or so :-) | 15:50 |
| jam | vila: In the past I came across an app that would hook into X's handling of your mouse. | 15:50 |
| jam | Such that it could cause the mouse to "drift" | 15:50 |
| jam | and "accelerate" etc | 15:50 |
| jam | So when you stopped moving the physical mouse, the cursor would keep sliding for a bit | 15:50 |
| jam | etc | 15:50 |
| vila | hehe | 15:51 |
| jam | It was a fun gag to play | 15:51 |
| vila | I sort of had that one until I found the work around for synergy :) | 15:51 |
| jam | but I'm sure would be horribly frustrating to use in practice. | 15:51 |
| vila | A funny one to mention too: | 15:51 |
| vila | virtualbox defines rigth-ctrl as the "host" key (to regain control of mouse/keyboard from guest) | 15:52 |
| vila | but since synergy was acting, I used an old sun keyboard at one point *without* a right ctrl key... | 15:52 |
| vila | and of course I realized that during a long blocking operation when the mouse wasn't usable anymore (captured by the guest) :-) | 15:53 |
| vila | oh, and also the scrollwheel bug was specific to one mouse, not the old one I finally found under some dust... | 15:54 |
| vila | oh, one last thing: | 15:56 |
| vila | I finally found the way to work around the buggy virtualbox NAT (that gave me troubles in Brisbane) by... using the one installed by parallels :-) | 15:57 |
| vila | (parallels installs a NAT handling background task at startup unlike vbox which try to handle it without being root and failed in some obscure corner cases...) | 15:58 |
| vila | if ping and nfs can be called obscure that is :) | 15:59 |
| === verterok_ is now known as verterok | ||
| abentley | jam: I want to introduce a new metadir format like development-subtree, except using branch format 8. Should I create a new entry, or just change development-subtree? | 16:04 |
| jam | W%rcR%ft21 | 16:05 |
| jam | oops | 16:05 |
| jam | wrong window, and wrong entry anywy... | 16:05 |
| jam | abentley: I think we need a new format, because otherwise anyone using dev-subtree *today* won't be able to migrate | 16:06 |
| abentley | jam: They ought to be able to do "bzr upgrade --development-subtree" | 16:06 |
| jam | abentley: because the individual objects would still be recognized? | 16:07 |
| abentley | jam: Right. | 16:07 |
| jam | so, IMO, --dev-subtree should be an alias | 16:07 |
| jam | not a concrete format | 16:07 |
| jam | so having it point at something new is fine | 16:08 |
| abentley | jam: Right now, it's not. | 16:08 |
| abentley | There's a comment explaining why that I don't understand. | 16:08 |
| jam | let me check | 16:08 |
| abentley | i.e. "it's not an alias". | 16:09 |
| jam | abentley: so the comment is just that we didn't create a -dev6-subtree to aliase -dev-subtree to | 16:09 |
| jam | so I would suggest... | 16:09 |
| jam | create a --dev6-subtree (or -dev7 | 16:09 |
| jam | and change -dev-subtree to be an actual alias | 16:09 |
| abentley | Okay. | 16:09 |
| abentley | jam: I don't understand why aliases specify their component formats. Seems brittle to me. | 16:10 |
| jam | As for --dev6 / --dev7... I don't really care | 16:10 |
| jam | abentley: I don't fully understand aliases either | 16:10 |
| jam | I guess that aliases are just omitted from the 'info' listing? | 16:11 |
| jam | I certainly would have thought that an alias designation would just copy info from whatever it was aliasing | 16:11 |
| jam | yeah, it seems to do: | 16:12 |
| jam | non_aliases = set(bzrdir.format_registry.keys()) | 16:12 |
| jam | non_aliases.difference_update(bzrdir.format_registry.aliases()) | 16:12 |
| === herb` is now known as herb | ||
| jam | And nobody actually took the time to code up how we would really want to use aliases | 16:12 |
| abentley | jam: Just being able to construct them from the format they alias would be a good start. | 16:14 |
| jam | abentley: like a "Format.create_alias()" function? | 16:14 |
| abentley | jam: I was thinking of FormatRegistry.register_alias() | 16:15 |
| jam | sure | 16:16 |
| abentley | jam: Shouldn't development formats be hidden? | 16:20 |
| jam | I would probably say yes by default, but I don't think there is a way to say "and give me the rest"... | 16:21 |
| intellectronica | so, anybody knows how i make bzr on ubuntu not popup notifications for everything i do. the new notification dialog is nice, but this is a bit too much for my taste | 16:22 |
| jam | intellectronica: well, the brute-force way is to uninstall bzr-gtk | 16:23 |
| jam | Though I believe there *is* a way to just disable it | 16:23 |
| jam | I just don't know it off hand | 16:23 |
| intellectronica | jam: yeah, removing bzr-gtk seems to do the trick. thanks! | 16:24 |
| SKArfaceGC | kfogel: Finally got around to writing a bit on permissions, since you expressed interest http://www.baltdad.com/2009/04/bazaar-part-5-permissions/ nothing earth shattering but it was useful for me. | 16:43 |
| === ja1 is now known as jam | ||
| kfogel | SKArfaceGC: cool! will take a look | 16:44 |
| kfogel | SKArfaceGC: oh, that's more about unix filesystem-level perms. I think I was thinking about client/server access control. | 16:46 |
| kfogel | like, who can branch what from where, who can push what to where, that sort of thing | 16:46 |
| SKArfaceGC | I'm going to hit that next. I've been crushed at work so I haven't had a ton of time to mess with it. | 16:46 |
| SKArfaceGC | I really do want to be able to handle perms at the server level rather than at the fs level. Would simplify some stuff in my env. | 16:47 |
| SKArfaceGC | Though it strikes me that with a decent script and heavy abuse of /etc/groups I may be able to simulate some of the detailed control I want. Just seems, well, a bit too hackish. | 16:48 |
| matio | bazaar is written in python isn't it | 16:48 |
| matio | ? | 16:48 |
| jelmer | matio: yes | 16:49 |
| kfogel | SKArfaceGC: yeah, I think doing access control via fs-level perms is not the wave of the future :)-. | 16:50 |
| kfogel | oops | 16:50 |
| kfogel | :-) | 16:50 |
| matio | does the project need any help (that would be quite easy), I want to help open-source projects that use python | 16:50 |
| jelmer | matio: yeah, there's always more things to do | 16:51 |
| jelmer | matio: A good start is looking for the bugs tagged "easy" in the bug tracker | 16:51 |
| matio | what could I help with? (thanks 4 reply) | 16:51 |
| jelmer | matio: see https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=easy | 16:53 |
| SKArfaceGC | are there any plugins for the smart server that deal with permissions already? | 16:54 |
| matio | thjelmer: thanks, I was just looking at the blueprints for bazaar! | 16:54 |
| LarstiQ | matio: easy, or trivial | 17:02 |
| LarstiQ | matio: (which is then https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=trivial of course) | 17:03 |
| === dereine is now known as dereine[OFF] | ||
| matio | im not sure where i would start | 17:14 |
| LarstiQ | matio: you could start by finding the patch mentioned in https://bugs.edge.launchpad.net/bzr/+bug/239523 , apply it, and see if that fixes the problem or not. | 17:17 |
| ubottu | Launchpad bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed] | 17:18 |
| LarstiQ | matio: if it doesn't fix the problem, it needs to be improved. If it _does_ fix the problem, it needs to be merged to bzr.dev | 17:18 |
| LarstiQ | matio: in which case you'd need to find out why it isn't merged yet, possibly take care of points raised during review, get another review done, etc | 17:18 |
| LarstiQ | matio: does that help? | 17:19 |
| matio | LarstiQ: yes, thanks | 17:20 |
| LarstiQ | matio: http://bundlebuggy.aaronbentley.com/project/bzr/request might be of help for finding the patch. If not, it should be in the mailing list archives. | 17:21 |
| LarstiQ | matio: http://doc.bazaar-vcs.org/latest/developers/index.html might also come in handy | 17:22 |
| matio | LarstiQ: thanks for your help | 17:24 |
| jelmer | jam: ping | 17:54 |
| jelmer | jam: The parent keys specified to add_lines(), should that be a list or a tuple? | 17:54 |
| jelmer | It seems like groupcompress bails out it if is a list and the other code bails out if it is a tuple | 17:55 |
| jam | jelmer: individual keys must be a tuple, IIRC, but the overall group of parents should probably be either | 17:55 |
| jam | Are you doing [(parent_1,), (parent2,)] ? | 17:55 |
| jam | or (parent1, parent2) | 17:55 |
| jam | Or ((parent1,), (parent2,)) | 17:56 |
| jam | the middle one is wrong | 17:56 |
| jam | for sure | 17:56 |
| jam | the first and third should be correct | 17:56 |
| jam | (I *think*) | 17:56 |
| jelmer | I'm doing the first but that triggers a test in add_lines() that makes sure the parents of a text don't change | 17:56 |
| jelmer | bzrlib/groupcompress.py:1601 | 17:57 |
| jelmer | if the present nodes have a different type than what I'm specifying it raises the assertion | 17:58 |
| jelmer | (Pdb) print keys[key][1] | 17:58 |
| jelmer | ([('36620@8da58560-a4e7-4996-a0c2-a735b94b261c:trunk%2Fautodoc%2Fsource%2Fparser%2Fkernel%2Fx_parse.cxx', 'svn-v4:8da58560-a4e7-4996-a0c2-a735b94b261c:trunk:121227')],) | 17:58 |
| jelmer | (Pdb) print node_refs | 17:58 |
| jelmer | ((('36620@8da58560-a4e7-4996-a0c2-a735b94b261c:trunk%2Fautodoc%2Fsource%2Fparser%2Fkernel%2Fx_parse.cxx', 'svn-v4:8da58560-a4e7-4996-a0c2-a735b94b261c:trunk:121227'),),) | 17:58 |
| jam | jelmer: so where does it fail if it is a tuple? (#3) | 18:00 |
| jelmer | and afaik I changed to using [] in the first place because another part of the code required that | 18:00 |
| jelmer | s/afaik/iirc/ | 18:00 |
| jelmer | I think the dupe check code of knits | 18:01 |
| jam | so failing because it is a list vs tuple doesn't seem valuable at that point | 18:02 |
| jam | I would have thought _get_entries() would always return tuples at this point | 18:02 |
| jam | but certainly it could have returned either at different times | 18:02 |
| jelmer | ok, tuples it is | 18:03 |
| jam | jelmer: either way, I wouldn't mind if the check was updated to cast them specifically | 18:12 |
| jam | since I don't think we care about the time of the container at that point | 18:12 |
| SKArfaceGC | where is documentation for a project on launchpad normally kept? Blueprints/Answers/Overview do not seem to be the place to look. | 18:38 |
| LarstiQ | ronny: https://lists.ubuntu.com/archives/bazaar/2009q2/057805.html | 19:08 |
| jfroy | jelmer: updated 364416 with the NoSuchRevision backtrace | 19:10 |
| jelmer | jfroy: is this a repo with mixed svn-v3 / svn-v4 revisions ? | 19:15 |
| jfroy | yeah | 19:15 |
| beuno | SKArfaceGC, there is no such place, for now | 19:15 |
| === abentley1 is now known as abentley | ||
| ronny | LarstiQ: thanks | 20:07 |
| LarstiQ | ronny: thanks for getting me finally to start with virtualenv :) | 20:09 |
| ronny | LarstiQ: np, always happy to beat people with cool things | 20:11 |
| LarstiQ | hihi | 20:12 |
| mwhudson | jelmer: hello | 20:12 |
| abentley | jam: Do you have a minute to chat? I need some advice on nested pull. | 20:24 |
| === nevans1 is now known as nevans | ||
| jelmer | mwhudson: hi! | 20:35 |
| BasicOSX | Who would have thought RMS had a sense of humor. Sent myself and mbp "condolences" for the 1.13.2 release :-) | 20:36 |
| beuno | BasicOSX, HI! | 20:36 |
| beuno | what do you think of updating the release PPA with 1.14? | 20:37 |
| beuno | instead of 1.13.2? :) | 20:37 |
| BasicOSX | beuno: I don't do the PPA part, just source tar/zip, but I think it's a great idea :-) | 20:37 |
| beuno | BasicOSX, oh? now I have to find someone else to bug! | 20:38 |
| LarstiQ | beuno: I've sent johnf (who does the ppa bits for bzr) a mail about that. | 20:38 |
| beuno | LarstiQ, thanks :) | 20:39 |
| LarstiQ | beuno: he's in the .au/.nz timezone afaik | 20:39 |
| beuno | we should also get an SRU for Jaunty | 20:39 |
| jelmer | beuno: did 1.14 end up in Jaunty? | 20:40 |
| beuno | jelmer, no :( | 20:41 |
| beuno | 1.13 | 20:41 |
| jelmer | ah, good | 20:43 |
| jelmer | otherwise we'd have heaps of broken plugins there.. | 20:43 |
| beuno | jelmer, well, now we have heeps of broken branches... :) | 20:43 |
| abentley | beuno: Do you mean the stacking issues or the new formats? | 20:49 |
| beuno | abentley, stacking | 20:49 |
| abentley | beuno: AIUI, we're putting bzr 1.13.2 into jaunty-updates. | 20:50 |
| beuno | abentley, has someone filed that? | 20:50 |
| beuno | that would be lovely :) | 20:50 |
| abentley | beuno: Ask spiv | 20:51 |
| * beuno looks at spiv | 20:52 | |
| jelmer | mwhudson: is that etckeeper mirror still visible somewhere? | 20:53 |
| mwhudson | jelmer: o | 20:59 |
| mwhudson | o | 20:59 |
| mwhudson | aargh! | 20:59 |
| mwhudson | no! | 21:00 |
| mwhudson | jelmer: the usual staging effect | 21:00 |
| mwhudson | jelmer: but the import took like 10 seconds | 21:00 |
| jelmer | mwhudson: that sounds about right | 21:02 |
| jelmer | mwhudson: speaking of 10 seconds.. launchpad-bazaar seems to be choking on openoffice | 21:02 |
| jelmer | https://edge.launchpad.net/~jelmer/openoffice/hosted | 21:02 |
| mwhudson | jelmer: gosh | 21:02 |
| mwhudson | jelmer: that mean 15 minutes without a progress report :/ | 21:03 |
| * mwhudson goes to look at the codehost's disk space graph | 21:04 | |
| jelmer | yeah, it's large | 21:10 |
| jelmer | about 200k revs at this point | 21:10 |
| jelmer | mwhudson: any idea? | 21:23 |
| mwhudson | jelmer: probably getting a LOSA to do the initial pull by hand | 21:23 |
| mwhudson | jelmer: unless you want to fix bzr's progress reporting? | 21:23 |
| === dereine[OFF] is now known as dereine | ||
| jelmer | mwhudson: there's lots of things I want to do | 21:32 |
| mwhudson | jelmer: i know that feelig | 21:32 |
| mwhudson | jelmer: i'll get spm to kick it when he starts work | 21:33 |
| jelmer | so this is just because bzr doesn't give any output, in which case lp assumes it's stalled? | 21:34 |
| mwhudson | right | 21:34 |
| mwhudson | we hook into the progress bar machinery | 21:34 |
| LarstiQ | calling bzr via bzrlib.. ah | 21:34 |
| LarstiQ | mwhudson: what version of bzr is that with? | 21:34 |
| mwhudson | (useful for mirrored branches really, the mirror puller sometimes got stuck for daaaays) | 21:35 |
| mwhudson | LarstiQ: 1.14rc2 | 21:35 |
| LarstiQ | mwhudson: and the progress isn't sufficient? Hmmm. | 21:35 |
| mwhudson | jelmer: what format is the branch? | 21:35 |
| LarstiQ | for being alive I'd expect the transport progress to really have helped. | 21:35 |
| mwhudson | jelmer: if i have bzr-git in ~/repos/bzr-git/trunk how can i run the tests? | 21:36 |
| mwhudson | jelmer: symlink from ~/.bazaar/plugins/gtk, bzr selftest git ? | 21:36 |
| mwhudson | LarstiQ: don't think the localtransport participates in that? | 21:36 |
| LarstiQ | mwhudson: oooh, fair enough | 21:37 |
| LarstiQ | yeah, that sucks | 21:37 |
| jelmer | mwhudson: development6 | 21:39 |
| jelmer | mwhudson: "make check" in the bzr-git directory should do it | 21:39 |
| jelmer | mwhudson: but what you suggested should work too | 21:39 |
| mwhudson | jelmer: oh right | 21:41 |
| mwhudson | hmm | 21:42 |
| mwhudson | ProgrammingError: You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. | 21:42 |
| mwhudson | jelmer: sqlite version fun or something? | 21:42 |
| jelmer | mwhudson: do you have bzr-git 0.2.1? | 21:42 |
| mwhudson | jelmer: bzr-git trunk | 21:43 |
| mwhudson | i guess i should branch the tag | 21:43 |
| mwhudson | and hey, maybe lp isn't up to date | 21:43 |
| mwhudson | ah, it's a hosted branch | 21:44 |
| ronny | LarstiQ: btw, http://moinmo.in/SectionParser might be something to help with making things invisible | 21:44 |
| mwhudson | jelmer: happens with tag:bzr-git-0.2.1 too | 21:45 |
| LarstiQ | ronny: that seems like it should work, thanks | 21:46 |
| jelmer | mwhudson: sorry, it looks like I forgot to actually merge my python2.4 fixes for bzr-git | 21:48 |
| kirkland | so i found the color coding pretty cool, interesting in 'bzr shelve' ... is there any way to get bzr diff to work the same way, color coded and in a pager (besides dumping to file and opening in vim?) | 21:49 |
| jelmer | mwhudson: Is it ok if I just push or would you rather see a 0.2.2? | 21:49 |
| ronny | LarstiQ: {{{#!wiki comment | 21:49 |
| mwhudson | jelmer: this happens with python2.6 too | 21:49 |
| LarstiQ | kirkland: that happens because you have bzrtools installed, which also provides cdiff | 21:49 |
| mwhudson | jelmer: a tag would be nice, no need to bother with a release | 21:49 |
| LarstiQ | kirkland: pager/vim wise, I usually | vim - | 21:49 |
| LarstiQ | ronny: that being standard supported? | 21:50 |
| mwhudson | kirkland: also less -R works | 21:50 |
| * LarstiQ falls asleep, ciao | 21:51 | |
| kirkland | thanks guys | 21:51 |
| luks | bzr-pages can do that automatically for you | 21:51 |
| luks | *bzr-pager | 21:51 |
| ronny | LarstiQ: yes, im not sure since what version tho | 21:52 |
| jelmer | mwhudson: pushed, tagged as bzr-git-0.2.1a | 21:54 |
| mwhudson | jelmer: ta | 21:54 |
| mwhudson | oh wow, bzr tags -r branch:lp:bzr-git goes bang in a spectacular way | 21:56 |
| mwhudson | ReadOnlyError: A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mwh/canonical/repos/bzr-git/release-0.2.1/.bzr/branch/) | 21:56 |
| === dereine is now known as dereine[OFF] | ||
| mwhudson | i guess i should file a bug or something | 21:56 |
| mwhudson | jelmer: pushed where? | 21:58 |
| jelmer | lp:~bzr/bzr-git/trunk | 21:58 |
| mwhudson | jelmer: really? | 22:02 |
| === welten is now known as welterde | ||
| mwhudson | oh wow, yes, really | 22:02 |
| mwhudson | jelmer: thanks happier now | 22:03 |
| jelmer | cool | 22:03 |
| * mwhudson just experienced svn's conflict handling for the first time in a few years | 22:04 | |
| mwhudson | it's .... different ow | 22:04 |
| mwhudson | now | 22:04 |
| jelmer | yeah, it's been improved | 22:04 |
| mwhudson | svn resolve --accept working <file> is pretty awkward though | 22:05 |
| mwhudson | and i don't really want to be asked questions during 'up' | 22:05 |
| mwhudson | ah well | 22:05 |
| === weltende is now known as welterde | ||
| jelmer | mwhudson: what are you using svn for anyway now that you have bzr-svn ? >-) | 22:05 |
| mwhudson | jelmer: it's codespeak :) | 22:05 |
| jelmer | ahh :-) | 22:06 |
| mwhudson | speaking of which, i have a repo dump here... | 22:06 |
| enigma | jelmer: I'm having a strange bzr-svn error when you have a second. bzr: ERROR: exceptions.AttributeError: 'SubversionPushResult' object has no attribute 'old_revno' | 22:06 |
| enigma | jelmer: "bzr missing" and "bzr pull" work just fine. It's just "bzr push" that has issues. | 22:07 |
| jelmer | enigma: with which version? | 22:08 |
| enigma | bzr-svn 0.5.4 with bzr 1.14 | 22:08 |
| mwhudson | jelmer: while you're here, python 2.4, bzr 1.14, subvertpy 0.6.5 and bzr-svn 0.5.4 should all get along reasonably happily? | 22:14 |
| jelmer | mwhudson: yes | 22:14 |
| mwhudson | jelmer: cool | 22:17 |
| mwhudson | jelmer: i'll be asking you a similar question in a month, i guess :) | 22:17 |
| * mwhudson stabs combinator | 22:17 | |
| mwhudson | uh! | 22:18 |
| mwhudson | the subvertpy tests just segfaulted on me | 22:18 |
| jelmer | uh? | 22:19 |
| mwhudson | jelmer: subvertpy.tests.test_client.TestClient.test_get_config segfaults for me | 22:19 |
| mwhudson | with python 2.4, 2.5 and 2.6 | 22:19 |
| mwhudson | on jaunty | 22:19 |
| jelmer | mwhudson: subvertpy tip? | 22:19 |
| mwhudson | jelmer: release-0.6.5 | 22:19 |
| jelmer | mwhudson: That one is actually fixed since 0.6.5 | 22:20 |
| * jelmer should probably release 0.6.6 | 22:20 | |
| mwhudson | jelmer: yes, trunk seems happier | 22:21 |
| mwhudson | apart from subvertpy.tests.test_properties.TestProperties.test_time_from_cstring | 22:21 |
| mwhudson | self.assertEquals(1225704780716938L, properties.time_from_cstring("2008-11-03T09:33:00.716938Z")) | 22:21 |
| mwhudson | exceptions.AssertionError: 1225704780716938L != 1225701180716938L | 22:21 |
| jelmer | mwhudson: export TZ=CET ;-) | 22:22 |
| jelmer | but yeah, that's a bug too | 22:22 |
| mwhudson | jelmer: ehhh | 22:22 |
| mwhudson | a bug in the tests, or in subertpy? | 22:23 |
| jelmer | mwhudson: that's a bug in the tests | 22:23 |
| mwhudson | ok | 22:23 |
| mwhudson | jelmer: i get this sort of thing when i try to run bzr-svn tests with python2.4 http://pastebin.ubuntu.com/161709/ | 22:26 |
| mwhudson | jelmer: does that make any sense to you? | 22:27 |
| mwhudson | ah, the message is actually | 22:28 |
| mwhudson | ImportError: subvertpy/client.so: undefined symbol: Py_InitModule4_64 | 22:28 |
| mwhudson | oh i see, i wasn't actually running the tests with trial | 22:29 |
| mwhudson | jelmer: subvertpy doesn't actually seem to work with python2.4 | 22:31 |
| jelmer | mwhudson: Tests seem to work fine here | 22:34 |
| jelmer | mwhudson: did you rebuild for python2.4? | 22:34 |
| mwhudson | jelmer: yes | 22:42 |
| mwhudson | at least, i tried :) | 22:42 |
| jelmer | mwhudson: what exactly doesn't work? | 22:43 |
| mwhudson | jelmer: importing the extensions | 22:44 |
| mwhudson | hang on, three conversations at once going on here :) | 22:44 |
| poolie | hello all | 22:56 |
| jelmer | hey poolie | 22:57 |
| poolie | i'm home again, yay | 22:57 |
| mwhudson | jelmer: spm is pulling your oo branch by hand now | 22:57 |
| spm | poolie: just in time for friday too! excellent timing! :-) | 22:57 |
| mwhudson | jelmer: ok, python2.4 seems to be working now | 22:59 |
| jelmer | mwhudson: cool - any source code changes necessary? | 23:01 |
| mwhudson | jelmer: are you going to release a new subvertpy, or should i just use tip? | 23:01 |
| mwhudson | jelmer: no | 23:01 |
| mwhudson | jelmer: although you might want to fix the business about the error message when extensions fail to import | 23:02 |
| sidnei | yo poolie! | 23:02 |
| poolie | hello sidnei | 23:04 |
| jelmer | mwhudson: if possible please just use the tip | 23:04 |
| jelmer | mwhudson: I'd like to fix the timezone issue as well in 0.6.6 | 23:04 |
| mwhudson | jelmer: ok | 23:04 |
| sidnei | poolie: im making good progress here. too bad it takes a hundred years to branch bzr on my connection :) | 23:04 |
| mwhudson | (we're not actually using subvertpy/bzr-svn yet, but i would like to get a mutually compatible set of stuff in our tree) | 23:04 |
| mwhudson | jelmer: argh, the bzr-svn tests segfaulted | 23:06 |
| * jelmer thinks mwhudson has some bad karma | 23:07 | |
| jelmer | mwhudson: bzr-svn 0.5.4, subvertpy tip, bzr 1.14 ? | 23:08 |
| mwhudson | jelmer: python 2.4, jaunty | 23:08 |
| mwhudson | jelmer: pastebin will follow in a sec, on a call now | 23:08 |
| === dereine[OFF] is now known as dereine | ||
| mwhudson | jelmer: it's bzrlib.plugins.svn.tests.test_workingtree.TestWorkingTree.test_get_ignore_list_morelevel that segfaults | 23:13 |
| lifeless | hi poolie | 23:16 |
| poolie | hi lifeless | 23:17 |
| poolie | i'm back, as you see | 23:17 |
| poolie | i'll answer your mail about news from london | 23:17 |
| poolie | i have a cold (hopefully not swine flu!) | 23:18 |
| jelmer | mwhudson: do you have a gdb backtrace? | 23:20 |
| fullermd | I have a solution to swine flu. It involves eating a whole lot of bacon. Who's with me? | 23:20 |
| lifeless | fullermd: :) | 23:20 |
| lifeless | fullermd: bacon explosion! | 23:20 |
| mwhudson | jelmer: no | 23:20 |
| jelmer | mwhudson: I'm really not sure what could cause this, nobody has reported a segfault in months | 23:21 |
| mwhudson | jelmer: on the phone, one sec | 23:21 |
| mwhudson | jelmer: http://pastebin.ubuntu.com/161741/ | 23:25 |
| jelmer | mwhudson: are you getting an actual segfault or an assertion? which svn version? | 23:30 |
| mwhudson | jelmer: segfault | 23:35 |
| mwhudson | 1.5.4dfsg1-1ubuntu3~launchpad0 | 23:35 |
| mwhudson | hmm | 23:35 |
| mwhudson | that ~launchpad0 is a bit suspicious :) | 23:35 |
| lifeless | mwhudson: probably a nochange rebuild for 2.4 | 23:36 |
| mwhudson | i hope so | 23:36 |
| sidnei | lifeless, poolie: any idea where TortoiseOverlays can be found? the build instructions are broken where the link should be: http://bazaar-vcs.org/BzrWin32Installer | 23:38 |
| lifeless | sidnei: no idea :( | 23:39 |
| tyhicks | Question from a git user: It seems like bzr repositories are made up of branches that are contained in subdirectories. In git, I tend to like that I can checkout a branch (with git-checkout) and not cd into a subdirectory. | 23:40 |
| tyhicks | Am I missing something with bzr repos or will I just have to live with it? :) | 23:40 |
| mwhudson | tyhicks: there has been vigorous debate about this :) | 23:41 |
| mwhudson | tyhicks: one thing you can do in bzr is separate your trees from your branches and repository | 23:41 |
| lifeless | tyhicks: you can create a checkout and use switch to switch between branches | 23:41 |
| tyhicks | mwhudson: Ahh... I didn't mean to fuel the fire | 23:41 |
| mwhudson | so you can have a repo in say ~/repos/project | 23:42 |
| mwhudson | and branches ~/repos/project/trunk ~/repos/project/feature-X | 23:42 |
| mwhudson | and then a checkout in ~/checkouts/project | 23:42 |
| mwhudson | then in ~/checkouts/project you can say "bzr switch trunk", "bzr switch feature-X" | 23:42 |
| mwhudson | tyhicks: no worries, just wanted to say that you're not the first to ask this question :) | 23:43 |
| tyhicks | mwhudson: I didn't know about bzr switch. I think that will work for me. | 23:43 |
| tyhicks | mwhudson: Thanks! | 23:43 |
| sidnei | alright, gotta go. have a good weekend all! | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!