RE: cvswrappers - any better suggestions ?

[Gianni Mariani]

Greg,

Your point is well taken.  However, time are a changing - source code is not
only text. Image, sound, movie, geometry, encryption key, etc etc files are
all parts of modern day applications.  All these files need to be version
managed just like regular files.  If we could apply an rcsmerge on these
kinds of files, then it would be ideal.

Here is some interesting work in this area:
http://www.cs.berkeley.edu/~jmacd/xdelta.html

I have one idea that might work. Earlier versions of RCS used to not deal
with binary files at all. At that time, people used to uuencode or base64
encode binary files and then check them into RCS files.  Under some
circumstances these files are mergable and hence limited "concurrent"
modification is possible.  I can think of at least 2 generic ways that you
could encode binary files into text files that could in many cases enable
merging of modifications - now, if they would break the intended
applications or not is a different story, but it would be easy to back out a
change and restore the original unlike today.

We both agree, cvswrappers is a band aid at best.

As to the RTFM comment, I have. Not all the users in my company have. I
don't want everyone to have to spend days understanding the ins and outs of
CVS like I have.  I want it to just work - ALL the time.  Hence, if someone
checks in binary files, then it should not have a default action of
destroying the file. Most files that are mergable have well known
extensions, "cpp", "c", "h", "java" etc and the 'file' command does a good
job of identifying them as "text". Version management goes beyond just text
files.

As to MYSELF developing a new versions management system, there are plenty
of people doing that, I would just confuse the situation.  The reason I
choose CVS is because it is prolific, people I hire are likely going to know
about the system. I'd rather fix CVS itself - that is if I get time to do
it - along with my 100 other unfinished projects.

My suggestion to you, as you offered so many to me, is to think about a
broader use of CVS as not only a concurrent versions/merging tool but also
as a database off all components that are used to build products - some of
which are not text; that I need to version successfully and satisfies the
ACID semantics (Atomicity, Consistency, Isolation, and Durability).  Then
add this to an environment of many users that have very different levels of
expertise.  I assert that people who do default things should not have
surprises - especially damaged data - even if the default thing (like adding
a new file without explicity saying it is binary) is a dumb thing to do.

Thanks
G

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Greg A. Woods
Sent: Thursday, March 29, 2001 11:52 PM
To: Gianni Mariani
Cc: address@hidden
Subject: RE: cvswrappers - any better suggestions ?


[ On Thursday, March 29, 2001 at 22:21:29 (-0800), Gianni Mariani wrote: ]
> Subject: RE: cvswrappers - any better suggestions ?
>
> I would actually call this a major deficiency in CVS - it should probably
> assume binary by default, or even use the command 'file' to detect the
file
> type on adding a file. Destroying files by default is just not recomended
10
> out of 10 times - just at a guess.

WHOA!  Hold on just a moment here!

"CVS" is the "Concurrent Versions System".  It was explicitly and
knowingly designed to handle *concurrent* editing of *source* code
(i.e. the stuff that's logically mergable with diff3)!  Versions of
binaries files are, by definition, not possible to merge in any logical
way with diff3, ergo CVS does not deal with binary file formats.

This cvswrappers crap was a poorly thought out add-on that does not do
very much good for anyone and which tries its damndest to go against the
core design of CVS from the inside out.  If you use it without fully
understanding the implications then you only get what you deserve.

If CVS destroys binary files by default then that's OK because storing
binary files in CVS in the first place is a user error -- it's not
designed to handle them in any complete way whatsoever.  RTFM.

If you want some kind of file and versioning management tool that has
some of the characteristics and features of CVS (eg. the user interface,
and/or the remote access protocol) then write such a tool -- just don't
call it CVS.

--
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>      <robohack!woods>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>