info-cvs
[Top][All Lists]
Advanced

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

Re: binary files bad idea? why?


From: Mark D. Baushke
Subject: Re: binary files bad idea? why?
Date: Thu, 08 Jul 2004 23:01:09 -0700

Hi Greg & Paul,

Greg, Could you answer the following restricted question...

IF we assume that the 'cvs update' of a particular file in a user's
sandbox needs to do a three-way merge (checked-out version,
latest-version and locally modified version) AND we assume that there is
a "hint" for the CVS server to use some program that looks just like
diff3 as to arguments, but (possibly) interprets (say a canonical HTML
structure ignoring whitespace) the file differently than the default
diff3, AND the "diff3-like-progam" for the checked-out version and the
latest-version specifies the same diff3-like program, THEN Paul's
request for an extension seems reasonable to allow this kind of an
extension.

The 'cvs commit' that might result from this merge is not related to
this discussion and continues to use the built-in gnudiff utils.

The lack of support for a per-delta newphrase that tells some version of
CVS to use this other diff3 equivalent would not impact RCS nor would it
impact older versions of CVS.

In this world view outlined above, are there other problems that are not
being considered?

I really do want to know your opinion. I do not see the fundamental
conflict you seem to see here.

Paul, Could you answer the following restricted question...

IF we assume that the 'cvs update' of a particular file in a user's
sandbox needs to do a three-way merge (checked-out version,
latest-version and locally modified version) AND we assume that there is
a "hint" for the CVS server to use some program that looks just like
diff3 as to arguments, but (possibly) interprets (say a canonical HTML
structure ignoring whitespace) the file differently than the default
diff3, BUT the "diff3-like-progam" for the checked-out version and the
latest-version specifies DIFFERENT diff3-like programs, THEN Greg's
objections to adding a "diff3-like-program" per delta runs into a
problem with not really having a good solution to jump from one diff3
alternative to another, so the default diff3 would need to be used.
However, the propagation of "diff3-like-program" adds extra complexity
to generation of new deltas and would seem to add a lot of overhead for
a given file. If a file really does change "types" over time, there are
boundary conditions that are difficult to handle and dealing with extra
information such as the file "character set" or "mime-type" which may
lead to the heuristic selection of a diff3-like prgram is rendered more
complex. If a simplifying assumption is made to use a diff3-like program
for all revisions of a file, then putting that hint into the admin
section for the file (just like keyword expansion) might make more
sense, but is it a general enough solution to really deal with the
situation correctly? What if your diff3-like program needs to be
interactive, how much impact does that make to locked directories and
the like? Would it make more sense to just use something like this:

   cvs -n status foo.ext
   ...notice that it is in need of being updated
   cvs up -rBASE -p foo.ext > foo.ext.base
   mv foo.ext foo.ext.mine
   cvs up foo.ext
   mv foo.ext foo.ext.new
   diff3-like-program \
     -E -am -L foo.ext -L <BASE-REV> -L <HEAD-REV> \
     -- foo.ext.mine foo.ext.base foo.ext.new \

"by hand" rather than trying to have cvs do it for you behind your back?

In this world view outlined above, are there other problems or solutions
that are not being considered?

I can sympathize with your desire for a non-diff3 program to do
user-level merges, but I am still looking to find such programs as might
exist. There are still a lot of unknowns about how such a new feature
should be implemented and there are not a plethora of programs that can
do what is needful unless I have missed them.

        Thanks,
        -- Mark




reply via email to

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