Jeff Anderson wrote: > Malcolm Tredinnick wrote: >> On Wed, 2008-09-10 at 16:15 -0600, Jeff Anderson wrote: >> >>> Jacob's git repo is great. Trac has at least a couple plugins that can >>> handle git repos. >>> >>> There are enough people who are willing to contribute to the development >>> of Django that it might not be a bad idea to consider moving to the >>> distributed model. >>> >>> I'm starting this thread to encourage healthy discussion. I forbid holy >>> wars and flaming. >>> >>> Has making a move to a distributed model already been discussed for >>> Django? The closest I've seen is Jacob announcing his git repo, and >>> that's about it. I haven't seen any serious discussion among core devs >>> about the idea. >>> >> You don't even begin to approach why this might be a good idea for >> Django. So, what does it gain? >> >> Right now, you can already use your distributed VCS of choice with >> Django and subversion. Some of us have been doing that for literally >> years. The only time I ever use "svn" is on the very rare times I want >> to alter subversion metadata properties. However, subversion is a very >> good lowest common denominator for everybody to use as the central >> repository and it makes a lot of sense to continue to have a central >> repo. >> > The problem with going with the lowest common denominator is just that-- > the lowest common denominator also means less features. In this case, it > means I'm stuck with subversion's linear development. non-linear > development is a requirement for the distributed model of software > development. > > If I want to start a branch in my own repo, I can do that. The problem > happens when merge conflicts start happening. I'm forced to do things > "the subversion way" when I'm stuck with a subversion backend. I > **must** rebase my work rather than merge. This isn't really a good > thing in the distributed environment. It also breaks my ability to > directly check in things from my branches and repos-- when people are > constantly rebasing their work, I lose any ability to really track their > branches, and almost all advantages of using a distributed RCS. > > Continuing to have a single, central repo isn't exactly moving to the > distributed model of development. I didn't realize that I needed to > explain the differences between the central repository model and the > distributed model, but I'll try. They are very different philosophies. > I'm suggesting that Django considers this philosophy of developing > things in a distributed fashion. I'm not suggesting that Django continue > using a centralized repo model, and simply switch from svn to another > tool. I'm sorry if that's what it sounded like. > > A distributed model would mean abandoning this notion of committers and > non-committers, and thus also the concept of a central repository. There > are plenty of blog posts and documents about this approach to software > development, their benefits, and weaknesses. I highly suggest doing > research on this approach if you aren't terribly familiar with it. > > One way that it *might* work for the Django is each component would have > someone that "watches over" it. Someone would be over the translations, > someone would be over forms, brosner would probably be over the admin > app, etc. Translations I believe is a good example. A translator for a > particular language or locale would update their working copy and > commit. Their changes would get merged into the translation manager's > repo. Generally, a release maintainer would be the one that merges in > stable/completed features into their git repo, so they'd merge in > anything when the translation maintainer says he has more stuff ready. > > This is very different from the way that things currently work. There > wouldn't really need to be any formal decisions about "who is in" and > "who is out" for commit access. If the release maintainer feels person x > is capable of taking care of a certain task, whoever person x might be > has just become a committer. They can't commit to a central repo, but > they can commit all they want to their own. > > I'm not simply suggesting "let's use tool x instead of tool y". I'm > suggesting a philosophy change in the way that Django development is > handled. I don't really have anything against subversion, it does what > it is designed to do very well. I am in favor of considering new ways of > doing things, and re-examining philosophies that are followed. That is > how I became a linux user, and a Python programmer. That is why I > started using Django. I was investigating a new way of doing things, and > found that Django had something good to offer. Here I'm just presenting > an alternate philosophy, and hoping for discussion to take place. I > believe that embracing the distributed RCS philosophy will help nurture > the development of Django in the long run. > > Basically, what I'm really trying to say is that there is no pony yet. > There is only a really big pig with a fake pony tail tied onto it, > wearing a saddle. Very ugly. Very Scary. Close your eyes. Little girls > are screaming. > Well, speaking as an old fart, and something of a stick-in-the-mud, I am interested in using the best possible version control system, but even more interested in something that's easy to use.
When you consider attracting new members to the development community, ease of use of the development infrastructure is important. I've heard good things about Mercurial, Bazaar and git, but I get the impression that git is sometimes difficult to drive. Overall the idea of a distributed version control system is great. But will I be able to drive it without getting myself in a mess? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
