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

Re: Optional text base design discussion?

From: Joseph Galbraith <galb_at_vandyke.com>
Date: 2006-10-14 19:51:20 CEST

Brandon Ehle wrote:
> 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

I think this could be done in such a way that low bandwidth
performance and server communication would only be a drawback
if the user failed to notify svn that he was about to modify
a file.

For example, we could add a "svn modify <file>" command,
which would check the hash for the working copy file
and if it hadn't already been modified, copy it into
the test-base area.

Then, as long as you remember to "svn modify" your files
before you change them, you get all the advantages of
the current system.

Additionally, it might be possible to add something like
a --no-scan option to check-in, which would simply assume that
only files present in the text-base area were candidates
for check-in and not preform an exhaustive scan of the
working copy. There could be significant performance

For those of us working in IDE environments, the right
set of tools could also help prevent the case where
I have to contact the server because I forgot to svn modify
before changing a file.

Also, while not something the subversion team
would undertake, a design such as this would make it
possible to combine subversion with a kernel mode
component that automatically copied the files before
allowing any write operation to proceed.

> 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

And the downside to this is that you don't have
'tear-off' working copies, where any subfolder of
a working copy can be move elsewhere and independently
remains a working copy.

Of course, I don't find much value in this feature...
and if I could trade it for working-copy performance,
I'd do it in a heart-beat.



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:51:37 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.