[Paul Sander - Wed at 11:05:05AM -0700] > >According to the ACL discussion, CVS is not a security tool, hence it would > >be very hard to make anything else than advisory locks. > > CVS, like any other application, can control how its users access its > data. It doesn't need to be a security tool to do that.
If the access is to be nothing else than advisory, it doesn't matter (and probably that's what you need, anyway). If the ACLs and locks are to be enforced on potentially malicious users, CVS needs to be secure. As of today, it was not written to be secure, and it probably isn't - that is, it's far from trivial to implement secure ACLs and locks into CVS. > This argument has been made before many times. The counterargument is > that having a single version control system is much easier on the users. Yes, certainly! I was a bit afraid to be misunderstood - if you have a setting with a lot of text files and some few binaries, it is certainly convinient to put the binaries into CVS. I wouldn't discourage you to put .jpg's and .gif's into the repository, as long as the _main_ reason for using CVS is to keep the text files (html, typically) under version control. At the other hand, if you have a lot of binaries that are frequently edited, and some few text files, CVS is probably not the right solution. > Also, version control _is_ needed even on binary files that are undergoing > active development, even if they can't be merged. If you can't make small diffs of the files, you can hardly get better version control than an archive of elder files and a changelog. Using CVS is a bit overkill. (...and if you _can_ make diffs, then it should also be possible to merge changes). > Unfortunately, there aren't many ways to wrap bitmap images in text > files that can still be merged. Some image formats can be converted > that way, but not the ones most popular for web design and icon images > used in GUI designs. There's also the larger picture to consider, > such as design documents and models that get stored in opaque formats > and have no merge tools. I'm not much into computer graphics, so please do correct me if I'm wrong. There are three classes of picture formats: - Bitmaps (a picture, as it is displayed to the screen). Perhaps practically impossible, but if you had one line for one pixel, you would actually get text files that easily can be diff'ed and merged. You'd probably need plenty of hardware resources, but at least you could get even better version control than at ordinary text files :-) - Vector/object data - that can be rendered into a picture. Such data should be perfectly possible to represent through text files, and those text files can be under good version control. - Compressed bitmaps - and then I'm talking of lossy compression (I'm considering losslessly compressed bitmaps to be more or less equivalent with bitmaps in this context). Having some few .jpg's that are infrequently edited in the CVS certainly can be convinient. Anyway, I guess (correct me if I'm wrong) the only way a compressed image can be edited is through converting it to a bitmap, and then back to a compressed image. I would daresay that quality is lost every time the edited bitmap is compressed - just like quality is lost every time some analogue data is beeing copied. If the file is frequently edited, it will slowly degrade - thus, I think it would make more sense to store the uncompressed bitmap in CVS, and rather have a tool (typically a Makefile) to create the compressed images. -- Unemployed hacker Will program for food! http://ccs.custompublish.com/ _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
