[Top][All Lists]

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

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

From: Greg A. Woods
Subject: RE: How well does CVS handle other types of data?
Date: Thu, 12 Jul 2001 01:56:32 -0400 (EDT)

[ 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.

Unmergable files are fundamentally at odds with any concurrent
development (be it concurrent editing, or just branching and merging).

Learn to separate your unmergable files form your other stuff and build
procedures and processes to bring them together only at build time!

> 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).

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.

However if you don't have gobs of money to spend on implementing one
then I'll bet there won't be one any time soon.

> 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
though and it doesn't seem that complex or difficult -- it's simply a
matter of understanding the intent of the two changes and knowing
whether they're in conflict or not and if they are then using the intent
to figure out whether one must be given up, or whether both must be
preserved.  Fundamentally there's no difference here in how you resolve
conflicting changes in source code, except that for most binary image
formats any and all changes always appear to be in conflict at the data
representational level.

Get your graphics people to handle that problem!  I.e. get your graphics
files out of your CVS repository!  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)!

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

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