Re: Attic cleanup

[Mark D. Baushke]

Paul Edwards <kerravon@nosppaam.w3.to> writes:

> "Mark D. Baushke" <mdb@cvshome.org> wrote in message 
> news:mailman.7576.1055146760.21513.bug-cvs@gnu.org...
> > Paul Edwards <kerravon@nosppaam.w3.to> writes:
> >
> > > "Larry Jones" <lawrence.jones@eds.com> wrote in message 
> > > news:mailman.7556.1055101737.21513.bug-cvs@gnu.org...
> > > > Paul Edwards writes:
> > > > >
> > > > > Can we have the Attic removed when there are no more files there,
> > > > > with this?
> > > >
> > > > Why?
> > >
> > > It is usual to put things back into the state they were before.
> >
> > The existence of an empty Attic directory is just a container.
> >
> > It is not really part of the 'state' of a given directory. It dates back
> 
> I didn't say it was.

Ahhh... so, I guess I was confused by your use of 'state' ... I was
under the impression that you were trying to tell us that something was
broken with having an empty Attic directory.

> > to when the $State$ of 'dead' was not used to indicate that a file had
> > been 'removed' from the mainline. It would probably be possible to
> > remove the Attic processing these days, but it is not 100% backward
> > compatible with very old cvs repositories...
> 
> I didn't even say that Attic processing should be removed.

Okay. I misunderstood what you were suggesting.

> > > 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...

> > 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?

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
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.

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. 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?

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. ?)

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

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?

> > 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.

        Enjoy!
        -- Mark