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

Re: performance enhancement by working copy svn server

From: Listman <listman_at_burble.net>
Date: Sat, 17 May 2008 13:22:44 -0700

On May 17, 2008, at 1:10 PM- May 17, 2008, Harvey, Edward wrote:

>>> I think the general consensus is that the default svn behavior will
>>> not change; 'svn edit' will be an optional mode of working,
>> for those
>>> who want or need the speed tradeoff.
>> I figured that from later postings in the thread, but it's
>> good to see it spelled out clear.
> Correct, the default behavior will not change - 'svn edit' remains
> optional.
> However, the WC backend is likely to change. Consolidating all
> the .svn subdirs into a single file, or into a single dir.
> <anecdote>
> For me in particular, this will be very welcome. I have a badly-
> behaved tool (from Cadence) and this is its behavior:
> The Cadence tool assumes it owns a whole directory that
> you're working on.
> It goes in, modifies all the stuff it cares to modify...
> It finds the ".svn" directory, deletes it, and creates a
> ".svn" file containing only a Space char.
> And then I'm unhappy.
> </anecdote>

Agreed, this is one of the advantages of Perforce, the meta-data is
saved on the server not in the WC and there's no chance of a
misbehaving tool breaking the working copy.. As one of my users said
the other day, Perforce is "bullet-proof", Subversion is fragile..


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-17 22:23:12 CEST

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.