Re: [RFC PATCH] Re: Empty directories...

Linus Torvalds [off-list ref] writes:

On Sat, 21 Jul 2007, David Kastrup wrote:

quoted

Ok, I have now acquired enough passing familiarity with the code
that I find part of my way around it.  Most of your patch looks
like it caters for the S_ISDIR type not previously in use in the
index (how about the repository?).

The object database has always had S_ISDIR (well, "always" is since
very early on, when I realized that flat trees didn't cut it).

Then I think I have a bit of a problem: I should think that S_ISDIR in
the repository presumably marks a tree object (still very fuzzy around
the concepts here).  An explicitly checked-in directory (under my
scheme always named "." inside of its tree) would presumably also have
S_ISDIR in the repository but behave quite differently.

As far as I can tell, it would have been exactly the same thing as the 
S_IFDIR, just instead of the S_IFDIR check, you'd have had to check the 
end of the filename for being '/'.

Relative file name of ".", more or less.  Both names satisfy S_IFDIR
in the filesystem, though.

Otherwise? Exactly the same.

The more important thing is in many ways the object storage, and
that's also the reason for doing the index the way I did - it more
closely matches what the object storage does (ie the "index" ends up
mirroring a linearized and unpacked "tree" object).

I still have to get enough of a clue about the object store to see how
this pans out.  I would not want to have the "." objects marked as
type "tree" and empty if I can avoid it.  It seems unclean, would need
extra case separations all over the place, violate the "empty trees
evaporate" property and also waste a good place for tracking
permissions or other attributes in future.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum