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

[Paul Sander]

>--- Forwarded mail from address@hidden

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

I didn't mean to imply that it was trivial to add such features, only
that it is possible.  So far, CVS has relied on filesystem permissions
to grant access to the contents of the repository, but some users find
that that level of access is not fine-grained enough.  Some would like
that kind of control on branches as well, and perhaps certain other
aspects (e.g. the ability to create tags or set states).

All of these things are _possible_, as illustrated by many other tools.
That does not mean that it is _easy_ to do.

>> 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.

Why limit CVS' features to just text files?  There are many kinds of
source files that are not text.  Source files are any files that cannot
be produced automatically by applying software tools to other files.
That does not imply that source files are exclusively text files.  (I call
your attention to things like software design tools such as Rational Rose
and other programming aids like NextStep.)  Would it not make sense to
support them as well?

>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.

As it is today, this is certainly true.  The fact that CVS operates best
on text files is an artifact of its implementation, not its design.   It's
possible (and easy, believe it or not!) to extend CVS in such a way that it
can support non-text files as first class citizens, though it's understood
that the quality of merges will vary with the data type.

>> 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.

However, CVS offers a lot of features that remain applicable:  Centralized
repository, branching, labelling, and so on.  You can't get this stuff
with simple archives, at least not in a way that's manageable in a large
scale.

>(...and if you _can_ make diffs, then it should also be possible to merge
>changes).

How small do the diffs need to be?  I claim that they can be useful
even if they encompass the entire content of the source file.  In
that event, the merge algorithm becomes a simple selection.

I do not wish to imply that this is generally a better merge algorithm
than the one that CVS currently uses, but it is the best one available
for certain data types.  Others apply to still other data types, perhaps
with varying degrees of quality.  Using them (or at least adding a
hook to let the user register them, rather than assuming everything is
text) would be a big win without a lot of effort.

>> 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.

Unfortunately, the users are not always able to specify the file formats
produced by the tools they use.  Sometimes they're not even given a
choice of tools.  And they usually are unable or unwilling or just forget
to go the extra steps to perform some conversions just to appease the version
control system.  This does not apply just to graphics files, but other
kinds of source files as well.

>--- End of forwarded message from address@hidden