On Mon, 2004-02-16 at 20:17, Timothy Reaves wrote:
> O.K., I've read over 707. I did not pay it much attention the first
> time through, as I wasn't sure it was relevant. To be honest, I'm
> still not.
Then I think that you've missed the point of 707... perhaps a lot of the
email list discussion of the past 4 years would fill you in on the
background.
> If all this has been hashed out, please forgive my ignorance, and
> kindly point to me the relevant document I might be over looking.
All I can offer at this point is that you search through the mailing
list archives for "opaque collections."
> I do not think wrapping is needed any longer (i.e. with CVS, assuming
> that is what you meant). However, is not the point of these directory
> structures under Mac to treat them as a single object? Being a
> relative new comer to Mac, I assumed it was a means of storing ea like
> data without needing a proprietary file format (ala OS < 10) and the
> customized tools such a format would require. If the purpose is not to
> treat them as a single file why would the finder show them as such?
Well, surely the purpose *is* to treat them as a single filesystem
object, but the reality of the matter is that they *aren't* a single
object on the filesystem.
> It is often the goal to version the entire directory, not just the
> files in it; look at Java jar files as an example. The big difference
> here is that they are 'compiled' into a single file. But many OS's can
> now mount those files (as well as zip, tar, etc) as directories, so the
> line blurs.
But a jar files is totally different than a nib file. A jar file really
*is* a single filesystem object--a nib file just plays a single fs
object on TV.
> I would think that Subversion would want some general way - if at all
> possible - to handle OS and fs dependent data structures. Again, is
> that not more properly what a nib should be called?
Tom-AY-to, tom-AH-to, it's still a collection of files in a directory.
The point that issue 707 is *trying* to make is that the *proper* way to
handle these .nibs, .rtfds, etc., is to allow Subversion to mark them as
an opaque collection of files and directories. Ideally, Subversion
would manage the contents of these directories automatically (removing
and adding files automagically as the appear/disappear). A whole bunch
of us would love to have this in Subversion, it's just that libsvn_wc is
currently a massive mess of code at the moment, and I've seen it reduce
more than one talented programmer to a sobbing bowl of jello.
> Is it not so much
> a directory as a data structure mapped to a directory? Whereas that
> might be somewhat a nebulous and fine point, things like reiserfs will
> make that distinction even more fine.
I'm not sure that I understand what you mean by this.
> Not being a cvs historian, I'd assume cvs did/does not support binary
> file formats well due to the lack of a need when it was written.
This has nothing to do with binary file formats and everything to do
with bundled directories.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 17 04:50:59 2004