On 11/5/08, Florian Klaempfl <[EMAIL PROTECTED]> 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 well! 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 staggered). Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
