I'd argue that I do get it; you just don't get that I get it.
Your statement "CVS literally cannot support binary files..." should be changed to
"CVS does not currently support binary files in a way that is consistent with the
philosophy of concurrent editing".
If we can agree with the above statement, then this immediately leads to two possible
approaches (or three, if you continue to argue that binary files should not be
supported...):
1) Violate the 'concurrent' philosophy with regard to binary files, and implement a
locked checkout to allow for straightforward creation of deltas and avoid the messy
problems of figuring out how to concurrently update binary files.
2) Allow for concurrent checkout of binary files, but disallow concurrent commits,
e.g. only a user that has updated to the current version will be allowed to commit
changes.
Neither approach is ideal, but both provide a step in the direction of better support
for binary files. I'm sure there are other approaches that may well satisfy other
people's needs, too. There may even be a way to fold binary file support completely
into the CVS philosophy; I'm just too busy right now to think it through completely
(and, unfortunately, I'm *way* to busy to actually do the work... sigh.).
----- Original Message -----
Clearly you do not get it at all. CVS literally cannot support binary
files in any better fashion without becoming something that will no
longer be a "Concurrent Versions System". It was designed specifically
to force concurrent editing and that design goal permeates the way it
works through and through (despite the valiant attempts by others to
bend it to suit their twisted ideas). You cannot throw out the bath
water without throwing out the baby in this case -- they are one in the
same.
----- Original Message -----
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
