Code versions

[The Dan Keefer <da...@yahoo.com>]

Folks,

Re: Code versions

[Patrick Burleson <pb...@gmail.com>]

On 8/21/06, The Dan Keefer <da...@yahoo.com> wrote:
> Folks,
>
> 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.
>
> Sorry, but I'm trying to conceptualize how all these version copies (on the
> server) relate to the copy on which I run code.
>
> And when I said "test", I'm not talking about full testing but the testing
> that goes on whenever any developer changes code. Before he puts the code
> anywhere else, he typically runs it to make sure at least syntactical errors
> aren't there.

Dan,

First, it sounds like each developer doesn't have CF installed on
their local machines to test code with but that they upload the code
to some central server for testing out their changes? How do they not
collide with each other?

Based on this message and your previous one, it appears you don't have
a strong understanding of how Version Control systems work. May I
suggest you pickup "Pragmatic Version Control: Using Subversion, 2nd
Ed." (http://www.pragmaticprogrammer.com/titles/svn2/index.html) to
learn more about the topics involved with Version Control, and how
they relate to Subversion.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Code versions

[Erik Hemdal <er...@comprehensivepower.com>]

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