Re: Attic cleanup

[Paul Edwards]

"Mark D. Baushke" <mdb@cvshome.org> wrote in message 
news:mailman.7581.1055157691.21513.bug-cvs@gnu.org...
> > > > Either that, or create an Attic for every directory.  No exceptions.
> > >
> > > Feel free to create an Attic directory for all directories if that makes
> > > you happy.
> >
> > Ok, so if I submit a patch to create a mandatory Attic for every
> > directory, so that the repository is more consistent, it will be
> > accepted?
>
> I probably would not bother to commit such a change, but that does not
> speak for any of the other developers. I don't see it as a big deal to
> go thru and do anything special with the Attic directory unless we want
> to just remove them completely from CVS...

I didn't say it was a big deal.  I just said it conformed to my idea
of what neat and tidy is.

> > > Over time that is what I expect will happen to most
> > > repositories.
> >
> > I would have thought that it would look more consistent if the only
> > directories that had Attic files were ones with obsolete files.
>
> I guess I just don't get it. What would look more consistent? The
> extneral view of the file versions is the same regardless of the
> existence of the Attic directory, or am I missing something?

You're missing bugs.  Code is going to be invoked to handle
Attics.  Code that shouldn't be invoked, when the temporary
dead file is long gone.  There's no reason to leave it sitting
around, this directory that requires special processing to handle.

> At most your original patch to remove the directory reduces the need to
> do an extra stat() call or two when doing work from a tag or a branch. I

In fact, it removes all exceptional processing that doesn't happen
in any other directory.  So when a user says "my repository works
except for this one directory", the word "Attic" doesn't spring to
mind, assuming their system is consistent.

> suppose you could argue that doing so reduces the processing time for a
> given directory. That would certainly be a more pragmatic reason for
> your change than you have provided so far.

The pragmatism is avoiding exception coding.

> To be honest, I'd rather not try to worry about if the system
> administrator is using a filesystem that provides ACLs that allow users
> to add new directories, but not to remove old ones or not.
>
> I also do not see an easy way from a cvs command viewpoint to determine
> in sanity.sh that the Attic directory is being removed if that is what
> is considered proper. Part of our changes to cvs is to try to not do
> harm to existing installations and to create test cases for each change
> that is introduced.

It isn't harm, by definition.

> Would it really be an error if the user doing a
> commit that resurrects the last file from the Attic not to be able to
> remove the Attic directory? If it is not an error, then why do it and
> risk causing a problem with the user's commit?

It isn't an error.  I didn't say it was.  I said it was inconsistent.

> Do you have tests for all of the various kinds of filesystems to make
> sure that the code works on all of them? (UFS, FAT12, FAT16, FAT32, AIX,
> EXT2, HPFS, Plan9, QNX4, EXT3, NTFS, NFS, HFS+, AFS, etc. ?)

No, just like there aren't tests to make sure empty Attics don't
cause problems.

> An adminsitrator could as easily have a crontab job that did something like:
>
>    find $CVSROOT -name Attic -a links 2 -a -type d -print0 | xargs -0 rmdir

That is technically incorrect because it makes assumptions about
the internal structure of a CVS repository.  How does he know
that those directories aren't required?

> or the equivalent for their repository if they wanted to do this. Of
> course, on a filesystem which is not UNIX, the number of links may have
> to be adjusted. Not all filesystems types provide "." and ".." for every
> directory, so that can be a problem too...
>
> > But I've got a fairly warped idea of what "neat and tidy" is.
>
> Possibly. Maybe my idea is warped. I suppose it is a matter of
> perspective. Why are you bothering to look into the cvs repository
> directly?

I look when I have weird problems.  And I don't like seeing
two directories, which I expect to be identical in nature, to be
different in nature.

> > > However, it is intended to be a lazy binding rather than
> > > immediate, just like the cvs 'magic branches' that reserve, but do not
> > > create an RCS branch to match a CVS branch.
> >
> > Empty Attics mean only one thing - inconsistency.  If one directory
> > has an empty one, and the other doesn't, it doesn't make any sense
> > at all.
>
> It just means that somewhere in the versions of your files for such a
> directory there is a time where a particular file version shows that it
> was in the dead state.

That was history.  Of no interest to me now, when I know that
everything should be the same and consistent.  Currently, we
have no dead files on branches, everything has been imported,
the historical reasons have gone.  Gone but not forgotten by CVS.

It is strange and inconsistent.  I have a patch to eliminate this
strange and inconsistent thing.

BFN.  Paul.