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


From: Radomir Zoltowski <Radomir.Zoltowski_at_s3group.com>
Date: Tue, 16 Feb 2010 14:49:23 +0000

Hi Hyrum,

Thanks for this. I will continue inline if you allow.

> The default (and only method supported in 1.7) will be a .svn directory at the root of the working copy. As with previous versions of Subversion, please don't manually move or edit the contents of the .svn directory.
My intention was not to move .svn, but the whole working copy as per the
topic below. However, in the new model, an administrator will have some
difficulty in: 1) finding the root of working copy other way than by 'cd
../../../' , 2) determining easily that a random disk location is a part
of some working copy or not. Of course it is a trade off against much
more important goals, but I just want to have a confirmation, that this
will be the case in 1.7.*.

>> ... or putting things differently. Let's say, there is a team of 100 people somewhere in Europe awaiting an access to a 250 GB repository somewhere in Australia. What to do to avoid 100 check-outs? Assume the repository contains binary data and must be checked out in full. Slave with http-based proxy is not an option (until svn+ssh-based proxy is invented).
> This is a valid concern. The complete behavior is still unknown (see statement above).
> Eventually (but not in 1.7), we plan on letting users share the pristine data store, which would avoid this problem.
Yes, I have seen this, too. However, the above described deployment
model, while it is not a best practice, I am positive it is excercised
frequently throughout the world due to lack of multi-site replication.
Removing this option before shared working copies see the light may
create some chaos. Therefore I would suggest providing some bridging
solution, that for example could be a new 'svn cleanup --relocate' or
whatever else. I am not a developer, but it seems easy enough to throw in.

> SQLite actually *removes* points of failure. Instead of our custom on-disk data format (which has had to be continually updated and improved), we let SQLite do that for us. SQLite is well-tested, widely used, and provides atomicity semantics which are very useful to Subversion. Instead of re-inventing the wheel, we can use a much better engineered wheel
Seems OK. I didn't know you were changing format frequently, thought is
was set in stone.


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications_at_s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
Received on 2010-02-16 15:50:10 CET

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.