info-cvs
[Top][All Lists]
Advanced

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

RE: CVS Version CHange


From: Greg A. Woods
Subject: RE: CVS Version CHange
Date: Tue, 2 Dec 2003 14:46:00 -0500 (EST)

[ On Tuesday, December 2, 2003 at 10:47:46 (-0500), Jim.Hyslop wrote: ]
> Subject: RE: CVS Version CHange
>
> If that's the case, then why was the revision number ever exposed in the
> first place? Is it a legacy of RCS or SCCS - do they not support symbolic
> tags?

I don't mean to answer for Larry, but I will put my two cents in:

It's almost impossible not to "expose" the RCS-Id in a system like CVS.

RCS obviously does support symbolic tags -- they are used to implement
CVS' symbolic tags.

SCCS does not support symbolic tags.  It would be almost impossible to
implement some of the internal features of CVS on SCCS, such as lazy
branch creation, let alone any of the tagging support (without also
using some additional database of sorts).  SCCS has a very rigid and
limited (though very simple, elegant, and reasonably easy to use),
revision, release, and branch numbering scheme dictated by the structure
of its ID numbers.  Many of us over the years have written and used, and
some of us still use, ad hoc front-ends to SCCS that give much of the
utility of CVS (handling trees of files uniformly, and even
copy-edit-merge concurrency).

> So are you saying that "cvs ci -r <revision number>" is a mistake and should
> not have been allowed?

Absolutely!  ;-)

However the authors of CVS-II were not afraid to expose/implement many
experimental features just to see how they might be used.  CVS
throughout its history has been a very experimental and evolving system.
There's always been lots of variety of ropes in and around it with which
one might hang one's self.

In CVS the release number of RCS-Id is like any useless and almost
atrophied organ -- however it's impossible to give it up without
also giving up backwards compatability of the internal repository
structure.

Perhaps CVS should just hide the "1." from view, though doing that in
the RCS keyword expansion would be fraught with problems too and it may
still be needed in many command-line parameters.  Perhaps translating it
into a symbolic value such as "TRUNK." wherever visible would be better.

> I agree that tags should be the _preferred_ way to do this, but I really do
> not see why you are so vehemently opposed to manually forcing revision
> numbers under special circumstances. What problems will this introduce?

I don't remember all the internal details of the issues but I do
remember that the first time I tried this silly trick as an experiment
those issues became quite obvious within a few moments of play.

> Again, under special circumstances, not under day-to-day use.

The problem is that once it's been done then it becomes an every-day
issue from then to the end of the life of the repository (unless it's
undone, of course).

> The major drawback with tags is that they can be moved or deleted, without
> any history of the changes.

If these sorts of things worry you then perhaps CVS is not the right
tool for your needs.  :-)

CVS is not very much of a policy enforcement tool, if any of one at all.
(despite the abilities of features such as "taginfo" scripting hooks)

RCS (and thus CVS) do not track changes to much of the meta information,
and, as you said in the text I deleted, there's a good deal of important
meta information kept by RCS that's not ``fixed'' in the internal
structure of an RCS file either.

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>




reply via email to

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