On 11/12/10 7:57 AM, San Martino wrote:
2010/11/11 Les Mikesell<lesmikes...@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. 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.

--
  Les Mikesell
   lesmikes...@gmail.com

Reply via email to