welcome: please sign in
location: Diff for "versionControl"
Differences between revisions 23 and 24
Revision 23 as of 2014-08-22 10:29:13
Size: 4413
Editor: kristian
Comment:
Revision 24 as of 2014-08-27 09:58:22
Size: 4414
Editor: kristian
Comment:
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
 * To push changes to the remote server, first commit locally {{{git commit -m "This version is awesome."}}}, then push to the server {{{git push}}}. Likewise you can pull changes from the server {{{git pull}}}.  * To push changes to the remote server, first commit locally {{{git commit -am "This version is awesome."}}}, then push to the server {{{git push}}}. Likewise you can pull changes from the server {{{git pull}}}.

A version control system is useful when working on a collection of files that evolves over time, in particular if several people are modifying the files. For example, version control is often used in software projects to store the code in a way that several developers can access and contribute to the code without the need to send files by e-mail etc. Another example is when you are writing a paper with your colleagues and you need to efficiently and safely share your additions to the paper. A version control system also keeps track of the history of your contributions; most version control systems can be used to retrieve the state of your files as of a given date. This means that there is no need to create local back-up copies. To make it short and sweet: version control means you can relax.

Git

Git is currently the preferred version control tool at the department. For starters you might want to look at a git tutorial I wrote some time ago git-tutorial.pdf. There are also heaps of tutorials out on the net. A quite comprehensive manual is Git Magic, another pretty good one is Git for Scientists. It is also quite handy to have a cheat sheet handy beside the keyboard for those quick command-and-options lookups.

Talk to Anders Nilsson in order to have a repository for your files set up, or if you want to know more about version control.

Setting up GIT

You can run GIT locally on your machine. How to do this is covered here. If you want a repo subsiding on one of the control servers, this is what to do:

  • Create an SSH key pair and send the public key to Anders Nilsson, mentioning that you want to use GIT. (First check that you don't already happen to have an SSH key pair, in which case creation is superfluous). Keys normally recide in ~/.ssh. The private key is in id_rsa, while the public key is in id_rsa.pub. If you don't have these files, create them with the ssh-keygen command, described here.

  • To create a repo, make sure you are on a computer with the correct ssh key and then, in the terminal, type:

git clone ssh://gitolite@git.control.lth.se/user/repo

Replace repo with the desired repository name and user with your user name. The repo will be created on the server and cloned to the current directory on your machine.

  • To see your server side repos, log into any fedora machine at the department and inspect /home/repo/gitolite/repositories/user, where user is your user name. If you want to delete repos from here, contact Anders Nilsson.

  • To push changes to the remote server, first commit locally git commit -am "This version is awesome.", then push to the server git push. Likewise you can pull changes from the server git pull.

On OS X you might encounter annoying warnings like

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_CTYPE = "UTF-8",
        LANG = (unset)
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

when communicating with the server. An easy fix to this is to avoid sending your locale settings to the server over SSH, by commenting out SendEnv LANG LC_* in /etc/ssh_config (sing a leading #).

Subversion (deprecated)

The version control system Subversion is installed on one of our servers. Currently, it is used for a number of research projects, some master's thesis projects and for the projects in the Project in Automatic Control course. However, since git reached maturity a couple of years ago there is very little reason in creating new subversion repositories unless you have good reasons to do so.

SubversionTracGuidelines

versionControl (last edited 2020-02-13 13:03:00 by albheim)