> > Of course, for those stuck with a slow file system (NTFS, UFS, NFS
> > etc), even a serious WC reorganisation may not help enough. This
> > remains to be seen - an 'svn edit' option would feel like admitting
> > defeat.
>
> Yes, I agree it would "feel like admitting defeat". I have no problem with
> it if it is an option.
>
> Just as a data point:
>
> I work with a 6 Gig working copy (14 Gig repository) and can do status and
> commit and update operations in seconds on Win XP SP2 with 2 Gig of RAM and
> NTFS.
I believe it's more about the number of files and folders than size
for repo crawling costs.
The worst we have is ~20,000 files in 3,500 folders (not counting
working-copy meta-data). The actual content-size is only ~650MB and
half of that size is in 10% of the files.
There's a noticeable difference in status checks between Subversion
and tools like Bazaar which uses not only a single meta-data folder
but also a very small number of files in the meta-data area.
Obviously size of working-copy content is a factor when considering
the space cost of the meta-data in Subversion with pristine copies
taking up a lot of space - those pristine copies are expensive. The
distributed solutions don't help as they include a complete revision
history (even if the repository format is often more concise than
Subversion, since clients don't wear the cost of Subversion
repo-size).
(Then again I have 10 working copies that share most of their ancestry
so a Bazaar shared repository with 10 branches/checkouts would reduce
the cost dramatically per working-copy.)
One way to reduce typical status costs would be to 'schedule' changes
for commit (I added this, removed that, or modified these) and only
looked for other changes when a full status (which would include
unknowns and unscheduled modifications and removes).
Of course that's a major UI change for Subversion and I wouldn't
expect it to be popular... Look at the UI Bazaar where a single 'bzr
add' adds all unknowns and you allow the 'status' to discover
modifications and implied removals - I think people will generally
choose a UI that requires the user to do less data-entry over the cost
of a few seconds.
(of course people also challenge Bazaars performance relative to its
peers Mercurial and git so maybe the cost for that UI is too high for
some - to them I say, try CVS).
NB: I'm not advocating Bazaar here, it's merely a comparison... Bazaar
misses, at least (though I'm no Bazaar expert), EOL support, version
properties, mime-type support, partial branches, nesting (externals or
Mercurials forest), mixed revision branches and tags, file/folder-copy
tracking and any reasonable support for case-insensitive
file-systems...
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-12 15:42:58 CEST