[ On Friday, February 18, 2000 at 09:32:06 (-0800), |}avid (opeland wrote: ]
> Subject: Re: Why does CVS treat removed files so specially?
>
> YES. I consider the removal of a file as a new revision of that file. So does
> CVS. I simply want it to apply to concept of tagging, stat, and log to the
> head revision of removed files just as it does to non-removed files. In other
> words, removing a file is NOT a special case.
CVS doesn't use tags that way. It cannot in order to support the
features I described previously.
> We are NOT doing multiple lines of development, but enacting a process WORKFLOW
> which says that files are in a different state at different times. Whether or
> not the file is present or not doesn't (and shouldn't) matter.
Branches accomplish the same goal (though perhaps with a different approach).
> If I had removed the tags, as you suggest, the file would be removed from live,
> and this does not support our process.
That's why you need to use branches with CVS. Your "live" product is
essentially a release and if it is created on/from a release branch then
you can easily have the file removed in the "development" branch without
having it removed on the release branch. Note also that the release
branch is in effect the "staging" area and the final tag placed on the
release branch is what defines the "live" version. The only tags you
would place on the develpment brans (i.e. the trunk) would be the base
tags that identify the forking of a new release branch.
> > > I find it hard to believe that the
> > > implementors INTENDED to have cvs commits not affect removed files.
> >
> > Now I'm really confused. A moment ago you were talking about tags. Now
> > you you say "commits".
>
> I meant to say "cvs commands". My bad.
Whew! OK, I understand.
The answer's the same though -- CVS commands, except when examining
historical views, must not affect removed files and this is absolutely
intentional. To do otherwise would be a kind of time travel that would
make the state of the file unknowable at the present time. The only way
you can do this is by creating a branch and then removing the file only
on one of the branches. This way the file can exist, and not exist,
simultaneously but with the definition required to keep the history of
the file across time consistent.
Think of what some SF writers envision when they talk about alternate
histories: The deletion of the file causes a fork in history -- one
branch where the file continues to live, and the other where it dies and
the future is different down each fork in time. In CVS though you have
to actually manually create the fork, if you want it, as otherwise there
can only be one future. Of course in CVS you still have to fork the
entire universe (module) -- not just one file! :-)
> Not that I've seen. It seems to work exactly as I want it to. It's just that
> to tag the dead revision, I have to run a different command than I do to tag a
> non-dead revision. This is inconsistent and I see no need for it.
You are not seeing the whole picture.
> I'm not sure why you insist that dead revisions "cannot" be tagged and that
> doing so will put the repository in an "unstable" state. I have empiricly seen
> that this is not so.
Tagging a removed file would mean that the file in fact was not
removed. You cannot both have a file in existance, and have it removed,
at the same time unless you use branches.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
