> [[ 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
[EMAIL PROTECTED]
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
