|
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/
