[Lazarus] SubVersion vs Git

[Florian Klaempfl]

Graeme Geldenhuys schrieb:
> 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?

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 :)