| lifeless | we can look at making a very slow spin | 00:00 |
|---|---|---|
| lifeless | its a fascinating bug | 00:01 |
| Noldorin | heh, you could say that, yeah. | 00:01 |
| Noldorin | hmm | 00:02 |
| Noldorin | the thing is, i'm not sure if it's unique to my ftp server, or somewhat more common | 00:02 |
| Noldorin | on windows ftp servers in general | 00:02 |
| Noldorin | would be interesting to see if it persists when the server gets upgraded to win 2008 | 00:02 |
| lifeless | first tinme we've seen it | 00:06 |
| lifeless | we've seen other IIS6 related issues | 00:06 |
| Noldorin | mm | 00:06 |
| Noldorin | though i wouldn't be surprised if others encountered it but didn't have the effort to pursue the problem | 00:06 |
| Noldorin | it certainly hasn't been a straightforward one :P | 00:06 |
| lifeless | hard to know | 00:07 |
| Noldorin | yeah | 00:08 |
| BasicOSX | How to I convert a branch to the new 2.0dev format? | 00:39 |
| lifeless | BasicOSX: there's an upgrade guide | 00:45 |
| lifeless | BasicOSX: but in short, if you have no stacked branches its just 'bzr check; bzr upgrade --2a' | 00:45 |
| lifeless | and to upgrade a remote branch just add the url to both those commands | 00:47 |
| BasicOSX | lifeless: got url to migration/upgrade guide? I've been away almost 1 month so I got a lot of reading to do to catch up :-) | 00:52 |
| lifeless | docs.b.o | 00:53 |
| lifeless | uhm, 1.18 added it, and its in .dev too obviously :) | 00:53 |
| BasicOSX | heh, maybe I should bzr update | 00:54 |
| === bialix_ is now known as bialix | ||
| floam | does anybody know if any of [bzr, hg, git] set the mtimes of the files in the working tree to the last time a file was updated? | 07:54 |
| fullermd | I'm pretty sure none of them do. That would have bad knockon effects with e.g. make. | 08:02 |
| floam | knockon? | 08:05 |
| lifeless | floam: consequences | 08:06 |
| fullermd | As bzr goes, it handwavingly seems like a relatively simple plugin to write, to at least give a command to set them. | 08:07 |
| lifeless | there is a bug open | 08:07 |
| fullermd | It would probably be very hard (read: impractical) to try and hook it into everywhere that files get written, though... | 08:08 |
| floam | I'm having a hard time imagining the effects, but I'll trust you. | 08:08 |
| lifeless | you can do something with care that won't break make and will give some idea about times. | 08:08 |
| fullermd | (as a plugin that is) | 08:08 |
| floam | seems no different than having my mtimes set in a tarball of a release. | 08:08 |
| lifeless | floam: things not building that should, and things building that shouldn't. | 08:08 |
| lifeless | floam: tarballs are immutable :) | 08:08 |
| fullermd | Yah. You don't often blat a tarball over an existing dir with .o files. With VCS's, flinging files around is the norm. | 08:08 |
| fullermd | You don't even have to postulate different versions. Imagine I edit a .c file, build, decide it was crap, and use 'bzr revert' to throw it away. | 08:10 |
| fullermd | If revert reset the mtime back to the last commit, the [broken] .o file would be considered up to date by a system (like make) that relies on timestamps. | 08:10 |
| floam | ok, good point. | 08:10 |
| fullermd | (of course, this is one reason I'm designing for more flexibility in my make replacement. Watch out for it in, like, 30 years when I catch up on free time ;) | 08:11 |
| floam | I should probably just not let my code care about files' mtimes, as much as I want to. | 08:11 |
| floam | I keep my website in version control, and my little python cms+blog stores blog entries as plain text files in markdown, and I use the mtime for the "posted" date. | 08:11 |
| fullermd | Funnily enough, I just had a VCS/mtime discussion elsewhere yesterday. Silly coincidences... | 08:11 |
| lifeless | fullermd: you too huh | 08:11 |
| lifeless | [build tools] | 08:12 |
| fullermd | Well, I have my website under version control, and I use $Date$ keywords for Last Updated. 'course, that's one reason it's still in CVS... | 08:12 |
| fullermd | lifeless: Yah. You won't like mine, though 8-} | 08:12 |
| floam | fullermd: yeah, that was my next quesiton. "which modern VCSs have $Date$?" | 08:13 |
| floam | but I really wouldn't want to rely on a certain VCS for my code. | 08:14 |
| fullermd | I think I heard that hg has a plugin or something for it. | 08:14 |
| floam | might as well be shelling out to bzr to find out then. | 08:14 |
| fullermd | bzr will ("does" FSVO, but it's too buggy to be useful ATM) | 08:14 |
| lifeless | fullermd: if you stop writing in perl I might ;) | 08:14 |
| lifeless | floam: bzr can do $Date via filters; hg too, and git as well. | 08:15 |
| fullermd | I figure if I go slow enough, it'll be in p6 by the time it's finished... | 08:15 |
| floam | wonder if bzr preserves xattrs.. | 08:15 |
| lifeless | fullermd: parrot is fun. They use my code ;) | 08:15 |
| fullermd | I actually DID considering trying to use PIR or some layer in parrot for it instead... | 08:16 |
| fullermd | But doing it in perl saves me having to do all that language implementation stuff. Laziness FTW. | 08:16 |
| floam | anyways, re: breaking things: what about ctimes? | 08:18 |
| fullermd | You mean recording the mtime from the commit timestamp into the ctime field as an end-run? | 08:19 |
| fullermd | I guess you COULD do it, but that would be a pretty wacky hackaround; any app you'd care about the mtime you'd have to rework to look at the ctime field instead. | 08:19 |
| floam | don't think so, I think I mean preserving the actual ctime. | 08:20 |
| floam | or when it was added to version control. | 08:20 |
| fullermd | Mmm. ctime is rarely going to tell you anything meaningful... | 08:20 |
| floam | yeah, except for my actual usecase of blog-posts-as-files, where the creation time is the actual pertinent thing. | 08:21 |
| fullermd | But ctime isn't creation time. It's inode-change time. | 08:21 |
| floam | know if any of the VCSs out there preserve it? | 08:21 |
| floam | oh? | 08:21 |
| floam | didn't know that. | 08:21 |
| fullermd | Yah. A lot of people don't, 'cuz it's so convenient to expand as 'creation', and creation is one of the major things that touches it :) | 08:22 |
| fullermd | But it's not the only. | 08:22 |
| floam | so nautilus, os x's finder's Created: fields would have to be absolutely useless | 08:22 |
| fullermd | chmod, for instance, is an inode change, so it updates the ctime. | 08:22 |
| lifeless | ctime changes on chmod/link; mtime changes on write/trunc | 08:24 |
| fullermd | At least some fsen also store an inode birth time, which could populate a Created: field with at least technical correctness. | 08:25 |
| fullermd | Of course, any form of 'editing' that uses rename() to atomically update the file means Created isn't necessarily what you think of it as either. | 08:26 |
| fullermd | For instance, I made a file, did a chmod to change the ctime, then cat'd it to change the atime. | 08:26 |
| floam | hm, I bet OS X is being sneaky and using some sort of xattr or resource fork or HFS trick to get these creation times displayed in Finder that aren't being affected by chmods. | 08:26 |
| fullermd | % stat -f'%a %m %c %B' y | 08:27 |
| fullermd | 1250925980 1250925730 1250925786 1250925730 | 08:27 |
| fullermd | The birth and modified times are the same (since I never modified it), but the change time corresponds to the chmod, and the access to the cat. | 08:27 |
| fullermd | I don't know how portable birthtimes are. amc at least you can fairly count on on POSIX filesystems. | 08:27 |
| floam | ah | 08:29 |
| floam | st_birthtime. | 08:29 |
| floam | anyways, I'm just going to add some metadata to my files and set them by hand, I think. thanks for the help. | 08:31 |
| fullermd | lifeless: BTW, is the paucity of progressbar updates on 'check' a known blip? | 08:36 |
| * fullermd can't remember if it was mentioned. | 08:37 | |
| lifeless | fullermd: no, I made it update better if anythinh | 08:37 |
| lifeless | rather than 5 bars going 0 to full :P | 08:37 |
| fullermd | I ran a check on my bzr.dev repo (~25 minutes), and for at least 5 minutes (all I really watched), even the spinner was frozen. | 08:37 |
| fullermd | ('course, I'd forgotten about that TREE_ROOT thing, so I don't actually know whether check found any real errors in the repo...) | 08:43 |
| === vxnick_ is now known as vxnick | ||
| NEBAP | is it possible to tell bazaar that I´ve moved a file after I moved it? | 15:16 |
| NEBAP | e. g. I have a file file1.ext and now create a folder files and move the file to it, so before: file1.ext after: files/file1.ext | 15:17 |
| NEBAP | how can I tell bazaar that I´ve moved the file? | 15:17 |
| fullermd | bzr mv file1.ext files/ should notice it's already done and note it down for bzr I thin. | 15:24 |
| fullermd | And think, too. | 15:24 |
| NEBAP | thanks I´ve found it: bzr mv file1.ext DAL/file1.ext --after | 15:33 |
| vila | denys: ping | 16:53 |
| vila | denys: don't waste your energy about leaked threads, the problem is known and selftest will even report about them (when it can finish that is), so if you're blocked on gentoo because of that, just try running less tests (with -s) or have a look at my patch for --parallel=fork that will reduce the number of tests run by each subprocess | 16:55 |
| denys | vila: sorry, was away from keyboard. is the problem unfixable? | 17:24 |
| vila | denys: of course not :-) But it's not trivial, see my comment on the bug report for more details and some work-arounds | 17:25 |
| vila | We never had crashes until recently so the priority was low. | 17:26 |
| vila | I'm sorry I didn't see your report earlier, understanding where the threads are coming is really tricky :-/ I hope you enjoyed the trip though :D | 17:27 |
| vila | denys: I'm setting up a gentoo VM right now to be able to reproduce the problem, but it's the week-end and my family may require me, so... | 17:28 |
| denys | ;-) | 17:28 |
| denys | I am the sort of guys who like fixes rather than workarounds. this problem bugs me (literally and figuratively) | 17:30 |
| vila | denys: oh ! By the way, I'm pretty surprised that you even encounter the prolem, so may be you can try to understand gentoo appears to have a lower number of threads that Ubuntu, OSX, Debian, xBSD, etc | 17:30 |
| vila | :) | 17:30 |
| vila | windows... I can understand because the overall OS model is different, but gentoo... | 17:32 |
| denys | hmm: | 17:37 |
| denys | cat /proc/sys/kernel/threads-max | 17:37 |
| denys | 114637 | 17:37 |
| vila | cat /proc/sys/kernel/threads-max | 17:39 |
| vila | 24575 | 17:39 |
| vila | denys: try harder :) | 17:39 |
| denys | that's what I mean. it's not a problem of threads-max | 17:40 |
| vila | may be python itself has a limit... | 17:40 |
| vila | ha ok | 17:40 |
| GreySim | I just want to say, I really really love bzr, and thank you all. | 20:54 |
| * GreySim loves that commands are intuitive and I don't think I've ever had to look one up. | 20:55 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!