2010/11/12 Les Mikesell <lesmikesell_at_gmail.com>:
> On 11/12/10 7:57 AM, San Martino wrote:
>>
>> 2010/11/11 Les Mikesell<lesmikesell_at_gmail.com>:
>>>
>>> That's not wrong in the sense that it won't work for a small repository,
>>> but
>>> it is not an efficient way to use subversion where you are concerned
>>> about
>>> space or time usage on the client. Normally you would just check out
>>> workspaces of one or more locations where you intend to work and if you
>>> branch or tag, switch an existing workspace to it (to make changes in a
>>> branch or build from the tag, which by convention should not have
>>> subsequent
>>> changes). Just be sure you have committed anything that belongs in the
>>> current location before the switch. If checkout time is an issue you can
>>> copy an existing local workspace as the starting point for a subsequent
>>> switch.
>>
>>
>> Do you think Subversion scales well for the following case, where
>> /trunk contains about 5000 files and its size is 500Mb
>> development requires 10 commits per day, 2-3 files changed per commit
>> on average.
>> Each commit is tagged (yes) from /trunk on the repository. How we will
>> test the tag is a separate issue.
>> For now also suppose the local wc only contains sparse-checkouts of
>> single files, not the whole /trunk.
>> Also suppose that a reorganization of /trunk is not possible.
>>
>> (concrete tests cannot be done at the moment, I am collecting various
>> opinions based on user experience on big projects, before doing
>> simulations)
>
> Our repo is about 43 Gb now and has more activity than that. It contains
> multiple projects some of which probably have more then 5000 files, although
> not in a flat directory. I don't see any scaling issue unless you meant to
> say 500 Gb. However, there may be network issues if your clients do not
> have good connectivity and windows clients may be slow if you do check out
> the whole mess due to their local filesystem. You might want to make sure
> that anything you do that requires frequent full checkouts is on a machine
> with good connectivity to the server even if you have to provide remote
> access for people using it.
To avoid network issues with full checkouts we think about
sparse-checkouts of what is really needed, in most of the cases it's
single files
Received on 2010-11-12 15:25:09 CET