From: The Dan Keefer [mailto:dan_keefer@yahoo.com]
>From the sound of things, while my code may originally run from /path1,
multiple revision paths get
>created elsewhere so that if I change file1.cfm, it isn't saved in /path1
but in some new Subversion
>folder.
When I check out code, I obtain a special folder called a "working copy".
This is a conventional folder, with the addition of a special (usually
hidden) folder called ".svn". This special folder contains the data
Subversion needs to keep my files under version control.
I can develop, change, build, and test my files locally in a working copy.
These files are under control, and Subversion will track whatever changes I
make to the files in my working copy. The repository is located somewhere
else -- in a different folder on my machine or on a completely different
server on my network. If I make changes to my working copy, I can preserve
them by "checking in" to the repository.
If I understand your situation, your developers would check files out of the
Subversion repository and do their work in a working copy at /path1. That
working copy will "point to" some location in your Subversion repository
which contains all committed changes and historical records for you.
The working copy will be "in sync" with the repository after you commit, and
will be "out of sync" anytime that a developer changed something that has
not been committed yet. Don't think of the files as "going somewhere else"
-- the files in the working copy are _always_ present in that folder. But
after you make changes at /path1 (your working copy) you can save them
permanently in the repository.
This is similar to a word processing program -- if you change a document,
it's different in memory compared to what's on disk, until you save the
changes. But unlike a word processor, Subversion remembers every change you
make to every file you change, by keeping records in the repository. And
you can manage more than one set of "same, but different" files by using
branches and tags.
This allows you to have a lot of flexibility in how you make and apply
changes, but how you actually do that is the whole subject of SCM itself
(for which Subversion is only one tool). That's why others have recommended
some SCM books to you. There's a lot to doing SCM well, regardless of the
tool you pick.
Does this help?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 21 22:04:52 2006