On Thu, 2007-08-16 at 16:37 +0800, Martin Ellison wrote: > > Could you explain this more? svn allows branching, so why not just > create as many development branches as required and work there? > > I do not know git, so could you please explain what git has over svn? > (Not intended as an attack).
SVN is centralised, git is decentralised. Git is reputably easier to merge. It also has "scalability" advantages, esp. wrt branching. In git, there is no authority. If I want to add a cool feature, I fork a repository, and add a feature. My repo then becomes one among any number of forks of the project. It is successful for Linus on his kernel development, but I think in Cinelerra it has lead to a bit of a mish-mash - surprising since the Linux kernel is undoubtedly a 2,3,4 or even 5 orders of magnitude more complex than Cinelerra. I think the problem is that git is good at creating forks, but merging is a social issue. So I might create a cool feature, but there's no guarantee that it will make it upstream. What Linus does is have a core of developers who he trusts, and he willingly accepts patches from his core team. He probably doesn't even look at what anyone else does. Now, those core developers probably work in key separate areas, meaning clashes are kept to a minimum. The core team, in turn, have their trusted sources - and in this way, the whole thing builds like a pyramid with Linus at the apex, Lord of all he surveys. Now, I could go and take a copy of the Linux kernel, and immediately produce a fork, declaring my branch to be superior. But that's a really bad idea. It's a bad idea because no-one is interested in my fork. What I probably should do if I want to submit a patch is branch something that is interested in the kind of patch that I want to contribute, and whose branch is eventually propagated upstream. And I think this is the main problem we're seeing in Cinelerra: lots of branches, but no upstream merging. So we're seeing lots of people making useful contributions. but that the code is just whithering on the vine. And I strongly suspect that as time goes on, the patches will become unmergable. Probably git is much better at svn when it comes to merging; but like svn, it isn't able to magically resolve code conflicts. I think what I'm saying is that git is merely a tool, it doesn't solve the social and organisational issues. That's for humans to sort out. At the moment, what I see, as I understand it, is: * Cinelerra-HV, which is Heroine's version * Cinelerra-CV, which is basically HV plus or minus a few patches, * "ct", which is happy to part from both, attempting to bring architectural improvements and some bug fixes * cinelerra 3, which is basically a Cinelerra redesign * a number of other players (including my branch), which attempt to do various things in various combinations Git makes it easy to create forks. But forking is a serious business, and shouldn't be undertaken lightly. I think interested parties really need to discuss this issue. And perhaps we should be asking the question "should we even really have a Cinelerra-CV version?" Another key question might be: "who produces the most code: HV, or CV"? If HV is chugging along at a steady pace, rarely accepting patches, whilst CV is mired in difficulties, then one might form the conclusions that it's better just to use HVs code, and forget about CV, or maybe just use it for occasional minor bug fixes. OTOH, if the opinion is that HV is sluggish, buggy, and the CV version would be more dynamic, then we should probably conclude that we should form a proper fork, probably using git, and let HV play catch-up with us. It all depends what you think. _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
