Versioning CVS or RCS
Fernan Bolando
Do you guys recommend a full CVS versioning system for a personal
project? Or do you think I should use RCS initially and upgrade to CVS
when the project matures?
thanks in advance
,Fernan
Tristan Miller
In article <63dcfa28fbc76ba1...@news.teranews.com>, Fernan
Bolando wrote:
> Do you guys recommend a full CVS versioning system for a personal
> project? Or do you think I should use RCS initially and upgrade to CVS
> when the project matures?
As you probably already know, CVS is built upon RCS. However, I don't
believe that it's necessarily more complex for the sort of
functionality a small project would entail. Therefore if you are
selecting between the two, I'd say go for CVS. The CVS homepage has
enough documentation to get you up and running in no time.
Be aware that there are a number of rather annoying misfeatures with the
RCS/CVS model, such as lack of support for renaming files. There are
other free versioning systems which aim to correct the shortcomings of
CVS. I don't have any experience with them myself, but if anyone else
here does, I'd like to hear some thoughts.
One CVS replacement I'm aware of is GNU Arch:
http://www.gnu.org/software/gnu-arch/
Anyone used it?
Regards,
Tristan
--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Dave Neary
> Do you guys recommend a full CVS versioning system for a personal
> project? Or do you think I should use RCS initially and upgrade to CVS
> when the project matures?
If that's the only choice, then CVS, for sure. It's actually less work
than RCS, IMHO.
But if you're starting from scratch, you might want to look at
Subversion, a replacement for CVS which has worked around the most
annoying architectural problems in CVS, while keeping its way of
working.
As someone else said, Arch might be worth looking at. It's a changeset
oriented versioning system (like Bitkeeper), which can make it a little
trickier to get your head around initially than the central repository
based idea used in CVS and Subversion, but can reap benefits down the
line if you become a highly distributed organisation (each Arch working
copy is also a repository for others, which means you can do stuff like
check in on a laptop with no network, and then check a whole bunch of
changes into a central repository when you hook up).
Personally, I use Subversion for new projects, and CVS for older
projects.
Cheers
Dave.
--
David Neary,
E-Mail: bolsh at gimp dot org
Work e-mail: d dot neary at phenix dot fr
CV: http://www.redbrick.dcu.ie/~bolsh/CV/CV.html
lawrenc...@eds.com
>
> If that's the only choice, then CVS, for sure. It's actually less work
> than RCS, IMHO.
I'll second that -- CVS is easier to use than RCS.
> But if you're starting from scratch, you might want to look at
> Subversion, a replacement for CVS which has worked around the most
> annoying architectural problems in CVS, while keeping its way of
> working.
I'll second that, too.
-Larry Jones
Is it too much to ask for an occasional token gesture of appreciation?!
-- Calvin
Fernan Bolando
> Dave Neary <real.addre...@thisoneis.invalid> wrote:
>>
>> If that's the only choice, then CVS, for sure. It's actually less work
>> than RCS, IMHO.
>
> I'll second that -- CVS is easier to use than RCS.
>
>> But if you're starting from scratch, you might want to look at
>> Subversion, a replacement for CVS which has worked around the most
>> annoying architectural problems in CVS, while keeping its way of
>> working.
>
> I'll second that, too.
>
Thanks everyone for the replies. I doubt it that any of my current
projects will become a full organisational project so I have decided not
to opt for Arch. I just created a CVSROOT installation and it seems ok.
I will be trying to install subversion just to see the difference
between CVS especially the renaming and moving directories.
I have been reading some of the problems encountered with CVS which
opted the creation of subversion. It's strange that even though it's
been a long time since people noticed this problems how come they(cvs
developers) haven't fixed it. Anyway cvs is installed in most of the
distro that I have used that's why it's much easier for me to try it
before enything else. < think out loudly >
thanks again everyone.
,Fernan
Dave Neary
On Mon, 24 Nov 2003 22:42:33 GMT, Fernan Bolando said:
> I have been reading some of the problems encountered with CVS which
> opted the creation of subversion. It's strange that even though it's
> been a long time since people noticed this problems how come they(cvs
> developers) haven't fixed it. Anyway cvs is installed in most of the
> distro that I have used that's why it's much easier for me to try it
> before enything else. < think out loudly >
Part of the problem is that CVS very definitely put its eggs in the RCS
basket, and RCS only manages files (actually, it only really manages
text files well). Supporting copies and moves and so on implies
versioning directories and somehow keeping track of the origins of files
through namechanges.
There were efforts to fix CVS - notably DCVS and Meta-CVS - but given
that the problems are based on this architectural limitation, rather
than any omission of features, it is difficult to see how one could
address them and keep CVS compatibility.
Cheers,
Thomas Dickey
> Part of the problem is that CVS very definitely put its eggs in the RCS
> basket, and RCS only manages files (actually, it only really manages
> text files well). Supporting copies and moves and so on implies
> versioning directories and somehow keeping track of the origins of files
> through namechanges.
RCS stores binary files (it has, for quite a while).
CVS's limited notion of managing the parts list is unrelated to the
underlying storage mechanism of individual files. See PRCS, for instance.
> There were efforts to fix CVS - notably DCVS and Meta-CVS - but given
"efforts" is an apt description.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
TLOlczyk
<psych...@nothingisreal.com> wrote:
>One CVS replacement I'm aware of is GNU Arch:
>http://www.gnu.org/software/gnu-arch/
>Anyone used it?
In a recent article on lwn.net they mentioned arch, darcs, monotone
and Bitkeeper as alternates to CVS.
Can anyone explain the difference in "merge" philosophy between
these systems and CVS ( with it's copy/merge idiom ) and traditional
SCM's like SCCS,RCS, PVCS etc ( with their check-in/check-out idiom )?
You don't have to explain Bitkeepers philosophy, since someone on
lwn.net already explained it, but I would like clarification of it's
licensing.
----------------------------
The reply-to email address is olczy...@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess.
----------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Kaz Kylheku
> In article <qv2891-...@jones.homeip.net>, lawrenc...@eds.com wrote:
> > Dave Neary <real.addre...@thisoneis.invalid> wrote:
> >>
> >> If that's the only choice, then CVS, for sure. It's actually less work
> >> than RCS, IMHO.
> >
> > I'll second that -- CVS is easier to use than RCS.
> >
> >> But if you're starting from scratch, you might want to look at
> >> Subversion, a replacement for CVS which has worked around the most
> >> annoying architectural problems in CVS, while keeping its way of
> >> working.
> >
> > I'll second that, too.
> >
>
> Thanks everyone for the replies. I doubt it that any of my current
> projects will become a full organisational project so I have decided not
> to opt for Arch. I just created a CVSROOT installation and it seems ok.
> I will be trying to install subversion just to see the difference
> between CVS especially the renaming and moving directories.
Try Meta-CVS. It requires CVS which you already have. Meta-CVS
implements directory structure versioning, using CVS as a database to
store the file elements and a representation of the directory
structure. Meta-CVS is a small program written in a safe, very high
level programming language; consequently, it's very robust.
> I have been reading some of the problems encountered with CVS which
> opted the creation of subversion. It's strange that even though it's
> been a long time since people noticed this problems how come they(cvs
> developers) haven't fixed it.
CVS can be compared to, say, the SMTP protocol and the RFC-822 mail
format. You can't ``fix'' these things. At best you can tunnel richer
information content through them, as with MIME, UTF-8 encoding and so
on.
It's irrelevant that CVS doesn't do renaming, for instance. It does a
good job of storing a versioned set of files. It can commit changes,
navigate to arbitrary versions, merge repository material against
local changes and so on. Renaming can be done by something that uses
the capabilities of CVS as a lower layer.
Your hard disk doesn't support renaming either, or files for that
matter. Do the manufacturers have to fix anything? No; you use a block
driver and filesystem layer over top of the disk to give it the
structure you want.
As a rule of thumb: fix the *semantics* in a higher layer, and fix
*reliability* issues in the lower layer. A program like Meta-CVS can't
effectively work around, say, the lack of atomic commits, or
inefficient back end storage of binary files. These can be
independently addressed in the substrate.
dfg
> As a rule of thumb: fix the *semantics* in a higher layer, and fix
> *reliability* issues in the lower layer. A program like Meta-CVS can't
> effectively work around, say, the lack of atomic commits, or
> inefficient back end storage of binary files. These can be
> independently addressed in the substrate.
Where the hell have you been the last few years?!
Good to see you back. :-)
I changed my ISP and handle, so you won't recognize me. Doesn't matter
really.
lawrenc...@eds.com
>
> I have been reading some of the problems encountered with CVS which
> opted the creation of subversion. It's strange that even though it's
> been a long time since people noticed this problems how come they(cvs
> developers) haven't fixed it.
Because there aren't any developers, only volunteer maintainers who work
on CVS in their spare time, and they don't think the problems are
serious enough to justify the amount of effort it would take to fix
them.
-Larry Jones
I'm so disappointed. -- Calvin
lawrenc...@eds.com
>
> RCS stores binary files (it has, for quite a while).
But it doesn't handle changes very well. A small change in a text file
results in a small change to its RCS file whereas a small change in a
binary file can double the size of its RCS file.
-Larry Jones
I've got an idea for a sit-com called "Father Knows Zilch." -- Calvin
TLOlczyk
From what I have heard most of the CVS developers have gone over
to Subversion.
Fact is that for a long time CVS development just stagnated, sometime
around 1995/6. In fact I remember a "Windows" bug. If you sent a ^M
accidentally in a file, it would treat the file as a Unix file even on
Windows. So when you updated every line ended in ^M. Fixed that
one.
But once development stagnated, then restarted, it becomes hard
to make major architectural changes. Certainly marking files is
deleted is difficult, so you have to physically remove files from the
repoitory. Modifiying the entire history is difficutl, so you can't
move files and directories. Etc.
Consider the first problem. What do you do if you mark files
as deleted in a new version, with repositories created by the
old versions?
Les Cargill
>
> On Wed, 26 Nov 2003 05:13:01 GMT, lawrenc...@eds.com wrote:
>
> >Fernan Bolando <fernan...@mailc.net> wrote:
> >>
> >> I have been reading some of the problems encountered with CVS which
> >> opted the creation of subversion. It's strange that even though it's
> >> been a long time since people noticed this problems how come they(cvs
> >> developers) haven't fixed it.
> >
> >Because there aren't any developers, only volunteer maintainers who work
> >on CVS in their spare time, and they don't think the problems are
> >serious enough to justify the amount of effort it would take to fix
> >them.
> >
> From what I have heard most of the CVS developers have gone over
> to Subversion.
>
> Fact is that for a long time CVS development just stagnated, sometime
> around 1995/6. In fact I remember a "Windows" bug. If you sent a ^M
> accidentally in a file, it would treat the file as a Unix file even on
> Windows. So when you updated every line ended in ^M. Fixed that
> one.
>
I suppose this marks one of the great things *about* CVS. It didn't
seem to need a lot of updating at all. Absolutem obsoletum, I guess.
> But once development stagnated, then restarted, it becomes hard
> to make major architectural changes. Certainly marking files is
> deleted is difficult, so you have to physically remove files from the
> repoitory.
That should not have been necessary. I may be misremembering, but
I remember file "deletion" to have worked rather well.
This is really about the semantics of the "cvs remove" command.
> Modifiying the entire history is difficutl, so you can't
> move files and directories. Etc.
>
Is there ever a compelling reason to do so? In particular with
Unix, it's a simple matter to symlink "oddball" directories of files
to new places. DOS boxen get the "it runs the subst command again"
thing. :(
> Consider the first problem. What do you do if you mark files
> as deleted in a new version, with repositories created by the
> old versions?
I distinctly remember file "deletion" working rather well in CVS.
The repository file still existed, but was no longer
copied to a target directory past that point in time ( as
identified by a label, or top of the tree ) by "cvs update"/
"chekcout" et al.
>
> ----------------------------
> The reply-to email address is olczy...@yahoo.com.
> This is an address I ignore.
> To reply via email, remove 2002 and change yahoo to
> interaccess.
> ----------------
> Thaddeus L. Olczyk, PhD
> Think twice, code once.
--
Les Cargill
lawrenc...@eds.com
>
> From what I have heard most of the CVS developers have gone over
> to Subversion.
You've heard incorrectly.
> Fact is that for a long time CVS development just stagnated, sometime
> around 1995/6. In fact I remember a "Windows" bug. If you sent a ^M
> accidentally in a file, it would treat the file as a Unix file even on
> Windows. So when you updated every line ended in ^M. Fixed that
> one.
Your memory also seems to be faulty -- no such bug ever existed (CVS has
never inferred the file format from the contents). Yes, development has
in a sense stagnated, but that's because CVS *works*. If it ain't
broke, don't fix it.
> Consider the first problem. What do you do if you mark files
> as deleted in a new version, with repositories created by the
> old versions?
A problem CVS solved long ago. ("Death" support was added in CVS 1.5,
the current stable release is 1.11.9.)
-Larry Jones
Even if lives DID hang in the balance, it would depend on whose they were.
-- Calvin
Kaz Kylheku
> But once development stagnated, then restarted, it becomes hard
> to make major architectural changes. Certainly marking files is
> deleted is difficult, so you have to physically remove files from the
> repoitory. Modifiying the entire history is difficutl, so you can't
> move files and directories. Etc.
Directory structure versioning is implemented in a separate program
called Meta-CVS which uses the services of CVS.
Some Meta-CVS operations are fairly thin wrappers around CVS. For
example if you invoke ``mcvs diff path/to/file'', Meta-CVS translates
the ``path/to/file'' to the element ID name, changes directory to its
internal CVS sandbox, and invokes ``cvs diff <name>'' where <name> is
the machine-assigned ID of the file that is known to CVS.
Some Meta-CVS operations that have CVS counterparts are actually quite
different. For example, ``mcvs rm'' does not call ``cvs rm''. Rather,
it performs an editing operation on the directory structure map. The
element being removed is not touched at all, it is just unlinked from
the directory structure, similarly to the way a file deletion in UNIX
is really a case of unlinking an inode from a directory. The ``mcvs
add'' command handles recursion, identification of new file suffixes
and assignment of 128 bit element ID's, so although it looks a lot
like ``cvs add'', it really isn't.
And then there are operations that don't exist in CVS at all, like
``mcvs mv'' for renaming or ``mcvs ln'' for making versioned symbolic
links.
> Consider the first problem. What do you do if you mark files
> as deleted in a new version, with repositories created by the
> old versions?
That's like asking: what if I edit some document made by a 10 year old
version of my word processor? How do I make changes and save that in
the old format? Well, gee, if the old format doesn't support the new
kinds of content you created in the document, saving to the old format
just not going to happen, unless you are willing to lose a lot of
information!
In any case, CVS does support deletion. The ``cvs rm'' command creates
a new revision which is marked ``Dead'' via the state property. When
you update to a dead revision, the working file disappears. If you had
some ancient CVS installation that didn't understand the semantics of
the Dead state, it would probably just ignore that information and
re-create that file, thereby subtly breaking the integrity of the
baseline.
There are problems with corner cases in file addition and removal in
CVS, but the new program Meta-CVS side steps all of them.
From the Meta-CVS point of view, I just want CVS to be stable, and to
address performance and reliability issues transparently---at least at
the command line interface level. I don't need CVS to try to add a
redundant rendition of symbolic link support or directory structure
versioning, but, say, atomic commits would be nice, as would be more
efficient storage of binary files.
It helps to view CVS as, effectively, a platform for building version
control systems. If you just use CVS by itself, you are using the
naked platform, which is why things sometimes get nasty. :)
Thomas Dickey
> Thomas Dickey <dic...@saltmine.radix.net> wrote:
>>
>> RCS stores binary files (it has, for quite a while).
> But it doesn't handle changes very well. A small change in a text file
"very well" can be qualified by pointing out that you're assuming different
characteristics of the "text" and "binary" files, and therefore adopting a
different measure of "small change".
If the "text" file doesn't have a reasonably large number of line-separators,
none of RCS/etc., perform well.
For instance, there are (legal, of course) html files that contain no
line-separators at all. If I change one character in that, it doubles
the size of the 2-delta file.
Obviously CVS is unsuited to managing them, right?