It looks like Linus has written his own "simple" revision control system called "git". It's here: http://kernel.org/pub/linux/kernel/people/torvalds/ Has anyone *actually* mentioned vesta to him? adammartin: Not sure. I'm thinking I'll take a look at this git thing and see what it does, maybe this weekend. It's apparently fairly rudimentary. From that "Committing initial tree" message, I think I have a good guess which of the three in zooko's triangle git chooses to leave out. Er, darn, mis-channel. wishes he weren't spending all weekend practicing next week's Security For Normal Programmers lecture... ...or he could write an article "reasons why linux kernel dev should move to vesta - and reasons why they might NOT want to" adammartin: Heh. not much in the way of information about git on that web page. scottven: Yeah, I haven't been able to find much about it. http://kerneltrap.org/node/4982 has some breif intro for anyone who hasn't found it yet.... Just appeared in vlatest - http://pub.vestasys.org/ : vestasys.org/vesta/repos/46.preserve_attribs/3: small code changes to improve the version, like passing preserved attribs as argument of appendEntry function Just appeared in vlatest - http://pub.vestasys.org/ : vestasys.org/vesta/repos/47: Preserve versions on stubs replaced by other objects and on other objects replaced by stubs and ghosts. Promoted from repos/46.preserve_attribs/4. vestasys.org/vesta/repos/46.preserve_attribs/4: Minor documentation re-wording Just appeared in vlatest - http://pub.vestasys.org/ : vestasys.org/vesta/srpc/26: Removed append_prt from chars_seq/bytes_seq. Restored pointer-free memory allocation for chars_seq/bytes_seq storage. A user asks me: "What is the default build directory, e.g the directory that files get compiled into by default?" I'm trying to figure out how to rephrase that into a decent FAQ. Or even what section to put it in. Maybe a new one on general building questions? you know, GIT does have some features in common with Vesta. scottven: Enlighten us. (I still haven't read much about it.) xorian: content based fingerprinting. fingerprint indexed backing store. a concept similar to advancing as a seperate action from checking in. xorian: oh, and 1980's style simple 3 way merge. :) scottven: Did you get all that from the readme? xorian: no, from the kerneltrap.org link that adam pasted in around lunch time today. xorian: it has lots of lkml excerpts about the features. xorian: GIT does however still use the CVS model of everyone having a more-or-less complete source tree checked out. THough, towards the end it evolves towards supporting sub-trees. cvs sucks vestabot: thank you. np scottven: I see what you mean. Reading through that page is giving me some ideas. Like having a diff tool that would read the directory structure and only compare the files that are different. But, ugh, SHA1 hashes for naming. the git discussion is pretty interesting. it seems like linus would be a lot closer to satisfied with Vesta than i ever thought. he doesn't really care that much about the sophisticated merging support in BK. and his way of making things fast in git is pretty Vesta-repository-like. i guess it's because i'm basically a file system person, not an SCM person, too. it seems like linux needs the diff tool that only looks at files that have been changed because the whole kernel is one huge package. or maybe a few huge packages (one per subdirectory). yeah, we could make something like that easily too. i imagine the "SHA1 hashes for naming" level of git is similar to the "lookup by fingerprint" level of the repository -- users don't really see that.