Rob,
Thanks so much.
I knew some of what you covered already, but I still appreciate the
detail. The *really* helpful concept is the tagging stuff. I really
appreciate the detail on that and on the branching! :o) Those ideas make
some real sense to me now. I don't know right now if I have any other
questions about source control procedures in general. I imagine that
I'll have more questions when I start putting the concepts into practice.
What I really need to know or learn now is how to accomplish all this
using VSS, (either that or I need to convince my client to use SVN).
Surely, there are similar concepts in VSS.
If anyone feels like expanding on the stuff Rob has gone over with me
here I'd really appreciate it! Remember, that I'm trying to keep the
process as simple as possible. I've got a client who has not use any
source control in a while, and admits that he can't remember everything
that should be done, so he's open to my suggestions on what our new
development process might be. Also, I've got a co-worker who seems to
have some sort of grudge when it comes to source control. He says that
he sees the benefit, but still complains about it. So the more
streamlined and easy the process, the better.
Also, now that I think of it. Is it a bad idea to implement source
control for our production code but not with our development code? It
strikes me as probably not the best idea, but are there perhaps
consequences or problems that I maybe haven't thought of associated with
not using source control for all of our code?
Thanks again, folks. I really appreciate the groups help. :o)
Chris
Robert Gatti wrote:
Chris,
Well, first I'll define the terms as I'm using them in case I'm using
them wrong.
Repository - a collection of projects on the subversion server
Project - a folder in a repository where source code sits, including
forks and metainfo
Head - a folder under the project containing the current source code,
sometimes called trunk
Tag - a single name that points to all source files no matter what
version each file is at
Fork - a copy of all or part of the project source files at a certain
version
At work we have a linux box running the subversion server, I think you
can run subversion on Windows but I've not tried. This server contains
all the source code. When a new project is created, a folder called
"trunk" is made under the project folder on the subversion server.
This is referred to as the head of the project and contains the
working code.
To work on a project I checkout the part I want to work on. Normally
this is the head and I want to get the entire project. So, when I
checkout the project I get a copy of the source on my computer. Most
of the time I put this in my webroot. After I've worked on the code
for a while and have something done I synchronize my copy with the
repository. This checks my changes against the code in the repository
and tells me if someone else has made changes that conflict with mine.
If there is a conflict I can figure out what I need to do to resolve
it. Most of the time it's just copying the changes my buddy made into
my file before committing what I did, this way I don't overwrite his
changes. Then I commit, which means to copy my changes back to the
repository.
When a change to any file is committed each file in the project on the
server has it's version increased. Version numbers start at 1. When
the project gets far enough along and we want to remember the current
state of the code on the server we tag it. This means the version each
file is at is remembered and associated with a name, like "release 1".
From that point on, no matter what has happened to the code, checking
out "release 1" will always get the same files at the state they were
in when tagged.
Now, I understand how forking works but honestly haven't needed to use
it yet. Basically, forking, also called branching, makes a copy of the
code on the server.
An Example, think of a project that was tagged with "release 1" at a
certain point. Development continued for a release 2. Release 1 is
checked out for live production and later a bug is found. Work has
already begun on release 2 so the code at the head is in flux. To
solve this the project is forked at release 1; this creates a copy of
the code at the release 1 point. The bug is fixed on the forked code
and the fix is uploaded live. To make sure the code at the head also
has the bug fix the fork is merged back into the head.
Let me know if more explanation is needed.
Rob
------------------------------------------------------------------------
_______________________________________________
Reply to DFWCFUG:
[email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors:
www.instantspot.com/
www.teksystems.com/
--
http://cjordan.us
_______________________________________________
Reply to DFWCFUG:
[email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors:
www.instantspot.com/
www.teksystems.com/
