RE: cvswrappers - any better suggestions ?

[Greg A. Woods]

[[ Could you please learn to format your text so that it can be properly
displayed on the average terminal?  Thanks! ]]

[ On Monday, April 2, 2001 at 12:20:34 (-0700), David Glick wrote: ]
> Subject: RE: cvswrappers - any better suggestions ?
>
> 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...):

No, unfortunately we cannot agree on that statement.  It is wrong (in
fact it's completely self-contradictory!), and it points out why you're
"not getting it" (at least to me).

BTW, binary opaque files should probably never be supported by any
source code control system that supports any form of merging.  ;-)

Note though that I have never argued against the concept of inventing
merge tools that can properly merge non-text files.  In fact I've longed
for tools that can merge source at a syntax level instead of a lines of
text level!  (Emacs ediff gets close in that it can combine its
capabilities with syntax highlighting and make at least manual merges
much easier.  Rumour has it that BitKeeper has a very good merge tool
too.)

However until someone can specify a repository format that can take a
CVS-like tool beyond RCS, this is all just blue-sky dreaming.

I.e. CVS literally cannot support *binary* files!

> 1) Violate the 'concurrent' philosophy with regard to binary files,
> 1) and implement a locked checkout to allow for straightforward
> 1) creation of deltas and avoid the messy problems of figuring out how
> 1) to concurrently update binary files.

That's what plain RCS, plain SCCS, and other basic tools built atop of
them do today.  There's a multitude of such tools, both freely available
and proprietary.  If this is your approach then drop CVS and choose one
of those tools.

You cannot make CVS do #1 without changing it into something that cannot
be a "CVS".  (Indeed the watch/edit facilities can help developers who
fail to work in the "concurrent editing" mode communicate, especially
when they haven't already got other good ways of communicating amongst
themselves.  These features are not a substitue for #1 though and they
only help a tiny bit with the binary file issues.)

> 2) Allow for concurrent checkout of binary files, but disallow
> 2) concurrent commits, e.g. only a user that has updated to the
> 2) current version will be allowed to commit changes.

That's exactly what CVS does now.  The problem is with the "update"
part.  CVS currently forces the burden of choosing between one version
and another on the "loser" of the checkin race.

However that's not the only problem -- there's also the problem of
merging changes between branches.  The more binary files you have the
less you can succeed with such merges.

Even if someone invents automated merging tools that could replace diff3
(i.e. rcsmerge) you cannot use them in CVS without changing the
repository format at a very fundamental level.

It's interesting to note that PRCS can do merges of text files with a
binary delta storage format (xdelta) just as well, if not better, than
diff3 can do.

> Neither approach is ideal, but both provide a step in the direction of
> better support for binary files.

If you don't like the tradeoffs of #2 then don't use CVS.  Period.

>  I'm sure there are other approaches
> that may well satisfy other people's needs, too.

There is a "two phase" commit approach, and there are tools available
which implement it (one of the free ones being Aegis).  This approach
has many advantages over CVS in some types of environments.  Note that
for binary files it still really only just shuffles the blame around in
a different way and shoulders the responsibilities for choosing change
sets on different roles in the process.

>  There may even be a
> way to fold binary file support completely into the CVS philosophy;

You really should read the relevant threads in the past four or five
years of this forum before you promote such a mistaken idea!  ;-)

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

I can appreciate that.  However it's no excuse though for blaming CVS
for being designed the way it is.  It's not even really a valid excuse
for using CVS when some better tool would make your work more
productive.

-- 
                                                        Greg A. Woods

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