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

Re: svn up known issue?

From: jason marshall <jdmarshall_at_gmail.com>
Date: 2005-07-27 06:58:44 CEST

On 7/26/05, Ben Collins-Sussman <sussman@collab.net> wrote:
> jason marshall wrote:
> > If the manual labor of using SVN is
> > truly so high, then my recommendation will be to pay the licensing fee
> > for Perforce, as the total cost/benefit is lower, and the in-house
> > expertise is slightly better (a couple of developers, versus none).
> Perforce may definitely be a better choice. It's designed to work best
> over a LAN. Users have to tell the server they're about to edit
> something, so the server is 'tracking' every working copy in existence.
> The payoff is that perforce can instantly know which files have
> changed, and the version of every file. It makes all the "discovery
> crawls" done by 'svn up' and 'svn commit' unnecessary. Of course, the
> tradeoff is that you always need to have the server close at hand, for
> absolutely every operation.

Perforce can tell me what Tom, Dick, and Harry are up to by keeping
the user connected. That much is true, and in some situations useful
in its own right, such as when I'm starting a long change, and want to
know if someone else is going to make my life difficult by changing
the file underneath me.

However, you don't strictly need the server in order to have your
local copy be able to tell you what you have open for edit. You could
have a purely local 'checkout' command that served this function. I
would presume that it was instead a desire to avoid explicit file
checkout that requires the full directory scan. One could have
checkouts without the functionality of sharing checkout status with
anyone else. Whether SVN could have such a feature tacked on at such
a late date is another matter entirely, but -some- version control
tool certainly could do so.

> > I encourage the SVN team to reassess their definition of 'reasonable
> > working set', and consider if the tool as currently presented can meet
> > reasonable performance metrics given that definition.
> Perhaps you could tell us exactly how many files and dirs are in your
> working copy. And, is this running on NTFS?

Certainly. I'll have to poll my non-Windows coworkers for performance
numbers, but I believe that I am using an NTFS partition (mostly
defragmented, 25% full). The code tree, minus SVN's additions, is
about 750 MB and several tens of thousands of files (I can be more
specific if you need).

Is NTFS really so much worse than FAT32, or are you making a
comparison versus ext3?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 27 07:01:14 2005

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

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