> This file was checked out of a 'main' directory that has, say...50
files
> in it and 10 subdirectories with 20 files in each of those (so lets
say
> 250 files total). This .html file doesn't need to be 'versioned' with
> the rest of the files out there...many of which really don't have
> anything to do with this .html file in the example. So I'm still not
> seeing the benefit of 'having' to check out all 250 files, version
them
> all and then check them all back in. Seems like overkill to me, but
> then again, perhaps I'm still missing the point somehow.
With Subversion you'd need to checkout the whole directory. (Most
programmers are going to have a working directory with the project
already checked out and Subversion is naturally setup to work with that
type of user.) You can exclude sub directories if you want to speed
things up. When you make a change to the file and commit it, only the
changes are sent back to the repository. It doesn't even send the whole
file, it just sends the information about what has changed. Any files
that haven't been modified aren't sent back to the repository.
In CVS each file has its own version number and it basically tells you
how many times that file has been changed. Of course this means that if
you want to recreate what the repository looked like at a certain moment
in time, you'll have to get version 10 of one file version 5 of another,
version 6 of another, etc. In subversion version number represent the
state of the repository at a point in time. It doesn't matter how many
files you change, if you commit something the version number gets
incremented. If you are used to looking at a version number and using
it to figure out how active a file has been, this seems confusing at
first, but it makes some things simpler. If you start with a system
that uses repository wide version numbers, the CVS way seems difficult
to get use to.
--Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 16 04:38:37 2005