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
> 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
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. For
example, we do automated test builds on virtual machines on the same LAN as the
subversion server for some of the projects triggered by a Hudson server.
Received on 2010-11-12 15:17:16 CET