[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.
Maybe.
> 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
Gee
- Re: renaming under CVS, (continued)
- Re: renaming under CVS, Noel Yap, 2002/02/26
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: renaming under CVS, Noel Yap, 2002/02/27
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: renaming under CVS, Noel Yap, 2002/02/27
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: renaming under CVS, Paul Sander, 2002/02/27
- Re: renaming under CVS, Greg A. Woods, 2002/02/27
- Re: CVS Update Behaviour, Nagy Gabor, 2002/02/25
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/26
- Re: CVS Update Behaviour,
Nagy Gabor <=
- Re: CVS Update Behaviour, Noel Yap, 2002/02/26
- Message not available
- Re: CVS Update Behaviour, Kaz Kylheku, 2002/02/25
- Re: CVS Update Behaviour, Arcin Bozkurt - Archie, 2002/02/22
- Re: CVS Update Behaviour, Paul Sander, 2002/02/22
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/22
- Re: CVS Update Behaviour, Noel Yap, 2002/02/22
- Re: CVS Update Behaviour, Greg A. Woods, 2002/02/22
- Re: refactoring under CVS, Noel Yap, 2002/02/23
Re: CVS Update Behaviour, Colm Murphy, 2002/02/25
Re: CVS Update Behaviour, Kaz Kylheku, 2002/02/25