Re: Need advice on 1) binary files, 2) locking

[Tobias Brox]

[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/