info-cvs
[Top][All Lists]
Advanced

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

Re: Smoke, FUD (was Re: CVS corrupts binary files ...)


From: Mark D. Baushke
Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
Date: Mon, 28 Jun 2004 14:58:03 -0700

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

Greg A. Woods <address@hidden> writes:

> [ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ]
> > Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
> >
> > The RCS format is very extensible and in fact the
> > CVSNT folks have extended it already and I have had
> > no problems using CVSNT repositories in conjunction
> > with either CVS or RCS.
> 
> "very" is an over-statement of the first order!  ;-)

Agreed. :-)

> Sure, it's an extensible format, but not in the
> way that's been suggested. You can't get rid of
> the _exclusive_ use of diff et al without
> entirely losing compatabilty with RCS.

Yes, but diff is not diff3. diff is used for the
delta format. diff3 is used by rcsmerge, not for
fundamental version deltas.

> > I do not see support for your assertion that
> > compatibility is "far more" than just the
> > adherence to the syntax defined in rcsfile(5).
> 
> Sadly rcsfile(5) only describes the meta-syntax,
> not the nuts&bolts of how RCS files work and how
> they're actually used by the RCS package.

True, but examiniation of the rcs sources (or cvs
sources) can help you a lot.

> > So, I believe that adding a
> > 
> >         'diff3hint someprogram;'
> > 
> > line to the RCS file should not be a problem
> > for "co" to still be able to checkout each and
> > every version of the file.
> 
> "diff3hint" in the way you're hinting it might
> be used is insufficient.

Why?

> RCS directly interprets the content of the delta
> text information, e.g. the likes of:
> 
>       @d5 1
>       a5 1
>       some new line of text
>       d256 1
>       @
> 
> See, for example, lib/rcsedit.c from the RCS
> source distribution.

Yes, and that is the concern of 'diff' NOT 'diff3'.

My assumptions explicitly did NOT address any
requirements other than that a 'diff3' replacement
be used. Where did your assertion that this requires
'diff' to be changed arise?

> Any modification of the diff algorithm would
> almost certainly require changes to the syntax
> of this delta text.

I did not suggest modification of the diff format.
I suggested modification of the diff3 program to
be used.

> As far as I can tell the extensibility of the
> RCS,v syntax does not go so far as to provide
> for callouts to add-on programs and I'm arguing
> that it's _far_ too late to try to modify this
> widely used standard file format now.

With existing RCS, you may compile it to use
DIFF3_BIN as any path you wish. There is nothing
to guarentee that the diff3 does what the GNU
diff3 program did...

> So, how _exactly_ do you propose to convince the
> standard "co" program (or the equivalent in any
> other RCS-compatible tool suite, including the
> current CVS implementations) to actually make
> use of the new delta text syntax that such a
> hack would create?

I propose that "co" use "diff" just as it has
always done.

I am not proposing any change to the delta
structure at all. 

The thought experiment is proposing a change in
the function called to do three way diff and merge
operations.

> I.e. How do you propose to make it possible for
> the standard RCS tools alone to re-create
> _every_ revision from all files created by this
> hacked system?

What I suggested does not require this.

> It's simply not possible.

You say this, but are assuming facts that were not
supported. Why does a change to 'diff3' for merge
operations imply or require a change to 'diff' for
everything else?

> Like I said, only the bare surface of RCS
> compatability is scratched by the meta-syntax
> described in rcsfile(5).

Why or how would a change in diff3 impact delta
formats for RCS? The DIFF3 binary is used only in
rcs-5.7/src/merger.c and plays no direct role in
checkout or commit of RCS files.

> The RCS file format is intricately intertwined
> with the unix diff algorithm, 

Actually, I suspect this to be false. I believe
the RCS delta section format is intertwined with
the ed(1) command format.

> which is itself tightly dependent on the
> "normal" use of lines of text to represent
> elements of a the source files being managed (at
> least when it comes to automated merging for
> concurrent editing).

And all of that is not material to the current
thought experiment.

> Meanwhile there are other change delta file
> formats and other version tracking tools that
> use those other formats, and often there are
> also tools that will convert RCS/CVS
> repositories into those other formats. I.e.
> there's no _real_ fundamental need to hack on
> RCS,v syntax.

Hmmm... I may have missed something completely.
Most of the ones I have seen (the CVS to ClearCase
script for example) use the RCS commands to
checkout a file, the log message, and the date and
author information and then checkin that file to
their own system.

Are there really utilities out there that try to
to read RCS formats directly and do not allow for
rcsfile(5) syntax to be used? If so, could you
name any of them?

If such do exist, there would probably need to be
a utility to strip out the 'diff3hint ...;' lines
- From the RCS,v file...

If the intent is to store information on a
per-file basis as to which utility should be used
for doing cvs update operations to replace the
'diff3' program with one that does a better job
for a particular file format, then I suspect that
you may find it desirable to add a hint of what
other program to use to the existing ,v file
instead of stuffing it into some other location
for CVS to use.

That said, it may also be possible to deal with
some other bolt-on database mechanism... maybe
that mechanism should be used for tags too...
after all, branch tags violate the exact
specification for RCS tag values...

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

iD8DBQFA4JRr3x41pRYZE/gRAiDIAKDj5pyNdVIoY3d/rdGXJKbuqf/cBgCfW5O8
lXURTO50BUOBVP/59a4dijI=
=g4Jw
-----END PGP SIGNATURE-----




reply via email to

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