On 11/12/2010 8:24 AM, San Martino wrote:
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
You can do whatever works best for each client on the client side. Someone who has good connectivity and works on many files might do a complete checkout and just update/commit from that workspace from then on. Someone with limited bandwidth or that doesn't want to take up the space to keep a working copy around all the time might do a sparse checkout of only the files he needs to modify and commit back.
In any case, as I tried to point out earlier and others have repeated, it doesn't matter if you copy to tags or not. The purpose of the tag is just to give you a human-friendly name that you can use for documentation or steps in your process. Even without explicit tags, every commit is atomic and increases the global repository revision number. You can recall the state of all or any part of the repository at any revision by including the '-r rev' option in your checkout or update command. In some other version control systems you have to assign tags to hold groups of files together, but in subversion you get the natural grouping of directories with the global revision number holding the state after every change. Copying to tags just gives you a different name for it. If you are doing something to test after each commit, you can just use the revision number and if you tag at all, only do it for versions that you have some reason to recall for some other purpose later.
And by the way, if you can automate your testing, you might like Hudson to run the jobs for you. You can set it up to poll subversion for changes frequently and run jobs (even on different machines) when they happen. http://hudson-ci.org/
-- Les Mikesell lesmikes...@gmail.com
