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

Optional text base design discussion?

From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2006-10-14 19:16:35 CEST

Has there ever been a design discussion on how to implement optional
text base working copies?

I have found plenty of flame wars in the past on the subject, but I
haven't found any design discussions on the best way to implement this.

The possibilities I have seen so far:

Compressed text bases
  * Keeps current low bandwidth performance
  * Reduces the amount of disk space slightly
  * Local working copy operations are slower

Removal of the text bases
 * Low bandwidth performance suffers
 * Reduces the amount of disk space by half in some cases
 * Local working copy operations possibly require server communication
 * Faster performance for working copy operations that have lots of files
 * Checkout performance for large binary files (no EOL translation) has
the possibility of doubling
 * Less chance for search and replace bugs

Single .svn directory (database?) for the entire working copy
 * Could be combined with compressed or missing text bases
 * Faster performance for working copies with lots of directories

There are probably other advantages and disadvantages that I have not
seen mentioned for the various approaches. If implemented, I would
imagine that these features would be optional by either some server side
configuration, or a client side option.

With the possibility of multiple working copy formats, there is an
interesting side discussion as to whether the ability to switch formats
on an existing working copy would be useful (which is possibly similar
to takeover functionality).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 19:16:56 2006

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.