[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

replacing .svn directory on NTFS and HFS+

From: <Ruediger.Dohna_at_oxaion.de>
Date: 2006-01-24 08:00:45 CET

I have read http://svn.haxx.se/users/archive-2004-03/1015.shtml but I still
might have missed someone else suggesting something similar or even better.
But I think, there is a solution to a lot of problems perpetually discussed
on this list - at least for Windows using NTFS and to some degree for MacOS
using resource forks.

NTFS can store arbitrary additional file forks (I think they use a
different official term). E.g. you can do "echo foo > testfile:svn" (note
the colon) and a seemingly empty file "testfile" will be created. Sadly you
can not retrieve the contents of that file fork with the TYPE command (it
throws an error) and few file editors can open it as a file, but using
Cygwin you can do "cat testfile:svn" or even "vi testfile:svn" and get back
your "foo". And this even works on directories!!!

MacOS HFS+ only supports one additional file fork, the resource fork. But
the resource fork has (generally) a special structure so you can store your
own data 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.

Both of these mechanisms had been introduced mainly for file 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 (provided that the
target filesystem is NTFS resp. HFS+). So the problems when working with
versioned files without subversion tools would simply disappear, together
with double matches in find tools etc.

It will introduce problems on its own: The metadata will silently get lost
when moved to a different filesystem. This happens already when you copy a
single file now, but not with directories. And it is more difficult to
*intentionally* remove the metadata. Maybe we would need tools for that...
and to change one format into the other (this should *not* happen
automatically!)

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. The .svn
directory would have to stay as a platform independant and fallback
solution.

Is this a new feature that deserves the status of an issue, maybe for 2.0?
What do you think?

Regards
  Rüdiger

Besuchen Sie uns auf den ERP-Days 2006 in München (30.01.2005), Stuttgart (31.01.2005), Frankfurt (01.02.2006) und Essen (02.02.2006). Nähere Informationen finden Sie unter: http://command-ag.de/cmd_oxaion/erpdays2006.php?colang=de .

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 Tue Jan 24 15:50:28 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.