[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS Update Behaviour

From: Nagy Gabor
Subject: Re: CVS Update Behaviour
Date: Tue, 26 Feb 2002 14:22:09 +0100
User-agent: Mutt/1.3.27i

On 02-Feb-25 17:54, Greg A. Woods wrote:
> > When I discovered cvs did not know this, I was puzzled, and sad.
> I am puzzled and sad that you could not figure this out on first meeting
> and learning CVS.  It really should be as self evident as it is well
> documented in the manual.

That's where I found it. I figured it out the first time I tried to use
this feature.

> You really need to learn more about how CVS works internally.


> If you had chosen CVS because RCS was insufficient for your needs then
> I think you would be happy not to have such a mapping layer.  CVS handles
> renames by way of removing and adding files.  No history is lost, but
> also no complications are introduced by such a mapping layer.

I never used RCS. I was looking for a version control system for my own
stuff after using PVCS in my job. I also used VSS later for something else.
For my Linux CVS appeared to be the best choice, supported, documented,
lot of people using it.

If I don't use CVS, which version control system would you suggest which
is free, and does all what I want? (OK, I'll check metacvs out)

> Implementing a mapping layer in CVS will hurt CVS.  It is impossible to
> implement such a mapping layer without destroying backwards
> compatability.

I don't know the internals enough. I don't really care about backward
compatibility. Surely it has to be a possibility for people who need that.

> CVS is highly valued by many of its users because it
> simply automates what can be done tediously with RCS alone.  This means
> that CVS does not implement a "proprietary" repository format that
> cannot be moved with ease to other tools that understand the same
> format, and indeed the RCS format is widely understood both by tools and
> by humans.  It is stable and quite capable for the basic requirement of
> the job.

OK. I don't know how hard it would be to implement this, what the
implications were. If you say, it would be inefficient, I would accept that
answer. If you say that "you don't need that feature", that's silly.

Thanks for the answer

reply via email to

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