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

Re: Focusing on 1.0 (was Re: Feature Ideas)

From: Kumaran Santhanam <kumaran_at_tigris.org>
Date: 2003-08-24 09:18:44 CEST

> 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.

I'm not sure I understand. Here's a comparison of the current
and proposed approaches:

current:
workspace/dir1
workspace/dir1/.svn
workspace/dir1/subdir1
workspace/dir1/subdir1/.svn
workspace/dir2
workspace/dir2/.svn
workspace/dir2/subdir1
workspace/dir2/subdir1/.svn

proposed
workspace/dir1
~/.subversion/adm/HASH/dir1/.svn
workspace/dir1/subdir1
~/.subversion/adm/HASH/dir1/subdir1/.svn
workspace/dir2
~/.subversion/adm/HASH/dir2/.svn
workspace/dir2/subdir1
~/.subversion/adm/HASH/dir2/subdir1/.svn

index file -> ~/.subversion/adm/index

As far as I can see, these are equivalent. In fact, it requires
only a minor change in adm_files.c [v_extend_with_adm_name() +
some support functions].

The only difference is if you did:

mv workspace foobar

In the current approach, this would work seamlessly. In the
proposed approach, the ~/.subversion/adm/index file would have to
be updated (either by hand, or through a svn command).

You don't have to walk the path back to find the parent - you
simply do a prefix search through the index, which goes O(n) as
the number of projects you are working on. Presumably, this
wouldn't be more than a few hundred for any single user, so such
a search would take negligible time.

If I'm missing something obvious or obscure, a further
explanation would be much appreciated.

> 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.

There are commercial SCM tools that do not take the metadir
approach, and they scale quite well. Metadirs are just one
particular implementation of client state. The metadir adds
files to the workspace that aren't actually being tracked. I
suppose that the degree to which this concerns you would depend
upon your particular outlook on version control.

Regards,
Kumaran

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 24 09:20:23 2003

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

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