I found a quite anonymous and sparse suggestion dated back in 2003. I would
like to elaborate on it and the objections raised against it. I have posted
most of this text to the users list, which was propably to the wrong
audience, but there was one very helpful answer from Angel Marin, which I
have assimilated.
NTFS can store arbitrary additional strams for a file or directory called
Alternate Data Streams ADS. E.g. you can do "echo foo > testfile:svn" (note
the colon) on an existing file "testfile" without changing its contents. To
retrieve that file fork do "more < testfile:svn". Editors using the
standard windows file open dialog can not open the ADS, but others like
jEdit can. And all of this even works on directories!!!
MacOS HFS+ supports only one additional file fork, called resource fork.
But the resource fork has (generally) a special structure so you can store
your own data using your own key (say ".svn") without disturbing and being
disturbed by others. It does *not* work on directories, though, and
somebody on this list stated that the use of the resource fork was
deprecated on MacOS X; so it might not be an option.
I do not know, if any of the common unix file systems support custom file
metadata, but I guess it would be at least in a planning stage.
All of these mechanisms had been introduced to store metadata. On Windows
it is used for storing file permission (ACL), the author, etc., so I guess
it lends itself as a natural place to store Subversion metadata as well,
rendering the .svn directory altogether dispensable, although not reducing
the disk space occupied. Even better: Moving, duplicating or renaming such
a file or directory would keep the metadata intact and attatched to the
file (Barry Scott had objected it would not, but at least on MacOS, Windows
2000 and XP it does, provided that the target filesystem is NTFS resp. HFS+
as well) . A whole bunch of problems working with versioned files without
subversion tools would simply disappear, including double matches in find
tools, etc.
Needless to say that the .svn directory would have to remain as a platform
independant alternative and fallback solution. It would be necessary have a
tool that can roll the .svn directory out into the file metadata and vice
versa (this should *not* happen automatically!).
Attatched custom file metadata would simplify most versioning use cases,
but not all:
1. Removing a file or directory would remove its meta data as well. In
order to know that something is missing, the directory would need to have a
list of known objects, so it can look for the same object with a different
name or at a different location (which still would have the old metadata)
in order to tell the repository to rename, move or even remove that object
(I do not think that we should have the user explicitly mark it as deleted
any more).
2. Moving or copying files or directories to a different file system would
*silently* remove the meta data. This happens already when you copy a
single file now, but not with directories. And the user might already have
got spoiled and not expect it ;-)
3. It is more difficult to *intentionally* remove the metadata. Maybe we
would need another tool for that.
How much code is involved in finding the correct path for the meta data for
a file or directory? Is the change to the existing code as easy/problematic
as it was renaming the directory to _svn?
There is another thing that might be done with this: Single file checkouts.
But as a lot of code might depend on only complete directories being
checked out, so this feature seems to be more risky to implement.
Regards
Rüdiger
Besuchen Sie uns auf der CeBIT in Hannover vom 09. - 15. März 2006.
Sie finden uns in Halle 5, Stand A38.
This message is intended for the addressee or its representative only.
Any form of unauthorized use, publication, reproduction, copying or
disclosure of the content of this e-mail is not permitted. If you are not
the intended recipient of this e-mail message and its contents, please
notify the sender immediately and delete this message and all its
attachments subsequently.
oxaion ag
Received on Mon Feb 6 12:23:07 2006