[Lazarus] OT: test message

Mark Morgan Lloyd markMLl.lazarus at telemetry.co.uk
Wed Nov 5 17:38:37 CET 2008

On 11/5/08, Florian Klaempfl <florian at freepascal.org> wrote:
>  > Hm. It is true that DCVS _allow_ various policies and workflows unavailable
>  > to centralized ones, but I do not see how such policies are required.
> At least the development of FPC has shown that such policies are needed.

And why can't you have that same policies for a Git repository?

>  > His changes do not get into the release -- same as if he would make changes
>  > to his working copy in SVN and not commit / send patches out.
>  > Notice the very important difference here: while in SVN these changes
>  > are "hidden"
> No.

Florian, I fail to understand your problem.... And fully agree with
Alexander. At the moment with SubVersion - if I do not send you a
patch, my changes are going nowhere. So if my hard drive breaks, that
information is lost. The exact same rule applies to Git. If I don't
push the changes to you, or send you a patch via email and my hard
drive breaks. That information is lost - unless somebody
pulled/fetched changes from my Git repository.

> This is where one uses branches in svn: everything is already in a
>  central storage, interested people get easily informed about the change
>  because they read commit logs, no need for local backups, no hazzle to
>  publish local trees and fast access for everybody.

And to use branches I need write access to the SVN repository. So now
you will be happy giving everybody write access? And filling the
'branches' directory with everybody's experiments.  That brings me to
the other point (also mentioned in the Git video).  What if you like
to experiment, but don't want others to see? Say I try something out
and it fails, or the idea just isn't viable anymore.  Everybody has
seen your failure and you feel miserable. At least with Git, I could
experiment without bothering others, not even requiring write access
to the "primary" repository. If I fail, only I know about it. If I
succeed, I will push the changes forward. :-)

>  >> How does testing work?
>  > As usual, somebody runs tests and checks the results.
> No, everybody, not somebody, has to run tests, at least for FPC.

Yes, we use SubVersion in our company as well and also have that rule.
We still get times when developers fail to run the tests before they
commit - and trunk is broken.  This happens often in Lazarus Trunk as

What we do for the tiOPF project is setup automated unit tests. It
runs every 3 hours under Windows with Delphi 7, 2005, 2007 and every 3
hours under Linux with FPC 2.2.3. Summary results are emailed to the
tiopf.dailybuilds newsgroup. If failures occurred, the failure results
are attached to that email.
So even if you commit without running tests locally first, the longest
a bug will go unnoticed is 1.5 hours (Windows and Linux test runs are

  - Graeme -

fpGUI - a cross-platform Free Pascal GUI toolkit

More information about the Lazarus mailing list