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: Thornley, David
Subject: RE: How well does CVS handle other types of data?
Date: Fri, 13 Jul 2001 09:25:58 -0500

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> 
> [ 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?
> 
That I don't think putting nonmergeable files into CVS is bad, that I
don't have problems with it, and that I'd really like to find out if
there is any reason not to.  So far, I've gotten a lot of emotion, and
an assumption that I must certainly be having problems, since I'm doing
the Wrong Thing.  

> > 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!
> 
I'm not saying CVS should merge unmergeable files, I'm saying that
nothing does, and so I can't seriously complain that CVS can't.
As far as I can tell, CVS does an acceptable job of handling binaries.
It could be better, but I don't see how any system is supposed to
do significantly better.

> > 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!
> 
Right.  You're so right, especially if you drop the last two words.  I
can't avoid having to do something equivalent to merging of opaque format
binary files.  This is not so much a matter of concurrent development
as it is a matter of branches.  We are going to have branches, and I can't
change that just because it can be inconvenient with a small fraction of
our controlled files.  Since we have branches, we will come across the
merging the unmergeable file problem; unless I dream the impossible dream
of something that will do that for us, we will have to confront it when
it happens.  We can handle it.  It will occur, regardless of how we manage
our source.

> 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!!!!!!
> 
Again, a very flat statement with no reason I can see.

> > 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!
> 
I'm not having problems with non-mergeable files in CVS that I
wouldn't have without CVS.  If you can point me to a better tool, I'm
listening.  It does have to support branching, because we can't do
without branches.

> > 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.
> 
I'm sitting here quite comfortably in my swivel chair, and people
keep telling me that I've got problems and predicaments.  I want to
see evidence that I've got a problem.

> 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!
> 
Why just RCS stand-alone?  That doesn't merge them between branches,
does it?  If not, why should I use something different?

> 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!
> 
If my nonmergeable files are few and the changes infrequent CVS works just
fine, and that will make my build system even easier to manage than if I
use carefully named directories.

> Why moan and complain about the impossible when a few tiny 
> tweaks in the
> right placess will make all your problems easy to manage?
> 
Because, so far, nobody's shown me how to make my problems, such as they
are, easier to manage than if I just use CVS.

Let's go through a possible scenario.  We cut off a release_12 branch.
Joe works on a feature we've promised for release 13, and checks in his
work, including changes to a binary file.  Sara works on a bug left in
release 12, fixes it, including changes to that binary file, and checks
it in.  Sara then has to merge it.  She merges, and gets a conflict on
the binary file.  This is a pain, since she has to take care of that
somehow, but I fail to see that it is an avoidable pain.

If we have the binaries in carefully named directories, then Joe changes
the binary in the head branch directory, Sara changes it in the release 12
directory, and promptly overwrites Joe's change when she merges to head.
If we use RCS files in carefully chosen directories, then we've got Joe's
version and Sara's version, and we've still got to merge them somehow.

The only way we can avoid merging such files, it seems to me, is not to have
branches.  For reasons I won't go into deeply, this is not an option.  We
sell
very complex software and have to maintain different releases (yes, that's
a pain, but right now that's the way it is).  Managing changes to several
different releases without VCS branching would require manual branching
and merging.

So, if we are to avoid the necessity of merging unmergeable files we have to
avoid having branches somehow, which isn't going to happen.  This means
we'll
have to merge these from time to time, where what I mean by merging is
selecting one or the other or creating a new one that fits the purpose.
Given that, I see no reason not to use CVS.



reply via email to

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