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

[Chris Cameron]

Ah,

So now you're suggesting RCS for 'binary' files and CVS for ASCII text
files.  Now a person who needs to manage 'binary' and 'text' files needs to
develop a tool for managing versions of both (and the 'binary' files may be
in multiple directories so we'd better add in a tool that works across
different directories).  Suddenly we're starting to need a tool like CVS!
Wait and look at this, then comment.
We need:
1. Ability to recreate a particular contour of file versions
2. Ability to work across multiple directories

Greg suggests that people write their own tool to do this, however CVS
(which is written on top of RCS, so how can it be good for binaries on it's
own, but not underneath CVS) can already do this.

CVS also allows you to merge text files.  For some binary files a merge can
be managed (e.g. word or framemaker documents), for others (e.g. gifs) it
does not make any sense.  Is merging of text files important?  In Greg's
world it is, in other peoples eyes it isn't.

The CVS paper (cvs_paper.ms in the CVS source distribution) says:
CVS (Concurrent Versions System) is a front end to the RCS
revision control system which extends the notion of revision control
from a collection of files in a single directory to a hierarchical
collection of directories each containing revision controlled files.
Directories and files in the CVS system can be combined together in
many ways to form a software release.  CVS provides the functions
necessary to manage these software releases and to control the
concurrent editing of source files among multiple software
developers.

The six major features of \fBcvs\fP are listed below, and will be
described in more detail in the following sections:

1.
Concurrent access and conflict-resolution algorithms to guarantee that
source changes are not lost.
2.
Support for tracking third-party vendor source distributions while
maintaining the local modifications made to those sources.
3.
A flexible module database that provides a symbolic mapping of names to
components of a larger software distribution.
This symbolic mapping provides for location independence within the software
release and, for example, allows one to check out a copy of the diff
program without ever knowing that the sources to diff actually reside
in the bin/diff directory.
4.
Configurable logging support allows all committed source file changes
to be logged using an arbitrary program to save the log messages in a file,
notesfile, or news database.
5.
A software release can be symbolically tagged and checked out at any time
based on that tag.
An exact copy of a previous software release can be checked out at
any time, REGARDLESS of whether files or directories have been
added/removed from the current software release.
As well, a date can be used to check out the EXACT version of the software
release as of the specified date.
6.
A patch format file [Wall] can be produced between two software
releases, even if the releases span multiple directories.

According to this ONE of the benefits of CVS is the 'concurrent editing of
source files' and ANOTHER is patching that is 1/3 of the major features of
CVS.

Now whenever I've been involved in product decisions, we've listed our
requirements, prioritised them and then listed our requirements that each
product supports.  Usually no product meets all our requirements so it is a
matter of determining which product best meets our top requirements.  As
merging probably doesn't fit in anyones requirement list for graphical
files, merging and patches are 'extras' from CVS, not a 'wrong tool'
decision.

Yes Greg, you've been involved with CVS for a lot longer than most of us.
But your vision isn't the only one for the software and maybe it isn't the
only one!  This thread seems to have drifted alot and people are now being
criticised for offering solutions to the original problem as if they are the
ones who asked the problem!

***************************************************************
Chris Cameron                       Open Telecommunications Ltd
Product Manager                           IN Product Management
address@hidden                           P.O.Box 10-388
      +64 4 495 8403 (DDI)                          The Terrace
fax:  +64 4 495 8419                                 Wellington
cell: +64 21 650 680                                New Zealand
Life, don't talk to me about life ....(Marvin - HHGTTG)

> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of
> Greg A. Woods
> Sent: Friday, 13 July 2001 12:09 p.m.
> To: Thornley, David
> Cc: address@hidden
> Subject: RE: How well does CVS handle other types of data?
>
>
> [ On Thursday, July 12, 2001 at 16:53:53 (-0500), Thornley, David wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > Except that I'm not banging my head against the wall, and it doesn't
> > hurt.  I don't know about the rest of you, but I'm not having problems
> > with the way CVS manages the stuff I work with, which does include
> > some binaries.
>
> at first you say one thing, and now you say another.  which is it?
>
> > What problem?  You've claimed that putting binaries into CVS is bad,
> > and now you're claiming that I've got a problem with it.  I'm happy
> > with CVS.  I wish it could handle unmergeable data as well as it
> > handles mergeable, but that isn't possible, so I'm (a) not considering
> > it a problem, and (b) not going to buy that keeping these apart is
> > going to solve any problem I may have.
>
> Well then quit wishing for the impossible!  All you're doing is
> confusing the onlookers!
>
> > Why, in the name of Babbage, is that supposed to be better?  I still
> > can't automatically merge binaries, so it's no advantage there.  So
> > what do I get if I do that?
>
> but you can't avoid having to do something equivalent to merging of
> opaque format binary files with CVS!
>
> If you must handle non-mergable files as source, and you want to use CVS
> for your mergable source, then it makes almost infinite sense to store
> the non-mergable files in some other revision tracking system!!!!!!
>
> > 1.  I get to maintain two version control systems in parallel.
> > 2.  I get to maintain a more complicated build system.
> > 3.  I get to try to keep the CVS stuff and the other stuff correctly
> > aligned.
> >
> > What I don't get is an easier way of managing binary files.
>
> You're looking at the world through CVS-only-eyes.  If you're having
> problems with non-mergable files in CVS then you should look outside CVS
> for a solution.  You might be pleasantly surprised at how much easier it
> makes your life in the long term!
>
> > However, I think you're wrong.  I have a simpler thing to do than manage
> > text-based sources in CVS and binary sources in another directory with
> > a more complicated build system:  I can put them all in CVS!  As long
> > as I make sure the -kb goes on (and this has not been a problem in my
> > shop), it's even simpler than hacking the build system.
>
> -kb is not the solution -- it just makes the problem harder!  If it
> didn't exist in the first place you'd never have gotten into this
> predicament.
>
> Why not just use RCS stand-alone for the binaries?  Making a build
> system that pulls a specified revision from an RCS file is trivial!
>
> If your non-mergable files are few and the changes to them infrequent
> then even carefully named directories will work just fine and make your
> build system even easier to manage!
>
> Why moan and complain about the impossible when a few tiny tweaks in the
> right placess will make all your problems easy to manage?
>
> --
>                                                       Greg A. Woods
>
> +1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
> Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>