On 11/5/08, Florian Klaempfl <[EMAIL PROTECTED]> wrote: > No. The point is that a dvcs has drawbacks. The distributed nature > requires a very strict management of repository structure and for the > changeset flow.
You have the exact same issues with SubVersion! > Which repository is used the create the releases? The same servers hosting the current SubVersion could be used as the "master" repository if you want. But other distributed repositories could also be setup to ease the load on the main server. Much like svn2.freepascal.org is used for. The secondary repositories could then be setup to push changes (manually or automatically) back to the primary server - at times when the main server normall has low load. > Who > merges to this repository and when? Who merges changes and patch now to SubVersion? Those same users would have write access to the Git repository. > What if somebody never pushes his > changes and keeps them local till his harddisk breaks? Same can be said for SubVersion. What if you make local changes and never commit a patch? At least with local commits in Git, you still have the benefit of seeing revision changes between all your local work. So I can implement something of say a 1 month period. I can see what I changed and undo changes locally as I see if. Once the feature is 100% implemented, I can push those changes to somebody that can commit in the primary server. With SubVersion my 1 months changes will be a single revision. I have no undo during that month or incremental history of my feature. >How does testing > work? When are tests run? At every commit? Every push? Who does testing work in SubVersion, Who runs the tests? When does test get run? I fail to see how this is any different between Git and SubVersion? > the more complex use of a dvcs. Here at work I'am happy if people use > svn up/svn co correctly and not do svn rm/svn add to commit a changed file. And why would using Git be an issue in this case? Simply don't give them write access the primary repository. They could push changes (via direct commit, or as a patch emailed to you) and you can review changes before it's applied permanently. Git can make patch too - you don't always have to commit directly to a server. > With subversion is this self regulated and the structure subversion > offers is enough for smaller projects like fpc/lazarus. Please watch the YouTube demo on Git. You will find it enlighening - I'm busy watching it now. The guy doing the demo has only used Git in small teams 3-6 developers and admits he hasn't used in in large environments (like Linux kernel), yet he is still impressed by the improvements over CVS and SVN. [http://www.youtube.com/watch?v=8dhZ9BXQgc4] There are lots of small, but impressive, pieces of information in that talk. Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
