[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: Mike Castle
Subject: Re: How well does CVS handle other types of data?
Date: Fri, 13 Jul 2001 11:47:27 -0700
User-agent: Mutt/1.3.18i

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:


In one branch is gets changed to

And in another branch it gets changed to:

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.

     Mike Castle      address@hidden
    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

reply via email to

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