Hold your fire on this one if possible. I'm not just a lazy slug who can't think and study for himself. I'm a little confused about the different way of using rcs that git, mercurial bazaar and probably several others offer. I've not used anything but cvs. I use it at least every couple of days but really only a limited set of commands, and no deep knowledge even of that style. My usage is basically to keep up with rc files for the several OSs' I tinker with on my home lan and a fair bit of scripting and experimenting with shell, perl, c, etc. that I've built up over the years and find reason to change a bit every so often. I keep a central cvs repo and on each host I do a check out of the entire thing from the base up. Mostly to have copies of various style of rc files the OSs need but also to keep the scripts I've written over the years and learned to rely on, available and in sync. To me, keeping up with cvs is always a PITA. I've never hit on a handy and efficient way to do it. Even for a just my light usage. And I do mean lignt. For example, even after yrs of using cvs my $CVROOT is still tiny: du -sh /usr/local/cvsroot 12M /usr/local/cvsroot So, I'm wondering if one of the newer systems would be less of a PITA. How would a workflow actually go: I'd create and populate a repo, then what?. Create clones on each machine I guess and if I found a need to change or add files, I'd then push back to the original repo? Its sounding a whole lot like cvs so far. So, am I likely to see some improvement in the chore of keeping up an rcs system with git, mercurial or bazaar? Anther thing I'm really curious about concerns binary rcs. I'm thinking of photo editing and things like flash where I might be changing a project over time and want access to past versions. I'm told cvs is not good for that... consequently I've never tried it. Am I likely to find that one of git, mercurial or bazaar is far better for that? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html