2010/11/12 Les Mikesell <lesmikes...@gmail.com>: > 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.
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
