info-cvs
[Top][All Lists]
Advanced

[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 22:56:29 -0400 (EDT)

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

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

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

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.

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

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)

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.

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