blino's website

Free software developer and more

Today, I have begun to set up an internal GIT repository, using the Git Repository Administration guide as reference.

So, let's create a /mnt/BIG/git repository on the (fictionnal) system, and restrict write access to members of the git group. This top directory has to be created with set-group ID, so that all users from the git group can add new objects.

urpmi git-core
useradd git -d /mnt/BIG/git
chmod +s /mnt/BIG/git

A projects/tests.git can be added this way (see the Git core tutorial for developers , Publishing your work section):

mkdir -p /mnt/BIG/git/projects/test.git
GIT_DIR=/mnt/BIG/git/projects/test.git git init-db
chmod -R g+w /mnt/BIG/git/projects/test.git

An interesting addition could be to pack the repository, as Samir informed me (see Git core tutorial for developers , Packing your repository section)

At this point, if a SSH server is available, users can clone the repository from a remote system, using the ssh:// protocol.

git clone ssh://
echo "Test" > README
git add README
git-update-index README 
git commit -m "initial README import"

This commits to the local repository, not to the repository.

To push changes on, users need write access, by being in the git group:

usermod -G git -a blino

Then, from a remote system, they can push their local repository changes to the master:

git push

An optionnal git-daemon can be configured, to make the git:// protocol usable (read-only).

cat /etc/xinetd.d/git-daemon <<EOF
service git-daemon
        disable         = no
        socket_type     = stream
        wait            = no
        user            = nobody
        type            = UNLISTED
        protocol        = tcp
        log_on_failure  += USERID
        port            = 9418
        server          = /usr/bin/git-daemon
        server_args     = --inetd --syslog --export-all --base-path=/mnt/BIG/git
service xinetd reload

For basic usage, the Git introduction tutorial (mostly for end-users) is a good starting point.

Importing a CVS module

set -e
cvs2svn --dump-only --dumpfile=$MODULE.dump /mnt/BIG/cvs/cooker/soft/$MODULE/
scp $MODULE.dump kenobi:
svn mkdir -m "add /soft/$MODULE/" svn+ssh://$MODULE/
ssh kenobi "sudo svnadmin load --parent-dir /soft/$MODULE/ /mnt/BIG/svn < $MODULE.dump"

Importing a single file to an existing module

I first tried to use an empty trunk to import a single file, but doesn't work with an empty trunk path. There is a patch to add support of empty trunk path to cvs2svn.

The best solution is probably to export in trunk, and load in /soft/build_system/robot/, that the file finally gets imported in /soft/build_system/robot/trunk.

mkdir fake-Upload-module
cp /mnt/BIG/cvs/cooker/soft/bugs/bin/Upload,v fake-Upload-module
cvs2svn --trunk-only --dump-only --dumpfile=Upload.dump fake-Upload-module
ssh kenobi "sudo svnadmin load --parent-dir /soft/build_system/robot/ /mnt/BIG/svn < Upload.dump"

But svnadmin load will fail when trying to create /soft/build_system/robot/trunk.

So I exported using --trunk=Upload, imported it to /soft/build_system/robot/, moved the file to trunk, and deleted the useless module...

I've tweaked Upload script on the build cluster to use youri, the wonderful upload system used for PLF. This script builds rpm packages from spec files, and shows additionnal comparison with the previous package release, such as changelog diff, requires diff, provides diff...

The main issue was the check of youri's return code, which was broken in warly's wrapper /o\

While Warly's gone on vacation, things always tend to screw up by themselves. Well, it's not that bad this time.

I just had to guess how to set up SVN accounts and manage SVN groups. It's configured in the conf/svnperms.conf configuration file, that I found next to the global conf/svnserve.conf file. It's not part of the standard setup, it's applied by the hooks/ hook (written by Gustavo \o/), run in hooks/pre-commit.

Other usual tasks include reset of password expiration (done with chage -d now <login> on kenobi and make -C /var/yp to update Yellow Pages)

I actually expected more trouble than that ;-)

blosxom Optimised for standards.
Olivier Blin (2005)