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

[Steven Rosenstein]

Greg,

Given all that you've stated below, it seems that the crux of your argument
turns on the ability of a file to be "mergable".  In my unadorned, pooh-like
brain, I ask the simple (and rhetorical) question, "why?"  Why can't I have a
simple switch which tells CVS that for this file or this directory or this
repository, I simply want to turn merging (and all CVS file manipulations)
*off*.  Period.  Nothing more.

What I am in effect asking of CVS is to simply keep track (via comments in the
log files) of the addition of newer and newer versions of non-mergable files,
where each new addition would completely overwrite (with one caveat) the
existing version.  The caveat would be the retention of version history appended
as a header and/or trailer to the file.  I would expressly waive the ability to
view any changes between versions of the non-mergable file, and when I tag a
release, I would have the full understanding that any future checkouts or
exports of that tag would return the *current* version of the non-mergable file,
and not necessarily the version of the file that existed at the time the tag was
applied.

I have a web application where 95% of the files (mergable and non-mergable) are
provided by a third-party vendor.  I am using CVS for mainly audit purposes to
keep track of the new versions of the files as we receive them from the vendor
and **WHERE POSSIBLE** display the differences between the various versions of
the mergable files.  Whenever we receive updates I import them into the
repository (applying copious comments), and I'm developing quite a meaningful
history of vendor modifications.  When one of my developers makes a change to a
vendor-supplied, mergable file, CVS handles tracking and integrating those
changes admirably.

CVS is an extraordinarily serendipitous tool.  To me, it *is* the best
application for my needs, and the cost (both $$$ and intellectual) is very
reasonable.  Please be understanding and accepting of my and other folks ways of
using CVS.  IMHO, confining CVS to simply being an easy and automatic means to
perform three-way merges between revisions is to do a dis-service to all of the
time an effort obviously spent on developing the rich set of features available
in system.

--- Steve





address@hidden (Greg A. Woods) on 07/12/2001 07:59:36 PM

Please respond to address@hidden (Greg A. Woods)

To:   Lan Barnes <address@hidden>
cc:   CVS-II Discussion Mailing List <address@hidden> (bcc: Steven
      Rosenstein/FTCI)
Subject:  Re: How well does CVS handle other types of data?




[ On Thursday, July 12, 2001 at 15:59:25 (-0700), Lan Barnes wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> You've made your position abundantly clear, and yet I still do not
> understand your ideas -- nor your vehemence. So what is left is that we
> disagree.

It's really very very simple.  Perhaps the problem is that these issues
are actually simpler than many people want them to be.  Various people
continue to try to suggest the impossible, and then refuse to accept the
plain simple facts.  You appear to be among them.  You cannot have your
cake and have eaten it too!  You can't have good support for change
management of non-mergable files in a version control system who's very
design and core functionality hinges on the ability to easily and
automatically do three-way merges betweeen revisions.  The more
unmergable files you add to a normal (i.e. a non-vendor-branched) CVS
repository, the more likely you'll run into increasingly difficult
problems.  The fewer unmergable files you have the easier it is to treat
them as special cases.

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