RE: How well does CVS handle other types of data?

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> 
> [ On Wednesday, July 11, 2001 at 11:35:14 (-0500), Thornley, 
> David wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > OK, what?  For my purposes, it has to support concurrent development
> > and branching, and right now my company isn't going to spend gobs
> > of money.  It has to be reliable.  Heck, it has to be widely used
> > and considered reliable.  The source code repository here is very
> > valuable, and we don't want to take chances.
> > 
> > So, given these constraints, what should I use?
> 
> I think you've totally and completely missed the point.
> 
Somebody is completely missing a point, that's quite clear.  Perhaps
different people are missing different points, but I don't think
so.

> Unmergable files are fundamentally at odds with any concurrent
> development (be it concurrent editing, or just branching and merging).
> Period.
> 
Right.  However, we have to branch.  This means that we have to cope
with the problems of unmergeable files, and perform manual merges.

CVS doesn't do this well.  However this is only an objection to using
CVS if other tools work better.  I've seen suggestions for doing things
that would cost me a good deal of work and work almost as well as CVS,
but it doesn't seem to me that they would be improvements over using
CVS.

> Learn to separate your unmergable files form your other stuff 
> and build
> procedures and processes to bring them together only at build time!
> 
Why?  What do I get out of this that I don't get by keeping the
binary source files with the text source files and use CVS on both
of them?  What does it buy me?

You've accused me in another post of not being able to see a screwdriver
because there's a hammer in my hand.  I've asked what a screwdriver is,
and where to get one, and so far I've got a piece of metal I can pound
into something almost as useful to drive in screws as the claw of my
hammer.  If you'd show me something better, like a piece of metal I could
pound into a better screwdriver than I've got, I'm very willing to learn.

> > And the version control system that allows branching and makes it
> > relatively painless to merge binary files that get changed 
> in a merge
> > would be....
> 
> There isn't one (that I know of).
> 
Right.  This is the point that you completely miss.  If you are going to
tell me not to use a particular tool for a particular task, you need to
show me either that that tool doesn't work for that task, or that there
is a better tool.  You haven't done either.

CVS handles unmergeable files, although not nearly as well as mergeable
files.
I haven't been told of a tool that manages unmergeable files better.  I am
going to continue using this hammer instead of the proper tool, which
appears
to have a handle made of unicorn horn and a blade formed from a dragon's
scale.
I do have work to get done.

> Paul Sander and others have made several proposals about how 
> to build a
> CVS-like tool that could handle multiple file types and make 
> more manual
> merging processes work in conjunction with semi-automated merging of
> text files.
> 
Yes, and I'm on record as being very dubious about this.  Merging does no
good if it can't do some sort of conceptual merge (with source code, the
concepts are fairly directly represented in the data format) and provide
decent tools for resolving conflicts.  If I've got to fire up Visio and
design a composite image, I don't see that it matters much whether I'm
automatically dumped into Visio or not.

> > Consider a GIF that is changed on a branch and (in a 
> different manner)
> > the main trunk.  Where is the tool that will merge it like 
> CVS merges
> > text files?  Does it also work with PNGs and JPEGs?  Any 
> other binary
> > files we're likely to need?  If you know of such a tool, I want to
> > find out about it.
> 
> How would I know?  I'm not a graphics artist!  I can imagine 
> the process

So can I, but it requires a human mind to do anything useful with it.
So what?

> Get your graphics people to handle that problem!  I.e. get 
> your graphics
> files out of your CVS repository!

Or let my graphics people into the repository.  We allow several different
classes of people in, and have processes to limit what they can do.  The
trick is to get the graphics people together with the graphics files, not
just to assume where the graphics people are and move the files to match.

  Together with your graphics people
> you should define identification schemes and procedures that'll allow
> you to create a master build process that'll pull the right graphics
> images into the final product(s)!
> 
And, to repeat myself yet again reiteratively, I, Mojo Jojo, ask how to
conquer the world - um, I ask what having nonmergeable files not in the
CVS repository does better than having them in the repository.