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
lesmikesell_at_gmail.com
Received on 2010-11-12 17:18:35 CET