[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How well does CVS handle other types of data?

From: Noel L Yap
Subject: Re: How well does CVS handle other types of data?
Date: Wed, 11 Jul 2001 15:28:26 -0400

Not only that, but CVS does't handle code reformats elegantly at all.
Philosophically, this means that CVS can't merge source code under all
conditions.  Does this mean you shouldn't use it when such tasks can occur?  Of
course not,  All it means is that these situations need to be controlled so that
CVS is usable (eg minimize their occurrence and ensure others know that it's
going on).  Even if the situation is cotrolled, there's still a chance that you
have a massive manual merge to do (eg when branches are involved).  Does this
mean that one should never do code reformats?

I guess this is the real argument -- it's not whether the files are text or
binary, it's whether they're mergable or not.  Ideally (and this has been
discussed before), CVS would allow hooks for diff/merge engines.  You could then
supply such an engine for, say, Java code, and refomat as you desire.


On Wed, Jul 11, 2001 at 02:29:08PM -0400, Jeff King wrote:
> Exactly. "Source code" and "binary data" are quite conceptually different.

Not always.

Both can be used to create an executable (embedded icons, for instance).
So, from the viewpoint of "source items that are used to make a final
executable," they ARE conceptually the same.

     Mike Castle      address@hidden
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Info-cvs mailing list

This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]