> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 06, 2002 1:58 PM
> To: Thornley, David
> Cc: [EMAIL PROTECTED]
> Subject: RE: CVS and Jar files: Should you import Jar into the
> Repository? Why or why not
>
>
> [ On Wednesday, March 6, 2002 at 09:59:38 (-0600), Thornley,
> David wrote: ]
> > Subject: RE: CVS and Jar files: Should you import Jar into
> the Repository? Why or why not
> >
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > >
> > > It might not be a "necessary feature", but it's the way
> RCS files work
> > > today and in combination with the forced concurrent edits
> feature of
> > > CVS, it makes it nearly insane to try to track non-diff-able and
> > > non-patch-able files!
> >
> > Why? Lots of people on this list who appear to be sane have used
> > CVS to track limited numbers of non-diffable files.
>
> Sure, it's possible, but it does not work well and it does
> not give any
> meaning to the results that cannot better be obtained in any number of
> other possible ways.
>
I still fail to understand the problem.
If I have a directory with several text files and one binary, I can put
it on CVS. I do have to record the binary as binary. I can have people
do concurrent development on the text files, and can use branches. When
I do a checkout, update, or export, I can get the versions I expect. One
command to get the whole thing, reducing the possible ways to screw up.
What I cannot do is merge versions of the binary, which means that I want
to avoid concurrent development, and in the case of separate changes
on branches I can't automatically merge. Instead, I have to choose one
version or the other, or independently create a third. This is not
particularly onerous, usually, and it's pretty much the same merge algorithm
that any other system would have.
Obviously, if the non-mergeable files change frequently, and are most
of the source tree, it becomes effectively impossible to use branches
and concurrent development, and in that case there's much less reason to
use CVS.
However, given small numbers of files that change relatively infrequently,
this approach works pretty well, and I really don't know of anything better.
> > The points to
> > remember are (1) it works in CVS, although not as well as other
> > formats do, and (2) there's nothing in general that's all that much
> > better.
>
> On the contrary! _ANYTHING_, in general, is much better!
>
> Simple directory naming schemes are almost infinitely better!
>
In what way is a directory naming scheme, or named tarballs, infinitely
better? In order for it to be infinitely better, I'd need to be causing
infinitely hard problems by keeping binaries under CVS control.
(Alternately,
the naming scheme would have to set itself up with zero work, or zero
chance of error, or something like that.) Even allowing for exaggeration,
I haven't had serious problems connected with keeping binaries on CVS.
I've been hearing that there are such problems for a long time, and still
haven't found them.
Could we perhaps have a use case showing these horrible problems? Assume
we're developing software and need a few icons.
> Get out of the box!
>
I'll get out of the box when somebody shows me something better outside.
Hasn't happened so far.
> > (Remember that, although binary diff programs exist, they're
> > just storage optimization unless a diff between two
> versions of a file
> > can be patched into a third and still make sense.)
>
> _Me_ remember _that_? I'm the one that's been trying to teach people
> that fact for nearly a decade now! That's part of the whole
> point _here_!
>
No, that's not part of the whole point. If it was possible to do
diff3 on certain binary files, and CVS didn't, then other systems could
do better than CVS in that regard. (This is apparently true of MS
Word files.) That would be part of the point. For things like
icons, there is no feasible diff3 short of giving the versions to
the local artist and telling her to come up with something that
reflects both changes.
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
