The hidden .svn folder

[BangBang Pictures]

Hi.

I am just wondering if there is way to relocate the hidden .svn folder to a different disk partition, or someway to accomplish it whatsoever. The SVN directory size would grow so rapidly as the contents get doubled.

Thanks.

[Daniel Sahlberg]

Unfortunately that is not possible. Subversion uses this file to identify the working copy.

The double size is because all original files ("pristines") are stored within the .svn folder to enable certain operations to be performed locally (for example "diff"). There is ongoing work to disable storing the pristines locally, effectively making a tradeoff between disk and network since for example a "diff" would need to fetch the original file from the server. 

The pristineless working copies is currently available in the nightly builds of TortoiseSVN, however be aware that it has not been widely tested. Any help in testing it out would certainly be appreciated.

Kind regards,

Daniel

[Bruce C]

Hi,

It seems an odd question, to be concerned with the hidden .svn folder. Perhaps it's exactly the question you need to consider. However, previous experience makes me wonder if there's another possibility.

As Daniel states, the .svn folder keeps pristine copies of the checked out files. Consequently, the .svn shouldn't really be much different in size to the files that need to be checked out for development. That is, the .svn is only doubling the required storage space [required for development] which doesn't seem very significant.

However, I've found that users that are more familiar with other VCS tools (e.g. git) can sometimes checkout the full repository rather than only the element that's required. That approach could significantly increase the local space required for typical development - both for the standard checked out files and the hidden .svn folder - by a much larger factor.

For example, a typical Subversion repository might have a structure as shown below:
  /
    /trunk
    /branches
      /BR-issue1
      /BR-issue2
      /BR-issue3
    /tags
      /ver-1.00
      /ver-1.10
      /ver-1.20
      /ver-2.00

Typically, a developer will only need to checkout a simple element (e.g. trunk OR BR-issue2 OR ver-1.20). This important thing to note here is that the checkout of a single element will require significantly less storage than a checkout of the full repository.

Now, Subversion doesn't impose any particular structure and so the structure can change from repository to repository. Consequently, Subversion will happily let a user checkout the full repository, even where it isn't the appropriate action. However, a full repository isn't normal, nor what is probably required. Since a distributed VCS tool (e.g. git) clones the FULL repository, users coming from those systems can sometimes believe that the checkout has to be done that way. That isn't the Subversion approach. That difference of operation would increase the size of the checkout and the hidden .svn folder.

If this is the issue, then the solution is to adopt the Subversion practice of only checking out the element that's required (e.g. trunk OR BR-issue2 OR ver-1.20). I'm sure that there are good books or online guides that describe typical usage of Subversion.

As I said, this might be irrelevant to your question. If so, sorry about that. However, perhaps this is the cause of the slightly unusual question. In that case, it seems worth mentioning. At the very least, it captures the possibility for others that might search and find this thread.

Hope this helps.

[David Balažic]

Hi!

Theoretically, space could be saved by using copy-on-write (aka COW) file copies, a feature supported by some modern filesystems.

Basically, the two copies of the file occupy the same disk blocks (similar to hard linked files), but they behave as separate "logical" files. When one is modified, the filesystem saves the changes in a separate place, so the changed file shows the new, changed content, while the other "copy" still shows the old content. (the other file can also be independently edited and changed).

SVN could use this for the pristine copies, saving half of the disk space typically. That is: the less local changes, the more data savings.

Also theoretically, this could by done entirely by the SVN software on any filesystem, but would be pretty tricky to implement.

Regards,

David