Discussion:
Attic Behavior
Lummoxx
2011-01-07 14:07:09 UTC
Permalink
Hi,

Is there any reason for a file that is in the Attic to NOT show state
as dead for any of its revisions?

I have shell access to the repository. When I look at the ,v file,
none of the revisions show "state dead", they are all "state Exp", yet
the file is in the Attic.

When doing a checkout of HEAD, the file is not checked out. When the
repository is browsed using ViewVC, in that directory, the file is
displayed as if it is alive (the option to hide dead files is active).

Attempts to restore the file via normal means (add then commit) do not
work, it returns the error "added independently by second party".

I'm the only one with shell access, and I know I didn't move the file
manually into the attic, so I hesitate to manually move it out. The
repository has a lot of tags defined, and I do not want to break any
of the tags by moving the file.

Am I missing anything simple, or is this truly some weird bug/error
I've stumbled across?

Thanks!
Todd Denniston
2011-01-07 15:08:01 UTC
Permalink
Post by Lummoxx
Hi,
Is there any reason for a file that is in the Attic to NOT show state
as dead for any of its revisions?
I have shell access to the repository. When I look at the ,v file,
none of the revisions show "state dead", they are all "state Exp", yet
the file is in the Attic.
IIRC if the file was created on a branch, then the ,v file exists in the Attic instead of the normal
directory.

IIRC when the file is merged on to the trunk then CVS should move the ,v file from the Attic to the
normal directory.
Post by Lummoxx
When doing a checkout of HEAD, the file is not checked out. When the
repository is browsed using ViewVC, in that directory, the file is
displayed as if it is alive (the option to hide dead files is active).
The file is not being checked out on the HEAD revision, because it only exists on a branch.
Post by Lummoxx
Attempts to restore the file via normal means (add then commit) do not
work, it returns the error "added independently by second party".
Because it was "added independently by second party" on a _branch_.
Post by Lummoxx
I'm the only one with shell access, and I know I didn't move the file
manually into the attic, so I hesitate to manually move it out. The
repository has a lot of tags defined, and I do not want to break any
of the tags by moving the file.
IIRC (grab a handful of salt) Moving the files by hand (with the command line) from the Attic to the
directory that contains the Attic will not break CVS or anything that it tracks. However now the
files will get processed (looked at) even by CVS processes working on HEAD, even though they don't
need to spend CPU time on it, i.e., Attic is ONLY an optimization to tell the CVS server that if it
is only working with HEAD, then it does not need to consider files that do not exist on the HEAD
(i.e. Dead and branch only files).

If you want the files on the HEAD, someone should
A) talk with who ever committed them to a branch to understand why.
B) figure out which branch.
C) figure out what ALL the changes on the branch are.
D) talk with management and see if they are ready for all, some or none of the changes on that
branch to be merged back into the trunk.
E) In Accordance With the output of (D), do a merge from the branch to the head.
F) verify the checkout still passes all of the tests it should.
Post by Lummoxx
Am I missing anything simple, or is this truly some weird bug/error
I've stumbled across?
Thanks!
Only simple when you have read the source and this list for years. :)
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
Lummoxx
2011-01-07 15:37:01 UTC
Permalink
Todd,

Thanks for the comprehensive answer. Unfortunately, I looked at the
tag/branch aspect of it...and it still didn't fit the behavior I was
seeing. Like, how can a file be in the Attic *at all* when not a
single state within the ,v file indicates a "dead" revision?

As it usually happens, shortly after throwing in the towel and asking
a list...I had an "aha!" moment, and I figured out what caused it.

The original file name was file.foo. Someone then added the file
File.foo (case). The repository is on *nix, apparently the client is
Windows, and some revisions went into one file, and some revisions
went into the other.

Doesn't matter how many times I say not to do that...

Thankfully, it's not on me to combine them back together and fix it, I
just admin the server. :)

Thanks again!

On Fri, Jan 7, 2011 at 10:08 AM, Todd Denniston
Post by Todd Denniston
Post by Lummoxx
Hi,
Is there any reason for a file that is in the Attic to NOT show state
as dead for any of its revisions?
I have shell access to the repository.  When I look at the ,v file,
none of the revisions show "state dead", they are all "state Exp", yet
the file is in the Attic.
IIRC if the file was created on a branch, then the ,v file exists in the Attic instead of the normal
directory.
IIRC when the file is merged on to the trunk then CVS should move the ,v file from the Attic to the
normal directory.
Post by Lummoxx
When doing a checkout of HEAD, the file is not checked out.  When the
repository is browsed using ViewVC, in that directory, the file is
displayed as if it is alive (the option to hide dead files is active).
The file is not being checked out on the HEAD revision, because it only exists on a branch.
Post by Lummoxx
Attempts to restore the file via normal means (add then commit) do not
work, it returns the error "added independently by second party".
Because it was "added independently by second party" on a _branch_.
Post by Lummoxx
I'm the only one with shell access, and I know I didn't move the file
manually into the attic, so I hesitate to manually move it out.  The
repository has a lot of tags defined, and I do not want to break any
of the tags by moving the file.
IIRC (grab a handful of salt) Moving the files by hand (with the command line) from the Attic to the
directory that contains the Attic will not break CVS or anything that it tracks.  However now the
files will get processed (looked at) even by CVS processes working on HEAD, even though they don't
need to spend CPU time on it, i.e., Attic is ONLY an optimization to tell the CVS server that if it
is only working with HEAD, then it does not need to consider files that do not exist on the HEAD
(i.e. Dead and branch only files).
If you want the files on the HEAD, someone should
A) talk with who ever committed them to a branch to understand why.
B) figure out which branch.
C) figure out what ALL the changes on the branch are.
D) talk with management and see if they are ready for all, some or none of the changes on that
branch to be merged back into the trunk.
E) In Accordance With the output of (D), do a merge from the branch to the head.
F) verify the checkout still passes all of the tests it should.
Post by Lummoxx
Am I missing anything simple, or is this truly some weird bug/error
I've stumbled across?
Thanks!
Only simple when you have read the source and this list for years. :)
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
Larry Jones
2011-01-07 16:28:26 UTC
Permalink
Post by Lummoxx
Thanks for the comprehensive answer. Unfortunately, I looked at the
tag/branch aspect of it...and it still didn't fit the behavior I was
seeing. Like, how can a file be in the Attic *at all* when not a
single state within the ,v file indicates a "dead" revision?
That shouldn't happen, but there were some bugs in CVS (mostly fixed
long ago) that would cause it to not move the file out of the Attic
under some circumstances when it should have.
--
Larry Jones

I think football is a sport the way ducks think hunting is a sport. -- Calvin
Arthur Barrett
2011-01-07 20:14:23 UTC
Permalink
Post by Lummoxx
The original file name was file.foo. Someone then added the file
File.foo (case). The repository is on *nix, apparently the client is
Windows, and some revisions went into one file, and some revisions
went into the other.
You may want to consider CVSNT on the client (and probably on the linux
server too). I used to see this happen all the time with older CVS 1.x
servers and clients, but not since I've been using CVSNT 2.5 and 2.8
(yes all our repositories are on linux).

Loading...