Setting up your Repository

Common ways to set up svn on a network are to use the svnserve that comes with it or to use Apache.

To begin though, we probably just want to experiment with creating a repository on our local machine, which can be done with a lines like:

svnadmin create /path_to_repository
svn co repository_uri local_dir ; cd local_dir
#svn import trunk file:///path_to_files_want_in_initial_repository
#if importing from a different repository
svn mkdir trunk #don't do if did above
svn mkdir branches
svn mkdir tags

Trunk, Branches, Tags

The organization above is not mandatory; however, it is a common way to organize an svn repository.
Basically, the trunk directory is used to hold the main version of your code.
Incremental work on the code is usual done and maintained in trunk.
If someone needs to implement a large feature which might make everything not work until it is ready, then they might create branches from trunk and work on those.
Often it is useful to have "frozen versions" of the code base which are known to be completely working and don't change much.
You might use the tags directory for these. For instance, you might maintain a production tag.

Basic Work Cycle

Typically, a programmer who is going to work on a bug, checks out a version of the repository:

svn checkout url_or_path_to_repository local_dir
Or
svn co url_or_path_to_repository local_dir

This makes a copy of the repository in local_dir.
If we cd into local dir, we can see what's there by typing the command:
```
svn list
```
If you actually do an ls -a on the directory in question, you will see there is a hidden directory .svn in each subdirectory of your local copy. This is how svn keeps track of what things have been updated.
You can now edit the files to fix your bugs using whatever editor you like (such as vi).
While you are making changes on your local system, other people might be committing revisions to the repository, to keep in sync with these revisions, you can do:
```
svn update
 or
svn up
```

More Basic Work Cycle

svn up will get the most recent versions of files you haven't changed from the repository into your local store, it will try to merge the changes in the files you have changed with those in the repository again outputting to your local store, finally, it may say there is a conflict on some files which svn couldn't resolve.
For the conflict files you need to look at the files and fix the conflict. Once its fixed you can type:
```
svn resolved filename_with_conflict.
```
You can then check in your code (this make your changes take effect in the repository rather than your local copy) with a line like:
```
svn ci -m "Fixes BugXXXX, r=so-and-so, a=someone-else" 
```
so-and-so is the person who reviewed the patch, someone-else is the person who approved the check-in. You often only have r= or a= but not both.

Add, Delete, Diff

Sometimes in fixing a bug, you need to add a file to the local copy of the repository.
After you have made the file in the editor, you can then tell svn to add it to the local copy using a line like:
```
svn add filename
```
Similarly, sometimes you might need to delete a file from the local copy of the repository:
```
svn delete filename 
```
Sometimes you need to create a patch consisting of your changes to the repository. This could then be reviewed by someone else.
```
svn diff  > my_patch.txt
```
Someone could then apply the patch by checking out the code from the repository and then doing a line like (in the correct directory):
```
patch -p0 < my_patch.txt
```

Issue Tracking

Typically, you would post patches you make to some kind of bug/issue tracking tool for review before they are checked-in.
Some popular Bug/Issue tracking tools are: JIRA , Bugzilla , Trac .
An issue tracking tool completely written in PHP is MantisBT .
Here is a list of other tracker that exist: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems

svn copy, merge

Creating a tag and a branch are essentially the same thing:
```
svn copy trunk_url  prod_url -m "Create production tag"
```
If trunk changes and you want to incorporate the changes into production one can, check out a copy of production and do a line like:
```
svn merge -r###:HEAD trunk_url branch_name
```
then commit the result.
If you don't want to emphasize from which version to which you can leave off -r###:HEAD
To reintegrate a branch with trunk, you check out trunk, and do a line like:
```
svn merge -r###:HEAD branch_url trunk
```
on the local copy, then commit the result.

Git

When we introduced version control systems we said we were going to consider one system based on the central repository model (Subversion) and one distributed system (Git).

Git has been around since 2005, and was originally developed by Linus Torvald, the creator of Linux.

Git has a nice website for publically hosting git repositories known as GitHub. Repositories on this sites get their own issue tracker (with rss feed) and wiki.

Git uses many commands in a similar way to svn; however, there are some key differences which we will see as we go along.

To begin to set up a git repository move to where you would like to have your repository and type:

git init name_of_git_repository.

If you cd into this directory and do an ls -a to see hidden files, you will see a .git folder.

This is where git keeps track of stuff, unlike svn, each subfolder of your repository doesn't get a .git folder -- svn allows you to check out sub-folders of a repository, with git you essentially always check out a whole everything in a whole branch.

If you want to let someone to get a copy of your repository, you copy the repository folder on to a usb key (a key without Stuxnet please), give it to the person you want to have the repository.

The person that wants to get your repository, might have an existing repository that they want to get your stuff into or might be starting from scratch. They issue a commands like:

git clone path_to_clone_from to_folder #from scratch case
git pull path_to_from_repos branch_name_you_want_to_pull_into #existing case
git checkout branch #makes branch the current branch in the repository you are working on

Notice sharing can be done locally without the need for a central repository, you can zip your git folders and e-mail, git even has its own e-mail commands.

To see information about git commands, you can type 'git help', or 'git command --help'

Example Creating a Repository

Here is a short example of creating a repository on a *nix system in the directory /Users/cpollett

mkdir myrepos
cd myrepos
git init
git add .
echo "hi there" > test.txt
git add test.txt
git commit -a -m "Initial commit"
cd ..
git clone file:///Users/cpollett/myrepos myrepos2
cd myrepos2 # now start editing myrepos2
echo "test2" > test2.txt
git add test2.txt
git commit -a -m "Made some changes"
cd ../myrepos #now want to get changes back in myrepos
git pull file:///Users/cpollett/myrepos2 master

This produces a copy of the repository in a separate folder. We then edit the copy, and pull the changes back (the changes were in the clone's master branch) into the original repository. We will describe git add and git commit in a moment.

If in myrepos2 we had want to get changes from myrepos, we could simply have done:

git pull

as git will default to pulling where it was cloned from.

Creating a WebDav repository

If you want to have a workflow more like svn with a central repository you can configure a WebDAV directory in Apache on a server for git:

<Location /git/myrepos.git>
DAV on
AuthType Basic
AuthName "My site"
AuthUserFile /etc/apache2/myrepos.passwd
<LimitExcept GET HEAD PROPFIND OPTIONS REPORT >
Require valid-user
</LimitExcept>
</Location>

When you initialize your repository, you do the following commands:

mkdir myrepos.git
cd myrepos.git
git init --bare
git update-server-info

You need to change the permissions and ownerships so the web server can access this folder, if _www was the user and group of the webserver then we could do:
```
sudo chown -R _www .
sudo chgrp -R _www .
```
Finally, you would need to restart the webserver:
```
sudo httpd -k stop
sudo httpd -k start
```

Configuring your Repository

To find out how our repository is set-up without trying to understand the contents of our .git folder, we can use the git config command:
```
git config -l #lists current config settings.
git config setting_name new_value #changes a setting
```
Git will take a stab at figuring out who you are, but you will probably want to adjust the settings user.name and user.email to properly identify yourself when you commit changes:
```
git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com
```
You might also want to use git config to configure an upload url:
```
git config remote.upload.url http://myserver/git/myrepos.git
```
Continuing the example of the last slide, we could populate the blank server's repository with stuff we make via:
```
cd myrepos
git init
git add .
git commit -m "setting up initial repository"
git push upload master
```
This might ask for password info. If you like you can configure a ~/.netrc file to save this info. This is a file on *nix systems with the following lines:
```
machine [servername]
login [username]
password [password]
```
where you replace what's in brackets with the relevant info.

Adding, Moving Files

Like svn, git doesn't manage files unless you tell git about them:

git add file_or_folder 
#folders added recursively, 
#.gitignore can be used to list files you don't want added or managed.
git clean #gets rid of files git doesn't know about
git rm file  #removes the file from the repository, with -f deletes from filesystem
git mv loc1 loc2 #moves file from loc1 to loc2
git checkout [rev] file #gets the [rev] version of the file into the current branch
#-f overwrites uncommitted changes.

In svn revisions count up starting with revision 0, if you commit changes to a subfolder or branch, it still adds 1 to the global revision count.
Git revision numbers are super-unmeaningful 20 byte SHA-1 hashes. Fortunately, you only need to use prefixes of a given hash number which are enough to uniquely identify a given branch.

Committing changes

Adding files, removing files, modifying files, each make changes to your copy of the repository after the last revision.
This revision is called HEAD in addition to its SHA-1 name.

To make a new revision of a given branch, you use the git commit command:

git commit -m "Commit message" 
git commit -a -m "Commit message" #the -a adds any unmanaged files to the repository

The new revision will incorporate all the changes you made since the previous revision.
You can use the same formats for commit messages as we had with svn.
If you want to undo any changes you have made since the last commit, you can use the command:
```
git reset --hard HEAD
```
Notice unlike svn, commits happen locally only on your machine.
To find out information about commits you can use the "git log" command.
To find out what has changed since the last commit you can use "git status"
To see the changes between two revisions, you can use "git diff rev1 rev2"
To see who has been modifying a file, you can use "git blame file".

Branches, Merging Branches

You can find out what branches exist in your repository by typing the command:
```
git branch
```
To make a new branch you can use the command: git branch my_new_branch_name
As we said before, you use "git checkout branchname" to switch between branches.
By default, if your repository has anything in it, it will have a master branch.
To merge branch branchname with the currently checked-out branch, you can type "git merge branchname"
git will tell you if there are conflicts. "git diff" will tell you which files were messed up by the merge.
After fixing the files, to resolve the conflicts type "git commit -a".

Example resolving conflicts

Conflicts might arise on a git merge, but also might arise on a git pull. As an example, consider:

%git pull
Auto-merging tmp.php
CONFLICT (add/add): Merge conflict in tmp.php
Automatic merge failed; fix conflicts and then commit the result.
%cat tmp.php
cat tmp.php
<?php
<<<<<<< HEAD
 echo "hello";
 echo "good bye";
=======
>>>>>>> a9a8ed990108598d06334e29c0eb37d98f0845aa
?>

Here % is the command prompt.

We could edit tmp.php and fix the conflict. Then to say there were no conflicts we do:
```
git add tmp.php
git commit -m "conflicts fixed and here is a message saying how"
```

Making patches

To make a patch with git you use the command:
```
git format-patch rev1 rev2
```
By default you will get a separate patch file for each commit between the two revisions. As an example of creating a single file patch via concatenation, we could do instead:
```
git format-patch e3e4f2067 --stdout > my.patch
```
Here no rev2 is given so it will be assumed to be HEAD.

To see the effects of a patch on current branch before applying it, you can do things like:

% git apply --stat my.patch
 test1.php |    2 ++
 test2.php |    2 ++
 test1.php |    1 +
 test2.php |    2 --
 4 files changed, 5 insertions(+), 2 deletions(-)

To see if the patch will cause any problem if applied, one can type:
```
git apply --check my.patch
```
Finally, to apply a patch to the current branch, you use
```
git am --signoff <  my.patch
```
Like svn, git repositories can be put on a server and made accessible remotely. This is what (Github does).
This is either done using git daemon, or using WebDAV extension to http. In either case, you can do your "git clone" with a url rather than a filesystem path.
If you've cloned such a repository, and made and commited modifications, and now want to send them back to the remote repository, you use the command "git push" or "git push remote_branch_name local_branch_name".

Git Tags

Unlike svn, where we might have a folder tags which has our different release project, with git we often directly make tagged revision of the master branch.
The production server than does a git checkout of that tag.
To create such a tag you might do,
```
git tag -a tag_name revision -m "message about creating tag"
```
For example, in our myrepos example, we might make some changes and commit and the commit has version number. We could make a v1 tag as follows:
```
git tag -a v1 c3ac05c -m "Made Version 1"
```
"git tag -l" lists what tags one has.
By default, when you do a git push, tags are not sent. To send them, use "git push --tags"
To get remote tags into your local git instance you can do:
```
git fetch --tags
```
In our case, we could cd into myrepos2 and then type this line.
```
cd ../myrepos2
git pull
git fetch --tags
```
To checkout a tag one can do:
```
git checkout tags/[tag_name]
```
In our example, in myrepos2, we could type:
```
git checkout tags/v1
```

Subversion and Git

Outline

Subversion