Re: binary files bad idea? why?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Greg,

It is a pity that you didn't bother to read what I wrote and instead
ranted on a question that was not asked. Have you been ill? If so, I am
sorry to hear it, please get well soon.

Let me put this in simple terms via an exmaple.

I was asking if an automated FORM of the following commands (note that
locking issues and file permissions and the like would also need to be
handled properly, this is just pseudo-code as an example):

Given a checked out tree where filename was originally checked out when
<base-version> was the top of the branch, and for which the latest
version is now <head-version> and for which local modifications have
been made, run the commands:

  cvs update -p -r<base-version> filename > filename.<base-version>
  mv filename .#filename.<base-version>
  cvs update filename
  mv filename filename.<head-version>
  <diff3-equivalent> \
    -E -am -L filename -L <base-version> -L<head-version> -- \
    .#filename.<base-version> filename.<base-version> \
    filename.<head-version> > filename.merged
  mv filename.merged filename

and where <diff3-equivalent> is some program other than 'diff3', but
which accepted idential arguments to diff3.

[The above is roughly equivalent to what run_diff3() does in cvs other
than that cvs hard-codes the use of the 'diff3' executable instead of
allowing for the possibility of using a different executable. Feel free
to read the code in rcscmds.c that pertain to this.]

The same basic method could be used either to do a simple
'cvs update' on a tree or to do a 'cvs update -jtag1 -jtag2'
on a tree.

As you should be able to see, there is nothing in the above that is
assuming anything about the internal delta formats or any of the other
drivel you banged into your keyboard.

It has been suggested that the 'diff3-equivalent' command name might be
kept in an newphrase section of the delta for each version, but that is
not even required for this example code and we could store it outside of
the rcs file if there was an excellent reason to do it (even though all
of the tools that manipulate rcs files I have been able to find would
not have a problem with an extra keyword-value pair).

Your entire reply to my previous message did not address any of the
points or topic of my message and instead attacked a position I do not
hold (by name-calling whoever would hold the positions that were not
your own). Honestly, my original message was not intended as flame-bait.

If you are not going to even bother to read what I write and not try to
read between the lines, you are going to hurt yourself and burst a blood
vessel or something...

        -- Mark


Greg A. Woods <address@hidden> writes:

> [ On Thursday, July 8, 2004 at 23:01:09 (-0700), Mark D. Baushke wrote: ]
> > Subject: Re: binary files bad idea? why? 
> >
> > 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.
> 
> Except those assumptions in total are bogus (and unrealistic), and they
> do not leave one with a true RCS-compatible repository either.

Your opinion, while strong, does not address the particulars.

> Remember the whole point of RCS compatability is to be compatible with
> other tools that understand and use the RCS ,v format.  It's not just a
> convenient delta compression mechanism.  However the particular form of
> delta compression used universally in the RCS ,v format is integral to
> everything I know of which would rely on RCS compatability.

Well, if we were really RCS compatible, we would not have magic branches
and CVSNT would not have mergepoint entries in deltas, so the 'whole'
point is somewhat less than 'whole'... There are good reasons to follow
the RCS format and not be egregiously incompatbile. Nothing that follows
the RCS syntax format to add a few newphrase entries could be said to
be a tools that is compatible with RCS format.

> If you want to just compress deltas efficiently regardless of the
> internal structure of the files being versioned then you should use
> xdelta and give up entirely on the notion of RCS compatability.  That
> way lies ultimate flexibility, but of course it's also the path to ever
> more waste of computing resources necessary to reconstruct deltas in
> more sensible forms for both human _and_ computer consumption, wether
> that's the traditional diff/patch style or some other representation
> suitable for non-text files, _every_ time they're needed.

I missed the leap of subject here. No once have I mentioned the internal
representation of cvs files. You are the one who raised xdelta, not me.
If you choose to raise that ballon and then shoot it down, it does not
really reflect on my question and mostly sounds like a rant to me...

> Also within the architecture of CVS it's totally bogus, stupid, and very
> short-sighted, to go blindly off and invent yet another ugly brain-
> damaged hack that doesn't fully account for the fact that some
> signifiant number of files' "internal structure type" (for lack of a
> more succinct term) _will_ change over time in any sizable project.
> CVSwrappers is bad enough for this reason alone already (never mind the
> other brain-damage it implies) and luckily it's not used by many
> otherwise sane people.  Any extension mechanism _MUST_ be per-delta, but
> of course that goes against the very nature of RCS (and there are
> already a vast number of attributes which are not per-revision but
> should be to get to this level of flexibility).

So, now you are calling yourself and your idea of xdeltas bogus, stupid
and very short-sighted? I am glad you were not flaming me. To be honest,
the above paragraph has so much invective as to be unreadable. Calm down
and try again. I didn't mention CVSwrappers this time around either, so I
am not sure why it was brought forward.

First you say that extensions must be per-delta and then that they must
not be. I'd be happy for there to be a way to have an extension which
was per branch and able to be changed. The only place that the
diff3-hint stuff would make any sense would be merging to the head
version of a branch... A way to get there would be to have the attribute
added to the head of a branch and able to be added to any new head of a
branch. The new semantics of the newphrase would be to walk the list of
ancestors until you find the diff3-delta to be used and default ot using
diff3 if nothing was seen on all of the revisions going back. However,
that is an implementation detail and I am still trying to explore the
usefulness of the feature itself.

> > 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.
> 
> That's not the point -- why would anyone be bothering to use a change
> control tool in the first place if all they want are archives of
> revisions with delta compression for storage efficiency?!?!?!?

Why would anyone assume that the question you answered was the question
I asked?

> The whole point of doing change control is to capture (and be able to
> reproduce, undo, copy, merge, etc.) the essense of the changes made, not
> just to archive various revisions.  While one can pretend to do this by
> reconstructing them every time using "the right tool" and re-extracted
> copies of "the right revisions", that's (politely speaking) not a very
> productive direction to go in when one is still using RCS in the
> back-end.

Again with your 'whole point' eh? For you the world has only black and
white and no grey areas at all?

To be honest, I have no clue what you are bitching about this time, but
it probably assumes that some fundamental change in the RCS deltas is in
question when that is not the case.

> As you full well know there are ample other available tools which are
> better suited to doing this already too (and one widely used delta
> compression algorithm to bind many of them together, conceptually at
> least, if not with repository compatability :-).

Huh? Sure, folks could use the pseudo-code I gave above to do merges,
but it is far from easy to do.

> IMVNSHO (and it has always been so) CVS could and should be making
> better and more efficient and more effective use of the deltas stored in
> RCS files, in their direct native format; not less.

And pray tell, what do you mean by the above paragraph? I have having
difficulty following your line of reasoning and suggestions here. They
seem to be far afield from my original question.

        -- Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFA8yiG3x41pRYZE/gRAup8AKCLLAobz3Hn/q6Rr/tpFz2r+EPgzgCdH5Yq
y0eEoP5hdPkJ76rVnc+msUk=
=SWyn
-----END PGP SIGNATURE-----