<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>The Django source code repository — Django v1.2 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.2',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="top" title="Django v1.2 documentation" href="../index.html" />
<link rel="up" title="Django internals" href="index.html" />
<link rel="next" title="Deprecated/obsolete documentation" href="../obsolete/index.html" />
<link rel="prev" title="Django Deprecation Timeline" href="deprecation.html" />
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django v1.2 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../index.html">Home</a> |
<a title="Table of contents" href="../contents.html">Table of contents</a> |
<a title="Global index" href="../genindex.html">Index</a> |
<a title="Module index" href="../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="deprecation.html" title="Django Deprecation Timeline">previous</a>
|
<a href="index.html" title="Django internals" accesskey="U">up</a>
|
<a href="../obsolete/index.html" title="Deprecated/obsolete documentation">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="internals-svn">
<div class="section" id="s-the-django-source-code-repository">
<span id="the-django-source-code-repository"></span><h1>The Django source code repository<a class="headerlink" href="#the-django-source-code-repository" title="Permalink to this headline">¶</a></h1>
<p>When deploying a Django application into a real production
environment, you will almost always want to use <a class="reference external" href="http://www.djangoproject.com/download/">an official packaged
release of Django</a>. However, if you’d like to try out in-development
code from an upcoming release or contribute to the development of
Django, you’ll need to obtain a checkout from Django’s source code
repository. This document covers the way the code repository is laid
out and how to work with and find things in it.</p>
<div class="section" id="s-high-level-overview">
<span id="high-level-overview"></span><h2>High-level overview<a class="headerlink" href="#high-level-overview" title="Permalink to this headline">¶</a></h2>
<p>The Django source code repository uses <a class="reference external" href="http://subversion.tigris.org/">Subversion</a> to track changes
to the code over time, so you’ll need a copy of the Subversion client
(a program called <tt class="docutils literal"><span class="pre">svn</span></tt>) on your computer, and you’ll want to
familiarize yourself with the basics of how Subversion
works. Subversion’s web site offers downloads for various operating
systems, and <a class="reference external" href="http://svnbook.red-bean.com/">a free online book</a> is available to help you get up to
speed with using Subversion.</p>
<p>The Django Subversion repository is located online at
<a class="reference external" href="http://code.djangoproject.com/svn/">code.djangoproject.com/svn</a>. <a class="reference external" href="http://code.djangoproject.com/browser/">A
friendly Web-based interface for browsing the code</a> is also
available, though when using Subversion you’ll always want to use the
repository address instead. At the top level of the repository are two
directories: <tt class="docutils literal"><span class="pre">django</span></tt> contains the full source code for all Django
releases, while <tt class="docutils literal"><span class="pre">djangoproject.com</span></tt> contains the source code and
templates for the <a class="reference external" href="http://www.djangoproject.com/">djangoproject.com</a>
web site. For trying out in-development Django code, or contributing
to Django, you’ll always want to check out code from some location in
the <tt class="docutils literal"><span class="pre">django</span></tt> directory.</p>
<p>Inside the <tt class="docutils literal"><span class="pre">django</span></tt> directory, Django’s source code is organized
into three areas:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">branches</span></tt> contains branched copies of Django’s code, which are
(or were) maintained for various purposes. Some branches exist to
provide a place to develop major or experimental new features
without affecting the rest of Django’s code, while others serve to
provide bug fixes or support for older Django releases.</li>
<li><tt class="docutils literal"><span class="pre">tags</span></tt> contains snapshots of Django’s code at various important
points in its history; mostly these are the exact revisions from
which packaged Django releases were produced.</li>
<li><tt class="docutils literal"><span class="pre">trunk</span></tt> contains the main in-development code which will become
the next packaged release of Django, and is where most development
activity is focused.</li>
</ul>
</div>
<div class="section" id="s-working-with-django-s-trunk">
<span id="working-with-django-s-trunk"></span><h2>Working with Django’s trunk<a class="headerlink" href="#working-with-django-s-trunk" title="Permalink to this headline">¶</a></h2>
<p>If you’d like to try out the in-development code for the next release
of Django, or if you’d like to contribute to Django by fixing bugs or
developing new features, you’ll want to get the code from trunk. You
can get a complete copy of this code (a “Subversion checkout”) by
typing:</p>
<div class="highlight-python"><pre>svn co http://code.djangoproject.com/svn/django/trunk/</pre>
</div>
<p>Note that this will get <em>all</em> of Django: in addition to the top-level
<tt class="docutils literal"><span class="pre">django</span></tt> module containing Python code, you'll also get a copy of
Django's documentation, unit-test suite, packaging scripts and other
miscellaneous bits. Django's code will be present in your checkout as
a directory named <tt class="docutils literal"><span class="pre">django</span></tt>.</p>
<p>To try out the in-development trunk code with your own applications,
simply place the directory containing your checkout on your Python
import path. Then <tt class="docutils literal"><span class="pre">import</span></tt> statements which look for Django will find
the <tt class="docutils literal"><span class="pre">django</span></tt> module within your checkout.</p>
<p>If you're going to be working on Django's code (say, to fix a bug or
develop a new feature), you can probably stop reading here and move
over to <a class="reference internal" href="contributing.html"><em>the documentation for contributing to Django</em></a>, which covers things like the preferred
coding style and how to generate and submit a patch.</p>
</div>
<div class="section" id="s-branches">
<span id="branches"></span><h2>Branches<a class="headerlink" href="#branches" title="Permalink to this headline">¶</a></h2>
<p>Django uses branches for two main purposes:</p>
<ol class="arabic simple">
<li>Development of major or experimental features, to keep them from
affecting progress on other work in trunk.</li>
<li>Security and bug-fix support for older releases of Django, during
their support lifetimes.</li>
</ol>
<div class="section" id="s-feature-development-branches">
<span id="feature-development-branches"></span><h3>Feature-development branches<a class="headerlink" href="#feature-development-branches" title="Permalink to this headline">¶</a></h3>
<p>Feature-development branches tend by their nature to be
temporary. Some produce successful features which are merged back into
Django's trunk to become part of an official release, but others do
not; in either case there comes a time when the branch is no longer
being actively worked on by any developer. At this point the branch is
considered closed.</p>
<p>Unfortunately, Subversion has no standard way of indicating this. As a
workaround, branches of Django which are closed and no longer
maintained are moved into the directory <tt class="docutils literal"><span class="pre">django/branches/attic</span></tt>.</p>
<p>For reference, the following are branches whose code eventually became
part of Django itself, and so are no longer separately maintained:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">boulder-oracle-sprint</span></tt>: Added support for Oracle databases to
Django's object-relational mapper. This has been part of Django
since the 1.0 release.</li>
<li><tt class="docutils literal"><span class="pre">gis</span></tt>: Added support for geographic/spatial queries to Django's
object-relational mapper. This has been part of Django since the 1.0
release, as the bundled application <tt class="docutils literal"><span class="pre">django.contrib.gis</span></tt>.</li>
<li><tt class="docutils literal"><span class="pre">i18n</span></tt>: Added <a class="reference internal" href="../topics/i18n/index.html"><em>internationalization support</em></a> to
Django. This has been part of Django since the 0.90 release.</li>
<li><tt class="docutils literal"><span class="pre">magic-removal</span></tt>: A major refactoring of both the internals and
public APIs of Django's object-relational mapper. This has been part
of Django since the 0.95 release.</li>
<li><tt class="docutils literal"><span class="pre">multi-auth</span></tt>: A refactoring of <a class="reference internal" href="../topics/auth.html"><em>Django's bundled
authentication framework</em></a> which added support for
<a class="reference internal" href="../topics/auth.html#authentication-backends"><em>authentication backends</em></a>. This has
been part of Django since the 0.95 release.</li>
<li><tt class="docutils literal"><span class="pre">new-admin</span></tt>: A refactoring of <a class="reference internal" href="../ref/contrib/admin/index.html"><em>Django's bundled
administrative application</em></a>. This became part of
Django as of the 0.91 release, but was superseded by another
refactoring (see next listing) prior to the Django 1.0 release.</li>
<li><tt class="docutils literal"><span class="pre">newforms-admin</span></tt>: The second refactoring of Django's bundled
administrative application. This became part of Django as of the 1.0
release, and is the basis of the current incarnation of
<tt class="docutils literal"><span class="pre">django.contrib.admin</span></tt>.</li>
<li><tt class="docutils literal"><span class="pre">queryset-refactor</span></tt>: A refactoring of the internals of Django's
object-relational mapper. This became part of Django as of the 1.0
release.</li>
<li><tt class="docutils literal"><span class="pre">unicode</span></tt>: A refactoring of Django's internals to consistently use
Unicode-based strings in most places within Django and Django
applications. This became part of Django as of the 1.0 release.</li>
</ul>
<p>Additionally, the following branches are closed, but their code was
never merged into Django and the features they aimed to implement
were never finished:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">full-history</span></tt></li>
<li><tt class="docutils literal"><span class="pre">generic-auth</span></tt></li>
<li><tt class="docutils literal"><span class="pre">multiple-db-support</span></tt></li>
<li><tt class="docutils literal"><span class="pre">per-object-permissions</span></tt></li>
<li><tt class="docutils literal"><span class="pre">schema-evolution</span></tt></li>
<li><tt class="docutils literal"><span class="pre">schema-evolution-ng</span></tt></li>
<li><tt class="docutils literal"><span class="pre">search-api</span></tt></li>
<li><tt class="docutils literal"><span class="pre">sqlalchemy</span></tt></li>
</ul>
<p>All of the above-mentioned branches now reside in
<tt class="docutils literal"><span class="pre">django/branches/attic</span></tt>.</p>
</div>
<div class="section" id="s-support-and-bugfix-branches">
<span id="support-and-bugfix-branches"></span><h3>Support and bugfix branches<a class="headerlink" href="#support-and-bugfix-branches" title="Permalink to this headline">¶</a></h3>
<p>In addition to fixing bugs in current trunk, the Django project
provides official bug-fix support for the most recent released version
of Django, and security support for the two most recently-released
versions of Django. This support is provided via branches in which the
necessary bug or security fixes are applied; the branches are then
used as the basis for issuing bugfix or security releases.</p>
<p>As of the Django 1.0 release, these branches can be found in the
repository in the directory <tt class="docutils literal"><span class="pre">django/branches/releases</span></tt>, and new branches
will be created there approximately one month after each new Django
release. For example, shortly after the release of Django 1.0, the
branch <tt class="docutils literal"><span class="pre">django/branches/releases/1.0.X</span></tt> was created to receive bug
fixes, and shortly after the release of Django 1.1 the branch
<tt class="docutils literal"><span class="pre">django/branches/releases/1.1.X</span></tt> was created.</p>
<p>Prior to the Django 1.0 release, these branches were maintaind within
the top-level <tt class="docutils literal"><span class="pre">django/branches</span></tt> directory, and so the following
branches exist there and provided support for older Django releases:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">0.90-bugfixes</span></tt></li>
<li><tt class="docutils literal"><span class="pre">0.91-bugfixes</span></tt></li>
<li><tt class="docutils literal"><span class="pre">0.95-bugfixes</span></tt></li>
<li><tt class="docutils literal"><span class="pre">0.96-bugfixes</span></tt></li>
</ul>
<p>Official support for those releases has expired, and so they no longer
receive direct maintenance from the Django project. However, the
branches continue to exist and interested community members have
occasionally used them to provide unofficial support for old Django
releases.</p>
</div>
</div>
<div class="section" id="s-tags">
<span id="tags"></span><h2>Tags<a class="headerlink" href="#tags" title="Permalink to this headline">¶</a></h2>
<p>The directory <tt class="docutils literal"><span class="pre">django/tags</span></tt> within the repository contains complete
copies of the Django source code as it existed at various points in
its history. These "tagged" copies of Django are <em>never</em> changed or
updated; new tags may be added as needed, but once added they are
considered read-only and serve as useful guides to Django's
development history.</p>
<p>Within <tt class="docutils literal"><span class="pre">django/tags/releases</span></tt> are copies of the code which formed each
packaged release of Django, and each tag is named with the version
number of the release to which it corresponds. So, for example,
<tt class="docutils literal"><span class="pre">django/tags/releases/1.1</span></tt> is a complete copy of the code which was
packaged as the Django 1.1 release.</p>
<p>Within <tt class="docutils literal"><span class="pre">django/tags/notable_moments</span></tt> are copies of the Django code from
points which do not directly correspond to releases, but which are
nonetheless important historical milestones for Django
development. The current "notable moments" marked there are:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">ipo</span></tt>: Django's code as it existed at the moment Django was first
publicly announced in 2005.</li>
<li><tt class="docutils literal"><span class="pre">pre-magic-removal</span></tt>: The state of Django's code just before the
merging of the <tt class="docutils literal"><span class="pre">magic-removal</span></tt> branch (described above), which
significantly updated Django's object-relational mapper.</li>
<li><tt class="docutils literal"><span class="pre">pre-newforms-admin</span></tt>: The state of Django's code just before the
merging of the <tt class="docutils literal"><span class="pre">newforms-admin</span></tt> branch (see above), which
significantly updated Django's bundled administrative application.</li>
<li>Tags corresponding to each of the alpha, beta and release-candidate
packages in the run up to the Django 1.0 release.</li>
</ul>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">The Django source code repository</a><ul>
<li><a class="reference internal" href="#high-level-overview">High-level overview</a></li>
<li><a class="reference internal" href="#working-with-django-s-trunk">Working with Django’s trunk</a></li>
<li><a class="reference internal" href="#branches">Branches</a><ul>
<li><a class="reference internal" href="#feature-development-branches">Feature-development branches</a></li>
<li><a class="reference internal" href="#support-and-bugfix-branches">Support and bugfix branches</a></li>
</ul>
</li>
<li><a class="reference internal" href="#tags">Tags</a></li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="deprecation.html">Django Deprecation Timeline</a></li>
<li>Next: <a href="../obsolete/index.html">Deprecated/obsolete documentation</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django v1.2 documentation</a>
<ul><li><a href="index.html">Django internals</a>
<ul><li>The Django source code repository</li></ul>
</li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/internals/svn.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" size="18" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Oct 20, 2010</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="deprecation.html" title="Django Deprecation Timeline">previous</a>
|
<a href="index.html" title="Django internals" accesskey="U">up</a>
|
<a href="../obsolete/index.html" title="Deprecated/obsolete documentation">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
distrib
>
Arklinux
>
devel
>
i586
>
media
>
main
>
by-pkgid
>
5fcb1fedf34660bc240dc59b7bfcebc4
>
files
>
298
