GIT is nice for its portability.
Here is a short memo in case you want to export a SVN (Subversion) repository into a GIT environment.

You need first to install the package git-svn and subversion.

First initialize your local repository.
mkdir foo
cd foo
git init

Then setup the repository to fetch the svn URL you are looking for. I found that the easiest solution to check out a SVN repository was by playing with the local repository configuration to get a remote svn repository.
git config --add svn-remote.$SVN_REPO.url http://url/to/check/out
git config --add svn-remote.$SVN_REPO.fetch :refs/remotes/$SVN_REPO
git svn fetch $SVN_REPO [-r$REV_NUMBER]
git svn rebase $SVN_REPO

SVN_REPO is the identifier you want to associate with your local repository.
REV_NUMBER can be added to specify a version number to check out.
What happens here is that the SVN repository is checked out as a remote branch.
~/code/test(master) $ git branch -a
* master
remotes/$SVN_REPO

Once this is done, you can use your local copy and check that in a central git repository or merge that with other works.

When SVN has to go through a proxy, it is important to set the file ~/.subversion/servers with the following options.
http-proxy-host = proxy.server.com
http-proxy-port = 8080

Developers are sometimes looking for cheap solutions to have their own private repositories. There are multiple solutions for open source software such as source forge or GitHub that can provide wide and secured functionalities. However, in the case of the 1st solution it is not possible to create private repositories, and in the second case private repositories are possible but this solution is not worth the money for independant programmers.

The cheapest solution remains in having its own hosting service (buying a domain, creating a free domain, etc). Google that will for sure lead you to free services with dedicated domain names for example.

Most of the time such hosting services are shared-hosting based. This means that multiple users are using the same server for their websites. In this case normal users do not have root rights (well, normal!), so it is impossible to make fine settings of the configuration files of apache, like httpd.conf.

GIT supports http protocol for its repositories for a long time, but the original protocol uses WebDAV and is really heavy and slow. Roughly, you needed to send to remote server entire files and not diffs. However, since version 1.6.6, GIT supports smart HTTP protocol, this has speed up http repositories and you do not even need WebDAV. An important point, WebDAV can be activated in httpd.conf of your apache server with the keywords “DAV On” but this creates an error, that’s why the solution presented here only uses smart http.

So, to set your GIT repositories, what is needed first is GIT installed on your server.
git --version
git version 1.7.0.4

The important point is to have support of the command git-http-backend.

This done, you also need the apache modules mod_cgi, mod_alias, and mod_env to be activated.

Now, let’s go through the whole setting process. In the case of this tutorial, our goal is to create a private repository for a project called foo-project. The private repositories that will be set are protected in read and write by apache group management.

From the root repository of your domain http://www.example.com/, if you have a connection through ssh, go to the root repository that should be called public_html. Then type the following command:
htpasswd -c .htpasswd user-name
You can also do that in another folder or in a subdomain of course.

You will be requested to write a password. This command will create a file called .htpasswd containing data like this:
user-name: $encrypted-passwd
“user-name” can be the name you want. It is an apache-level security group, so if you want you don’t need to use the same user name as your Linux session. This file contains user and password data for the access to private repositories.

It is possible to add new users to this file with commands like:
htpasswd .htpasswd new-user-name

Then create a file called .htgroup. It contains the following data:
foo_write: user-name new-user-name
This file will be used to control the group data of apache. You can create for each private repository a group with a list of users. One line has to be used for each group. Keep in mind that it is easier to maintain the group list in a common file. However you can set group file in different files if you wish. Just don’t forget to list those files in appropriate .htaccess files.

Then it is time to create the access control to private repositories. Create a folder called git in the root folder public_html and move in it:
mkdir git
cd git

There you need to create a new CGI script that will be used to rewrite requested URL for private GIT repositories. With an editor, create a file called git-http-backend.cgi with the following data in it.
#!/bin/sh
#first we export the GIT_PROJECT_ROOT
export GIT_PROJECT_ROOT=/to/site/folder/public_html/git/
 
if [ -z "$REMOTE_USER" ]
then
 export REMOTE_USER=$REDIRECT_REMOTE_USER
fi
 
#and run your git-http-backend
/usr/bin/git-http-backend

GIT_PROJECT_ROOT is an environment variable pointing to the root folder of your GIT repositories. A mistake here may lead to an error 500…

Depending on the server of your shared hosting service, git-http-backend may not be in /usr/bin/ but in /usr/lib/git-core/ or whatever. Be sure to check where it is with the command:
which git-http-backend

Then create an .htaccess file in git to control URL rewrite. It contains the data:
Options +ExecCgi
 
#This is used for group/user access control
AuthName "Private Git Access"
AuthType Basic
AuthUserFile /to/site/folder/public_html/.htpasswd
AuthGroupFile /to/site/folder/public_html/.htgroup
Require valid-user
 
#This is the rewrite algorithm
RewriteEngine on
RewriteBase /git
SetHandler cgi-script
RewriteRule ^([a-zA-Z0-9._]*\.git/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack))$ /git/git-http-backend.cgi/$1

Then it is time to create the GIT repository of foo-project and move in it.
mkdir foo-project.git
cd foo-project.git

Now you should be in folder /to/site/folder/public_html/git/foo-project.git.

Then initialize your GIT repository with the following commands.
git --bare init
git --bare update-server-info
cp hooks/post-update.sample hooks/post-update
chmod a+x hooks/post-update
touch git-daemon-export-ok

This basically makes all the necessary settings to allow your folder to use smart http mode. If you don’t care about GIT details, just copy/paste that!

What finally remains is to create an .htaccess file in public_html/git/foo-project.git to control access to this repository.
Allow from all
Order allow,deny
#foo_write is the group is .htgroup. All the users of this group will be authorized to access this repository at will.
Require group foo_write

The setting on remote side is done. So now, here is how to access to the remote from your local machine.
You may either clone the new git repository.
git clone http://www.example.com/git/foo-project.git

Or add a remote URL.
mkdir myproject
cd myproject
git init
git remote add myproj http://www.example.com/git/foo-project.git
git fetch myproj

It may be necessary to install the library curl and set the file called .netrc in your home repository (accessible with $HOME/.netrc) like this:
machine www.example.com
login user-name
password $mypasswd

If you don’t want to use .netrc file you can directly add you user name in the remote URL.
http://www.example.com/git/foo-project.git
Becomes
http://user-name@example.com/git/foo-project.git
In this case you will be requested a password each time you interact with the remote folder. This is annoying so you should stick with curl.

Then, manage your folder as you always do. First begin by pushing your first commits to your newly-made repository. Here is an example:
echo "My first commit" > README
git add README
git commit -a
git push origin master

When pushing to your repository, you may find upload package errors. A common message is:
error: unpack failed: unpack-objects abnormal exit
Don’t panic. You made it well. It should not occur normally but it may happen in certain environments. This is a write permission issue. Be sure to have the repository “objects” set with correct write permissions to allow a push to be written correctly in remote repository.

An additional tip…
There are also a nice pure php solution to allow you to have a gitweb-like service in pure PHP.
GitPHP is a web frontend for git repositories. This is extremely handy in a shared hosting environment as you do not need to set httpd.conf and you don’t need root rights on your server.

Have you ever looked for a cheap and efficient way to set up a GIT repository among multiple users without going through external services.
Some of them are really useful such as bettercode.net which allows to have private GIT repositories up to 2 GB.
Well, what is tiring about such services is that they have a looot of options.
When the point is only to look for a way to create a GIT repository and to code, why using such services?
Why not using a different way and simply create what you want: a CVS or GIT repository and not something else.

At this moment comes Dropbox.
Have you ever heard about it?
It is an external storage service that permits to share files among multiple computers synchronously.
The idea of GIT inside Dropbox is to put your remote GIT repository inside a Dropbox.
This way, your “remote” GIT repository is synchronized among all the computers linked to the Dropbox account.

Setting it is pretty simple.
First create an account in the Dropbox website and install Dropbox on your machine after downloading its client. Then you need on your machine GIT, git-core is most of the time sufficient.

After installing the package Dropbox on your machine, you will be asked to set a folder where all the files are synchronized, let’s call it $BOX_FOLDER here.
It may be better to subdivide the GIT folder in your Dropbix folder with something like $BOX_FOLDER/git.

Then respect the following steps to have new GIT folder called mygit.git.
1) Create remote repository in your Dropbox
cd $BOX_FOLDER/git
mkdir mygit.git
cd mygit.git
git init --bare

OK, now your remote repository is set. This GIT folder is the data that will be sent to your Dropbox.

2) Create folder on your local machine in your local repository… let’s say $LOCAL_FOLDER
mkdir $LOCAL_GIT_FOLDER
cd $LOCAL_GIT_FOLDER
git init
git remote add mygit file:///$BOX_FOLDER/git/mygit.git
git fetch mygit

By doing that your local folder is set and linked to the remote repository in your Dropbox.
When adding a remote connection to local folder “file://” means that remote repository is on your local machine.

3) Push your first commit
# Write some files
#commit them
git commit
git push mygit master

And you are done with your 1st commit!
You can then continue your stuff.

Advantages of this method:

  • Cheap and easy way to create private GIT repositories.
  • In case of multiple users, simply share the password and username of the Dropbox where repo is located!
  • Flexibility is wonderful, you can setup permissions to repository if you want.
    Some web hosting services do not allow you shell connection. Here you can do as you wish as remote repository is synchronized with you local machine.

Disadvantages:

  • [Edit] A GIT commit create several objects files that need to be synchronized with the remote server. If at the same time another user commits code before the synchronization of the first commit is done, folder may become corrupted. GIT in Dropbox may be better for a single developer or a team having a unique committer
  • Even if Dropbox is a cool tool, its synchronization takes some delay if several machines are linked at the same time. This delay may be from seconds to minutes, generally not more.
  • Dropbox may also cut a connection while synchronizing. If this happens, a condition to always keep the consistency of your GIT repository is to have only one machine linked to your Dropbox at the same time.

Postgres-XC, write-scalable cluster database manager based on PostgreSQL, version 0.9.4 has been released 1 week ago.
Its manuals have finally been released yesterday in Source Forge.
The latest release of Postgres-XC contains new functionalities and is based on PostgreSQL 9.0.3.

Here is the list of documents released.

You can also now download the manuals from a new GIT repository:
git clone git://postgres-xc.git.sourceforge.net/gitroot/postgres-xc/pgxcdocs

However to see the diff of the repository, you need to add this configuration to your git config file:
[diff "odf"]
textconv = odt2txt

And those lines to .git/info/attributes
*.ods diff=odf
*.odt diff=odf
*.odp diff=odf

©2010-2013 Michael Paquier All content is ©Copyright of Otacoo.com 2010-2013. Privacy Policy - Terms of Use