Development cycle

[Kurt Huwig]

Hi all,

I was working on something kind of similar, so I'd like to throw in some code
if possible. But maybe this is the wrong project, so let me first explain my
idea:

I am a user of Aegis for several years:

        http://aegis.sourceforge.net/

What I really like about Aegis is that it establishes a development cycle that
basically consists of:

- definition
- implementation
- review
- integration

as well as an enforcement to write automatic tests. Aegis uses RCS and tries
to enhance it to support features that Subversion has by default like atomic
commits, file rename etc. Basically if you use Subversion, you can have
something similar with much less code, which is what I did. Well on a very
small scale to fit my needs.

The development cycle helps a lot to improve code quality as well as project
overview. In my company, we first define the changes to be done in one line
descriptions and sometimes some short sentences to make it clear. This gives
a cheap overview of what is left to be done. Changes are usually something a
developer can do in 2h to 2 days. The review is done by peers and helped to
improve code quality and spread knowledge about how things work among the
developers. The integration leaves a trace about what has been done and get
rid of these "continued development" commit comments.

Thinking about this, I came up with the usual thing developers do: generalize
(sometimes until unuseablity). Why not have a review after the definition
stage? Why not have an automatic (as in code metrics) and a manual review?

The code I currently have allows to do the definition and the integration
steps. The review is done by commiting to a separate branch which can be
checked out by the peer and reviewed.

Another reason for this code was the need for semi-automated merging of
branches. Aegis makes this very easy by simply locking every file that leaves
the implementation stage until it is integrated into the "trunk". SVN imposes
the hassle to keep track of which changes in the trunk you already merged
into your branch. Well my code does this job for you by introducing a "delta"
file that contains a serial number of commits to the trunk. This does also
yield a nice version number that is unaffected by other commits to the
repository as it is only increased when the trunk changes.

So, as you guys seem to be deeply into this subject, is subissue resp. DITrack
the right place?
--
Greetings

Kurt Huwig (Vorstand)
Telefon [phone], Telefax 0681/96751-66
http://www.iku-ag.de/

iKu Systemhaus AG, Am Römerkastell 4, 66121 Saarbrücken
Amtsgericht: Saarbrücken, HRB 13240
Vorstand: Kurt Huwig, Andreas Niederländer
Aufsichtsratsvorsitzender: Jan Bankstahl

GnuPG 1024D/99DD9468 64B1 0C5B 82BC E16E 8940  EB6D 4C32 F908 99DD 9468

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...