[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: Noel L Yap
Subject: RE: How well does CVS handle other types of data?
Date: Thu, 12 Jul 2001 20:51:00 -0400

>> From: Lan Barnes [mailto:address@hidden
>> I really fail to see the technical reason for deprecating using CVS
>> archives to store -- and tag -- binaries necessary for a build. The
>> disk space involved is a nonissue for us (space is cheap), and the
>> issue of avoiding simultaneous edits exists under any system.
>No, it most certainly does not!  Systems that do not support branching
>and concurrent editing automatically avoid the issue in the first place!

The key word here is avoid,  No system can ever prevent concurrent edits.

>Perhaps you should look at Aegis, and BCS too....  or any versioning
>system that does not support concurrent editing and branching and/or
>which is based on the primary concept of maintaining one stable baseline.

So stable that you'd never have to fix a bug (and thereby have to create a bug
fix branch)?

>I think you're missing the point.  CVS does not fully support
>non-mergable files.  Period.  It cannot, by the very virtue of its
>design goals!  What little support it gives is completely misleading
>and almost always leads to future problems!

Like I said before, "source code isn't CVS-mergable in the strictest form of the
word".  If they were, then CVS would be able to merge them even in lieu of
massive reformatting.

>So put your non-mergable files in some other tracking system (even one
>so simple as to use pathname-based identifiers), and modify your build
>system sources (eg. scripts and makefiles) so that they will implicitly
>match up your CVS tags with the identifiers used for the non-mergable
>file repository!  Doins this is so simple it's child's play and it
>completely and totally avoids all issues with binary file handling in CVS!

And pushes it off for something that doesn't handle the situation, either.  The
situation is best handled through a process that would avoid multiple lines of
development, not through technology that prevents its resolution.  Manual
"merges" are still necessary to catch what slips through.

A good example is something that can be done in ClearCase (in theory, anyway,
I've never had the occasion to do it) where you can manually merge two versions
of a file, then explicitly tell ClearCase that there was a merge, which versions
were involved, and what was merged into what.  CVS doesn't keep track of merges,
so in CVS, all you'd have to do is the manual merge (and keep track of it
through some other means).
Why do you keep proposing a solution where nobody else sees a problem?


This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

reply via email to

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