[Top][All Lists]

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

Re: Why is this file stuck in the Attic?

From: Kaz Kylheku
Subject: Re: Why is this file stuck in the Attic?
Date: 13 Feb 2003 16:39:06 -0800

address@hidden wrote in message news:<address@hidden>...
> Hi,
> I have an associate that managed to get some files stuck in the Attic and
> I want to be sure I explain the reason correctly.  I've appended the
> interesting parts of the history and log commands.

This is some kind of bug. The file was clearly resurrected, acquiring
a non-dead revision on the main trunk. This should have been
accompanied by a move out of the Attic.

> My interpretation is that at revision 1.7, the file was deleted and moved
> to the attic by one user.  The second user then explicitly pulled a copy
> of the "missing" file, made changes and checked the changes in.  This file
> stayed in the Attic, as it should have, and remained invisible to normal
> cvs checkout and update commands.  Is this correct?

A dead file can, in principle, be only resurrected by a ``cvs add'' on
an object having the same path name. It sounds like the resurrection
somehow happened differently, as a result of a race condition between
a delete done by one user and a commit done by another. This is one of
those corner cases of CVS that this page refers to:

> What I don't understand is why the state for revision 1.8 and so on did
> not remain dead.

A dead state is the result of a commit after ``cvs rm''. There should
not be a sequence of dead states; if any new revision is created in
sequence after a dead state, it should be a non-dead state, because
the only reason for creating a new revision would be to resurrect the

You should repair this situation by moving the file manually out of
the Attic. Also note that the file *will* be checked out if you use a
-r option to select a revision. To check out the main trunk, you can
use this:

   cvs co -r HEAD ...

when you run CVS this way, it ignores the Attic optimization, and
looks into the Attic directories to find all files.

I think that this should become the default behvior of CVS; the Attic
optimization should be deprecated, and eventually scrapped. CVS should
continue to understand and process the Attic directories for backward
compatibility, but not generate them.

The whole reason for Attic directories is to shorten the directory
scan times when updating or checking out the main trunk. More
importantly, Attic eliminates the need to open an RCS file, parse it,
and determine its head revision, only to find that the state is dead.
This optimization could be achieved without the Attic directory: a
cache structure could be kept somewhere in some text files which would
tell CVS what files to ignore because they are dead on the main trunk.
Such a cache could just be blown away if it was suspected that its
contents are misleading.

reply via email to

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