Graeme Geldenhuys schrieb: > 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?
A git repository requires even more. > >> > 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. Indeed, but as soon as you commit on svn, things are save, this is not true for git. > 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? People having asked so far, got their own branch, at least for FPC. > And filling the > 'branches' directory with everybody's experiments. Doing svn rm is rather simple if needed. But I'd be happy to see people filling branches with experiments, yes :) > 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. :-) If they are accepted. In the worst case you worked months on the wrong track because you got no feedback. It is a point for NDA affected stuff, but imo no common use case for FPC/Lazarus. > >> >> 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! This doesn't solve git either, it makes things probably even worse: people think there local tree works and they tested all commits so they push without testing. > > 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. FPC does this too (nightly) but it often doesn't help either ;) > 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). > Anyways, since git is near to unusable on windows anyways, it is out of the game :) _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
