Hi We currently have about 350GB of 1MB binary image files stored in a CVS repository in order to keep track of who created them and when, and in rare circumstances when they are modified or replaced, who did that and when. The application has no need for concurrent merges, since the files are rarely modified the ',v' files take up little more space than the images themselves, and we have had no problems with cvs messing with the format of the binary files (which are obviously checked in -kb). We have relatively few users hitting on the system at one time which probably is how we get away with it.
Essentially, we use CVS like a versioning filesystem in this application, and while it may be a little slow and unwieldy, it gets the job done, at essentially no cost and using a tool we were already familiar with. The thing we miss most is an "ls" command via pserver (which we use exclusively) but if we really cared that much we could add it I suppose. We also miss a digital signature capability on checked in files, but again we could add that if it really mattered. So for everyone who says we shouldn't be doing this because it wasn't designed for it, I say point us to a better tool that is as free and accessible and familiar as CVS and can also handle all our text and source files, and yes, Word and PDF documents too. We don't want one tool for text and a different one for binaries, period. Maybe Subversion will do the job when it is finished. By the end of the year I expect to have several TB of images stored in this system and I will let you know if and when CVS becomes a problem. david PS. I also store jar files and complete tar'd up releases and all sorts of other things in CVS so I guess I am just a heretic. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
