RE: cvswrappers - any better suggestions ?

[David Glick]

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

Since I'm using an Open Source mail agent (which I'm trying to find time to 
contribute to), I'll take this as an enhancement request and add it to the 
list... <g>

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

Well, you're right this time; I don't get it.  How is my statement 
contradictory?

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

Greg, what you're arguing here is that it is impossible for #1 to be 
implemented without changing the repository.  I agree.  However, it is 
certainly feasible that this change would be fully backward compatible with the 
repository as it exists today. Of course, it's also true that the repository 
would *not* be 'forward compatible', e.g. you could not use an old CVS server 
on a new repository with regard to binary files.

However, I disagree with the notion that I should drop CVS for something that 
supports binary files better.  I *like* the way CVS supports source code 
editing; I think it makes development groups *more* productive.  But binary 
files are almost always an annoying problem in most modern development 
environments that I have to find a way to deal with.  The current support CVS 
has for binary files is ok, but not great.  Better binary support, even if it 
fails to fully support the 'concurrent' philosophy, would at least allow me to 
leverage the benefits of CVS for what it does best.

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

Perhaps you can educate me here.  I was under the impression that CVS did not 
supports deltas when dealing with binary files, but rather copied the modified 
binary file completely.  Is this not accurate?

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

Or else modify CVS to better meet my needs, assuming that it also meets the 
needs of other users and doesn't impact its use by 'old timers'.  Now, if 
nobody but myself would find these modifications useful, I fully agree I should 
go find something else to use.  However, in the short amount of time I've been 
monitoring this list, this issue seems to come up a lot.  You can argue that 
it's because those people are newbies and don't 'get it'.  I'd argue that it's 
because CVS is flawed in this instance.

>>  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!  ;-)

<g> I'll add it to my reading list.  However, you're doing a great job in 
summarizing the arguments.  I'm just curious if I'm rehashing old argurments or 
coming up with anything new.

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

I'm not blaming CVS; as I said, I *like* CVS, and I fully buy into its general 
development model.  I do believe that the 'Concurrent' in CVS is what makes it 
superior to most other tools.  Having said that, I'd like a better way to 
handle binary files, even if its not 'concurrent' in this instance (and I 
accept that this *is* contradictory <g>).


David Glick
Transmit Consulting, Inc
619-475-4052
address@hidden