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

[Noel L Yap]

>[ On Thursday, July 12, 2001 at 20:51:00 (-0400), Noel L Yap wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> The key word here is avoid,  No system can ever prevent concurrent edits.>
>
>Huh?  If there's no branching support, and no concurrent editing
>support, how are you going to do a concurrent edit?
>
>Note that I'm talking about this from the point of view of the
>repository itself.  Sure a luser could make an edit in an unlocked file,
>but such a system will not permit it to become a part of the repository.

I'm using the term "system" in a broad way.  It's not limited to the source
control tool.  It includes processes.

>> So stable that you'd never have to fix a bug (and thereby have to create a
bug
>> fix branch)?
>
>In the case of Aegis, yes, that's exactly the design goal.
>
>Aegis does support a form of branching now though.....

I don't see how any system (let alone tools) can ever absolutely guarantee no
bugs.  If it can, then it might as well guarantee no security holes.

>What I've been trying to allude to is the fact that at least some of the
>more commonly discussed non-mergable files, i.e. icon image files and
>the like, are not necessarily ever in a position where merges will ever
>be needed.

If this is true, then there's no harm keeping them in CVS.

>Think about it.  If you've got a bug-fix branch in your source code
>which versions of the icons are you going to use?

It depends.


>  You'll either use the
>current revisions, or the revisions that were used in the release being
>fixed, depending on what changes were made to the current revisions.

Or something completely different.  It depends.

>If
>you need to use only some of the current revisions then you won't be
>doing merges and such to copy those changes over, you'll either have the
>"graphics group" (virtual or real) create a consistent set of new
>revisions for the bug-fix branch.  How they store these revisions is
>irrelevant just so long as your build can specify them for the builds
>done on the bug-fix branch, and so long as the builds for the "current"
>development branch (and any other branches) still get the right
>revisions they need.

Yes, and using a version control tool like CVS is one way to get those
revisions.

>None of this is any different whatsoever from creating a build
>environment where you've got several versions of some third-party
>object-only library installed on your build machines.
>
>Eg. you have:
>
>    /usr/local/libmotif-1.1/lib/libmotif.a
>    /usr/local/libmotif-1.2/lib/libmotif.a
>    /usr/local/libmotif-2.0/lib/libmotif.a
>    /usr/local/libmotif-2.1/lib/libmotif.a
>
>In your Makefile(s) you have:
>
>    MOTIF_VER=     1.2
>    MOTIF_LIB=     /usr/local/libmotif-${MOTIF_VER}
>    LDFLAGS=  -L${MOTIF_LIB}
>
>(and similar stuff of course for the associated header files)

This is one way to do it.  Some would use a version control tool.

>When you check out the bug-fix branch you don't suddenly want to be
>linking against Motif-2.1!  You'll simply leave MOTIF_VER alone unless
>of course one of your bug fixes is explicitly to update the code so that
>it can properly use the latest Motif libraries.

Or the library can be labeled with something the rest of the source is.
Granted, CVS may not be the best tool for this job, but it is usable for some
shops.

Noel



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.