ok, I've found http://git.or.cz/course/svn.html.
On 16/08/07, mark carter <[EMAIL PROTECTED]> wrote: > > 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 > -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
