--On Saturday, August 23, 2003 5:34 PM -0700 Kumaran Santhanam
<kumaran@tigris.org> wrote:
> However, I feel more strongly about #1, and I respectfully ask
> everyone to take this into consideration for v1.0. The feature
> is not easily scripted around (unless somebody can think of an
> idea for a solution). Also, unless I'm missing something, it
> should be relatively straightforward to implement and test in the
> client.
No, it's not straightforward because your approach doesn't scale and isn't
user-friendly. Imagine a working copy with one million files in it, but
spread out amongst several directories. Imagine trying to read that large
.svn/entries file on 'svn st' in a sub-directory (nevermind that you have to
walk up directories looking for your .svn parent). How do you deal with
partial checkouts? Imagine trying to move a sub-directory and still have SVN
deal with that gracefully.
There are lots of pitfalls in your #1 that I don't think you realize that have
nothing to do with libsvn_wc's state.
CVS takes the one-metadir-per-directory approach, and I think it's the right
one to take in the general case. 'Opaque collection' support would be nice
(and I'm a Mac user and hate that I can't store Keynote files in SVN), but
they aren't a general purpose solution to anyone's problem. I think CVS got
the right balance here for the general case.
And, if you really want #1 *right now*, mount the SVN repository via some
WebDAV interface. The contents of the files may change as other people make
changes (as it'd reflect HEAD), and every file change results in a commit, but
there won't be any .svn directories for you to worry about. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 24 08:23:02 2003