> -----Original Message-----
> From: David Sitsky [mailto:sits@...]
> Sent: Tuesday, February 10, 2004 3:22 PM
> To: Kelly F. Hickel; Matthew Hailstone; codestriker-
> Subject: Re: [Codestriker-user] Feature request
> > Hi David,
> > Just FYI, we don't do development this way, nor does any
> > development organization that I've been a part of for the last 20
> > We do projects in branches, have the branches reviewed, do unit
> > THEN merge it to the main line of development. We want our
> > to be able to do a commit at any time (and urge them to do it at
> > daily) to prevent mishaps due to power outages, drive failure, etc.
> > This has paid off more than once! The other issue arises when
> > working on a change that affects several different platforms (aix,
> > solaris and windows for instance), you need to be able to commit, so
> > that you can check the code out on the other machines to do unit
> > testing.
> Hi Kelly,
> I guess the key message here is that with your process, each developer
> their own separate _private_ branch, so even if they do daily commits
> their private branch, there is no impact to the rest of the
> team. With your process, there is still a way once the work has been
> completed, to generate a diff that can be reviewed, and then merged
> the main branch.
> With the process described by Matthew, unreviewed code from more than
> developer is being committed into a branch/main trunk, which I think
> big problem.
> The basic message is unreviewed code should never be committed to a
> "public" branch that other developers are using.
While I (in theory) agree with your last statement, we do have
multiple developers working on projects (not always, but often), and so,
they do share a branch. They are fully authorized to beat each other
with a wet noodle if one of them breaks the other's code (;>), but it
does happen. We do the reviews at the end, and sometimes the reviews
cause changes, so we need to review it again, requiring a new
codestriker topic, instead of just updating the existing one.