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

[Mike Castle]

On Thu, Jul 12, 2001 at 04:26:59PM -0400, Greg A. Woods wrote:
> [ On Thursday, July 12, 2001 at 08:22:54 (-0700), Mike Castle wrote: ]
> > Except that that is a bit of a pain in the ass to support for remote
> > access.
> 
> Why?  Surely you can think of other ways of copying files across a
> network.  That's something people have been doing with networks since
> they day they were invented....

And it is one that cvs supports VERY well.  Why should I have to have two
solutions for the same problem of working remotely?  cvs and scp or rsync
would work together well.  But, the difficulty of creating that system is
more likely more hassle than dealing with the limitations of cvs.

> > And you still have the same damned merging problem.  Now it's just down to
> > one line of text representing what binary file to pull in during the build
> > process.  The problem has not been solved doing this.
> 
> That's the point.  You push the merging issue out to a place where it
> can be solved with more appropriate tools.

I'm not even talking about that.

Obviously you have to have some sort of mapping in side cvs (in a text
file) that points to the correct versions of the binary file.

for instance, say we have a listing such as:

manual=manual-2001-03-07.doc

In one branch is gets changed to
manual=manual-2001-03-09.doc

And in another branch it gets changed to:
manual=manual-2001-05-13.doc

That is still a merge problem.  CVS marks it as a conflict.

I don't see how this is any better than the current cvs behavior of
presenting two versions of the files in question to the user.

mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc