On Thu, Mar 18, 2010 at 9:53 PM, Harry Putnam <reader@xxxxxxxxxxx> wrote: > 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. [...] > 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. Yes. Or you could skip the central repo and pull directly from one machine's working tree to another. If that has any value to you, then it's the only likely reason a DVCS would do you any good for this trivial case. The real question is: what makes your current setup a PITA? If you can't answer that concisely, then you don't know what to look for in a supposedly better solution. > 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? git sucks at handling large binary files (>50 megs or so) unless you have boatloads of RAM. If your binary files are moderately sized (a few megs) then it'll probably be reasonably efficient. I don't know about hg and bzr for memory usage. It's better to store uncompressed binary files (eg *.tar) instead of compressed ones (*.tar.gz) in order to allow useful delta compression. That means raw images instead of png/gif/jpg. And probably completed flash files are compressed. The best thing to do is actually try it and see if your repository size and memory usage is reasonable. Have fun, Avery -- 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