On Thu, 2009-12-10 at 10:31 +0200, Pasi K?rkk?inen wrote: > So the git tree is basicly a fork of mplayer svn? > Is there some reason of not synchronizing the repositories? > > Are the new features considered bad in some way, so that they cannot be > integrated to the 'official' svn tree? > > Just trying to get the big picture here :) I'll try to give a reasonably short version. The basic reason the split exists is a difference in opinions between myself and Reimar about how to do development. MPlayer was originally started by people able to write code but with no clue about how to run/maintain a project, and has historically had quite bad development practices. Though some of the worst things have been fixed, the people who got used to those practices in the early project never really completely abandoned them in favor of any better ones, and Reimar still insists on doing things in much the same way. I think Carl is about the only new developer there has been since 2005 or so who seems to believe those practices are actually a good idea. I originally started the git repo for other reasons, including doing some large changes that were better initially done in a branch separate from the svn trunk that users compiled by default. However the above is why there still exists a separate svn repo where the changes (and now later ones) have not been integrated. As far as I can tell Reimar is not willing to accept code that has been developed in a way different from what he prefers, regardless of the quality or functionality of that code. The current situation is that I maintain the git repo and Reimar maintains the svn repo, with Carl doing some smaller stuff. Other developers are not active and/or competent enough to have a major effect on the overall situation. The git repository supports most of the functionality that exists in svn but not vice versa. There are enough changes in the git repo that it's very unlikely they'll be duplicated in svn. If I for some reason stopped maintaining the git repo and nobody else stepped up to handle overall maintenance of the codebase then most of the changes would probably be simply lost. If Reimar stops working on svn then the svn repo will likely stop being an at all viable alternative and fade away pretty quickly. If neither of those happens then both repos may exist for some time. In the long term I don't see much justification for the continued existence of the current kind of a separate svn repo though. The git repo has better features, and that difference is likely to increase rather than decrease in the future. While some of the changes involve tradeoffs, most notably the removal of the internal GUI (keeping it working after other changes would have required extra work which I decided was not worth it given how bad a shape the GUI was already in), I think they are overall beneficial to a significant majority of users. The main reason the svn repo exists separately without the git changes - wanting to do development in a particular way different from how the git repo is handled - is not in itself beneficial to any users, and I doubt it'll result in the creation of any significant advantages in the future either.
