Hi San, On Fri, Nov 12, 2010 at 2:57 PM, San Martino <sanmrt...@gmail.com> 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.
Why would you want to tag each commit? A commit is a tag in itself: there's a unique identifier to refer to the entire commit. This wasn't the case in PVCS, RCS and CVS, but there's really no reason to tag each and every commit; if you want to check out what got committed, just use the revision number! > 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. Bye, Erik.
