[ditz-talk] Dummies guide to ditz

Dalton Calford dcalford at distributel.ca
Tue Sep 2 11:55:38 EDT 2008

Warning, long post.

I am setting up a central git/ditz/gitpserver repository.

I want to make sure that my assumptions are correct with the project, so
I want to be as clear as to what I am doing and why, so that any
mistakes I am making are caught.

First, I am producing a git repository, on a linux (ubuntu) box.
It is a shared repository with many projects, a git-pserver
implementation and a web front end.

I want ditz to be the issue tracker.

I use ACL's to manage the low level file permissions as one or more
groups may have r/w access, while one or more other groups would have
r/o access, everyone else would not see the project.  We use the windows
domain controller to manage users and their group membership.

The root of the repository is in the /home/git directory.

Because git needs special settings to run as as cvs-pserver, we have put
all the setup elements into a single script.

The script would be run as a local user from the command prompt or it
can be called from a web script (I can provide all of this to anyone who
wants to know how it is done).  I am going to give a text explanation as
the script itself may be confusing to those who are not totally familiar
with the environment.

The script takes three arguments
1. project name
2. group name
3. user name (this is for the web script)

After verifying user and group rights/existence on the server, the
script performs the following steps

1. creates a directory in the /home/git/ directory with the same name as
the project.  -the directory is created as the user passed as $user
2. changes into the newly created directory and performs a "git --bare
init --shared
3. creates a directory called ".notbare" and changes directory into it.
4. performs a "git-init --shared=all" and touches README (creating an
empty README file)
5. performs a "git-add README" and a "git-commit -m 'Added README'
6. returns to the project directory.
7. fetches in the newly created .notbare project
8. gets rid of the .notbare project
This is due to the needs of the git-pserver code to have existing
material in the repository, and it needs to be in the proper location.

for example, for a project called "foo"
cd /home/git
mkdir foo
cd foo
git -bare init --shared
mkdir .notbare
cd .notbare
git-init --shared=all
touch README
git-add README
git-commit -m 'Added README'
cd /home/git/foo
git-fetch .notbare 
rm -fr .notbare

All the steps with the .notbare directory can be accomplished with a
default empty project, but, as there is no guarentee that the end user
would have such an animal, we go through all the steps.

Now with the project needs a few more steps performed

git-branch -M $project (create a branch with the project name)
git-config gitcvs.enabled 1
git-config gitcvs.ext.enabled 1
touch cvs.log
chmod 666 cvs.log
git-config gitcvs.logfile `pwd`/cvs.log
git-config gitcvs.ext.logfile `pwd`/cvs.log
mkdir logs

So now that the various setup stuff has been explained, now we get to
the part about the git.

1. in the project directory, we create two files - .ditz-config
and .ditz-plugins.
The ditz-config file has standard settings (bugs directory etc)
The plugins file has git, git-sync and issue-claiming enabled.

2. in the project directory we perform a ditz-init,a ditz-add-release
and a ditz-release all via expect scripts. (I can provide the details on
this for anyone who wants them)

3. we run 'ditz html' 
4. we touch gitcvs.$project.sqlite

we then setup all the file rights/permissions etc and make a link from
our apache web tree to the html directory so that the web server always
is pointing to the correct index.html for the project.

So, here are my questions

1.)  Since this is designed for remote work, only projects pushed or
pulled into the repository work, so the ditz stuff is not really part of
the repository - should they be added as part of the cvs setup code (ie
where we create the readme file) and then fetched into the newly created

2.) We want the issues to be able to be updated locally and merged into
the project, how would you set up the repository to work with git?

3.) We are creating a web interface for ditz and I am currently
reviewing the sheily code to see how that works - is anyone interested
in this?

best regards


More information about the ditz-talk mailing list