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.
On Monday, 16 January 2023 at 07:13:36 UTC daniel.l...@gmail.com wrote:
> måndag 16 januari 2023 kl. 08:47:20 UTC+2 skrev bbpictu...@gmail.com:
> 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.
>
> 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
>
--
You received this message because you are subscribed to the Google Groups
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tortoisesvn+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tortoisesvn/0dc1e510-fec8-41f2-8811-0abf503c56e6n%40googlegroups.com.
