Hi Michael,
Michael wrote:
> I would much rather try
> sticking to the goal of Subversion being a revision management
> system and that the files are "sacred" and should not be corrupted
> or changed due to the use of Subversion. (I should get back what
> I put in)
I have not heard any suggestions yet that would challenge subversion's
ability to be an uncompromised revision management system. I can't see why
anyone would want that. Understood if you mean the data stream and probably
created-time and modified-time streams are sacred. Those certainly play into
things you might want to "get back" just the way you put them in.
However, are other streams really sacred? Do you have strong feelings about
how the archive bit might be set on an NTFS file of a server repository? If
not, then I don't see why you'd have strong feelings about other potential
streams, none of which jeopardize the sacred streams.
Similarly, I don't see why svn would or should care about non-special
properties (not in the "svn:" namespace).
Also, beyond asking those questions, I should add my opinion into the fray!
The .svn folders *doubles* the number of folders that live on my hard drive,
and the repository server's hard drive. It slows everything down, even
backup/restore of all the workstations. Not to mention that when alternate
streams are small, there is the lost benefit of stored locality. Plus, from
a usability standpoint, it's not long before I end up browsing folders in a
way that needs to include hidden folders, and the .svn folders clutter up
everything.
It's noise when metadata shows up as files.
As these "object filesystems" (NT terminology) get built out, and once
people start relying on them, they will realize that all metadata *not*
stored correctly becomes an impedance mismatch. For example, file traversal
searches and desktop search engine searches getting false-hits from a
metadata file that is actually "metadata plus pointer" to a real file, but
the search tool doesn't and shouldn't know that. Similarly, BeOS/Haiku
indexes unable to index metadata for active search or passive search
(categorization), because the metadata is "misfiled". Which ultimately
causes adapters like Google desktop search plug-ins to get the work done
that could have been done correctly in the first place.
If the current svn filesystem abstraction is an impedance mismatch with the
reality of emerging filesystems, then that's only going to become a bigger
problem over time, as subversion becomes more successful (yahoo!) and
metadata storage starts getting corrected by the industry as a whole. The
industry has spent big money over more than a decade getting this done...
and not without good reason. No point in even digressing into that -- the
filesystems are here now, and how they got here is already history. Back at
the high level, it seems to me like if this doesn't get addressed now, it
will still have to get addressed later.
David
----- Original Message -----
From: "Michael Sinz" <Michael.Sinz@sinz.org>
To: <dev@subversion.tigris.org>
Sent: Monday, February 06, 2006 9:53 AM
Subject: Re: using NTFS ADS, HFS+ ResourceForks or other file system
metadata facility instead of a .svn directory
On 2/6/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> Ruediger.Dohna@oxaion.de wrote:
> [...]
> > it lends itself as a natural place to store Subversion metadata as well,
> > rendering the .svn directory altogether dispensable, [...]
>
> This is an interesting idea. There are two levels at which we could use
> filesystem metadata storage:
>
> * just for storing the Subversion "properties" on an item;
>
> * for storing all Subversion meta-data that is currently in the ".svn"
> directory - pristine (base) copies, information about which
> repository/path/revision the local files are connected to, etc.
>
> You seem to be talking about the latter.
>
> Of course a fair bit of work would be required to do this, so it would
> need to
> have some distinct advantages.
[...]
> I can't yet see a compelling reason to use filesystem metadata storage.
I can think of at least one more reason not use the filesystem
metadata for Subversion - the files I am putting into the repository
have metadata for their own use. As such, modifying or adding
to this changes the file I have placed into the repository.
(Note - currently, Subversion does not actually deal with metadata
within files very well [ok - at all :-)] which is a whole different
problem and also non-trivial to fix in a cross-platform way)
There are other tricky issues that start to come up, but I would like
to not go down those rabbit holes now. I would much rather try
sticking to the goal of Subversion being a revision management
system and that the files are "sacred" and should not be corrupted
or changed due to the use of Subversion. (I should get back what
I put in) [Yes, I know that we don't do metadata or xattrs yet]
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 6 18:11:35 2006