David Rauschenbach wrote:
> 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.
There are many other streams that are important. Some development tools
store tag information in the xattr/forks. The Mac stores resource data
and compiled plist stuff (why they went back to forks for that is beyond
me, but they did)
So, there is more than just the simple time/date/etc stuff here.
> 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.
Yes, this is a problem. But think of the .svn folder as its own "stream"
that is associated with the current directory (the containing directory)
Once you look at it like that, then the .svn directories are really just
containers for that data and if/when a client has a filesystem that can
handle that behavior better, it should be able to do so.
Think of a filesystem that is databased based like BeOS or the future
WinFS stuff from Microsoft - the possibilities get really interesting.
The problem is that not all filesystems are like that and not all users
use them so you end up with the .svn directories.
(BTW - I (and others at C=) were pushing hard to make our applications
really be folders and thus having multiple "streams" in the application
was just really multiple files in the folder. That is what NeXT and now
Mac OS-X do for applications and it works really, really well - until you
use a command line and "cd" around your disk to see what it really looks
like.)
> It's noise when metadata shows up as files.
:-) Then fix your file browser :-) I think it is bad when you can not
see that there is metadata in the system using normal tools. (Show me
where Windows can display you the ADS from NTFS...)
At least with hidden/special directories they can be hidden or not as
per the user's choice.
> 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.
I don't think it is a mismatch - I just think that the current enhanced
filesystems are not enhanced enough and the tools are too crude as far
as dealing with the enhancements. Lets see where/how that goes in the
future, but remember there is a very long adoption curve for these types
of ideas. (Mac started with this in 1984 and the Lisa in 1982 - so this
is not new stuff and yet it still is not mainstream in any real way)
--
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
Received on Tue Feb 7 01:27:07 2006