[ On Thursday, September 4, 2003 at 18:25:43 (-0400), Terrence Enger wrote: ]
> Subject: Re: cvs diff, proposal for change
>
> I would not dream of suggesting a change to that. Nor do I suggest
> changing anything in the repository, or even in a sandbox.
Properly doing what you suggest requires changing the very way RCS files
work internally. RCS stores the output of "diff" and relies on the use
of newlines to delimit records in a file. If you want to store deltas
of binary (opaque structure, non-text) files then you either need to use
a means of calculating the differences between versions of such files
(e.g. xdelta), or you need to store whole copies of every version of
every file. The latter though is totally incongruous with how CVS uses
RCS files.
If you're going to do the latter then why are you bothering with CVS?
The primary goal of the Concurrent Versions System (CVS, aka CVS-II) is
its ability to allow "Concurrent" edits of source files. This ability
hinges squarely on the way the underlying RCS system calculates deltas
of source files and can merge changes with conflict detection.
You can _very_ easily build interfaces between your larger SCM and an
archive of binary files stored with each file in a uniquely named
directory -- it's just naming conventions and you can even use the very
same naming conventions you now use with CVS (i.e. serial numbers for
un-named revisions and the same tag names for named revisions).
> Yes, but (in my best, 3-year-old, obnoxious whine) ...
> (1) I have some familiarity with cvs, and I am learning to
> like it more all the time.
What you are hopefully learning to like about CVS is not possible to
achieve with opaque-structured binary files and not possible to achieve
using RCS as the repository format with any non-text files (regardless
of how well you understand the structure of those files and regardless
of how many tools you may already have which can detect changes in such
files in a structured manner -- if you don't modify RCS you cannot
meaningfully store deltas to any such files and thus you cannot
meaningfully merge changes between different versions that were derrived
from the same ancestor).
> (2) I have binary files, and <confession> lack of version
> control of binary files has wasted too much of my
> time</confession>.
> Just like any 3-year-old, I don't want to admit that I am
> SOL.
You're not really SOL -- it just looks like it until you learn to think
a little outside the box you've built around your current thoughts.
1. keep your binary files in a separate manually managed archive.
2. use smart naming conventions for that archive which directly map, or
can be mechanically mapped, onto the same naming conventions you use for
your text files in CVS.
Lots of us have very successfully used this approach to managing change
in files we cannot store meaningfully in CVS. If, for example, you use
"make" or some other scripting language to build your sources then the
integration of this management is done by changing the version names
used in makefiles or the build scripts to reference the binary archives
and thus you can still track the changes to the references of those
binary archives in CVS.
If you have some other tools which allow you to track internal changes
to those binary files in some way that's meaningful for those files and
for your project then by all means please do use those tools on your
separate archive of binary files.
> cvs already supports binary files to the extent of offering
> -kb.
"CVS supports binary files"?!?!?!? No, I don't think so. The '-kb'
"sticky flag" is just a terribly bad hack that gets more people into
more trouble with CVS than you could ever imagine because it gets
mis-interpreted as doing what you think it does. It was not intended
for that purpose at all and it does not work the way you think it does.
DO NOT try to store binary files in CVS.
> And Herr Klauer's files are binary only in the sense
> that different patterns look the same on the screen.
Yeah, sure, but unless you can calculate deltas between them in a
meaningful way and then store those deltas in an RCS file in the same
way RCS diffs text files, then you can't manage changes to such files
using tools like RCS and thus CVS. This is ever more critical for CVS
since of course CVS relies on being able to merge changes made to two
different derrivative versions of the same file and to detect potential
conflicts in those changes and mark them up in some way that the user
can resolve the (apparent) conflict(s).
> Would
> the objection to the proposal still stand if I could submit
> a patch? (I am not planning to do that soon, and probably
> not at all; just probing for the roots of the objection.)
I find it very counter-productive to discuss superficial changes that
would give only the appearance of handling non-text files. That's what
'-kb' has lead to and nothing good at all has come of it over the years.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]>
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
