[ditz-talk] Dummies guide to ditz

William Morgan wmorgan-ditz at masanjin.net
Tue Sep 2 22:36:36 EDT 2008


Reformatted excerpts from Dalton Calford's message of 2008-09-02:
> 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
> repository?

I would recommend having the ditz files tracked by git alongside the
code. I think that also answers this question:

> 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?

If the Ditz issue database (the bugs/ directory) is under version
control, then this is taken care of for you by git. As long as no one is
modifying the repo on the server directly (i.e. it's a 'bare' repo and
is only pushed to and pulled from), then you're guaranteed no conflicts.

If you're using 'ditz html', you probably want to have a git hook that
runs that command when someone pushed a commit, If you're using sheila,
you may have to do a little legwork to make it resync upon a git push.
(Or maybe it should just periodically check the last modified time of
the bugs directory and reload the project hwen that changes.)

> 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?

Yes, me. :)

I didn't understand all the project creation stuff completely, but
wouldn't it be easier to create a new project by just cloning a base
project that had everything set up correctly, including the README, the
ditz bugs/ directory and configuration, etc? Then you only have to
create that thing once, and you don't need to write and maintain scripts
that regenerate it.
-- 
William <wmorgan-ditz at masanjin.net>


More information about the ditz-talk mailing list