Using version control with django

[Rich Shepard]

I want to track django projects with subversion. (Single developer, local,
so svn is better suited than the distributed git and mercurial.) I'd like
advice on how to lay this out vis-a-vis the django layout.

Project overall root is ~/development/crm-project. This directory
contains:

Makefile README crm-project/ docs/ manage.py* requirements.txt

The top-level project directory is the same-named crm-project, and this
contains:

__init__.py __pycache__/ settings.py urls.py
__init__.pyc crm/ settings.pyc wsgi.py

The app directory is crm/.

So, where should I place trunk/, tags/, and branches/ be created? If
they're in the overall project root (~/development/crm-project/) should I
then move that directory's contents into the newly made trunk/ subdirectory?

I find nothing in my web searches for using svn with django. Perhaps my
web foo is insufficient.

Rich

[Gergely Polonkai]

Hello,

the fact you develop alone doesn't make SVN a better choice than Git, Mercurial, or any other distributed version control. But as you already made your choice, here are my two cents.

You should put all the stuff under trunk/, so it becomes trunk/manage.py, trunk/crm/, etc. If you are developing for multiple customers, the branches and tags directory may come in handy later. Also, it's nothing but naming convention: you can call these directories dog/, Pete/, and ananas/. But that’s more for a Subversion user list, not Django.

On the other hand, you definitely should choose a distributed version control if you are working alone. For example, Git, Mercurial and Fossil repositories are self contained, which means the whole development history is located right where you work. If you decide to publish (or just backup) your work, all you need to do is to add a new remote. With SVN, it's hard to publish somewhere else than before (read: it’s a real PITA to migrate SVN history from one server to another).

Best,
Gergely

[François Schiettecatte]

I would add a +1 for git, I started off with svn and switched to git, branching and merging is much easier which really helps when you want to test ideas.

François

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACczBUJ3apCi5pgsm%3D768HA3dU0-%3DL%2B8Q16fgTaMjKXttRMuTg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Rich Shepard]

On Tue, 23 Aug 2016, Gergely Polonkai wrote:

> You should put all the stuff under trunk/, so it becomes trunk/manage.py,
> trunk/crm/, etc. If you are developing for multiple customers, the
> branches and tags directory may come in handy later. Also, it's nothing
> but naming convention: you can call these directories dog/, Pete/, and
> ananas/. But that’s more for a Subversion user list, not Django.

Gergely,

That's what I suspected to be the case.

> On the other hand, you definitely should choose a distributed version
> control if you are working alone.

Well, subversion's served me well since I replaced CVS with it. Backups
are daily (using dirvish) and since the repository's been in the same place
for almost a couple of decades it's not likely to be moved. :-)

Thanks for confirmation,

Rich

[Rich Shepard]

On Tue, 23 Aug 2016, François Schiettecatte wrote:

> I would add a +1 for git, I started off with svn and switched to git,
> branching and merging is much easier which really helps when you want to
> test ideas.

François,

Thanks for your insight,

Rich

[Mike Dewhirst]

On 24/08/2016 5:42 AM, Rich Shepard wrote:
> I want to track django projects with subversion. (Single developer,
> local,
> so svn is better suited than the distributed git and mercurial.) I'd like
> advice on how to lay this out vis-a-vis the django layout.

I use svn too. I hope git is a passing fad.

My entire project is in trunk and I always deploy to the staging server
directly from trunk

I work on the project in the "mike" branch and that's what is used by
the dev server

I merge from mike into trunk and test before deploying to staging

When comfortable, I make a tag with the version number and deploy it to
production via a script on the production server which exports the named tag

My svn server is online so other devs can have their own branches. You
can branch trunk any time to work on a specific feature and merge it
back or discard as desired. I frequently branch from mike and so on.

I have the mike branch in a couple of virtualenv directories (for
pythons 2 and 3) and trunk lives in its own directory with py2.7 because
both servers run 2.7 (which has to stop before I go mad - gotta get to
3.x exclusively).

I never work on trunk directly but always on a branch and merge that in
for testing in trunk. If testing throws up a problem I revert the merge
and go back to work in the branch.

HTH

Mike

[Rich Shepard]

On Tue, 23 Aug 2016, Gergely Polonkai wrote:

> On the other hand, you definitely should choose a distributed version
> control if you are working alone. For example, Git, Mercurial and Fossil
> repositories are self contained, which means the whole development history
> is located right where you work.

Gergely,

SVN is also self-contained, unless a separate repository is created for
each project. Regardless, after looking at some docs I decided to move from
svn to git. Since I'm not a professional developer I don't know it will make
any difference to me, but ...

I also keep versions of important documents, such as books or articles
submitted for publication and drafts of my expert opinons when I'm retained
for litigation support. While svn had no problem keeping each branch of its
repository tree separate, perhaps the maintenance of separate repositories
(one for each project) will not be onerous.

Suggestion taken,

Rich

[Tim Chase]

On 2016-08-23 12:42, Rich Shepard wrote:
> I want to track django projects with subversion. (Single
> developer, local, so svn is better suited than the distributed git
> and mercurial.)

I used subversion both as a solo developer and as part of a team, and
have migrated to a DVCS for both simply because my code/repo can be
on multiple machines (laptop, desktop, hosting service, etc) even if
it's not part of a team, and branching/merging is much less painful
(well, branching in SVN is easy, it's the merging that I never found
easy). While I've settled on git for my needs (as has my $DAYJOB), I
have also used and endorse both Mercurial (hg) and Fossil as strong
competitors. For the solo developer (or small team) Fossil has some
really compelling features such as a built-in web interface that
includes a wiki and bug-tracking/ticketing system. Mercurial's
learning curve was a little shallower when coming from SVN yet will
still giving you most of the power of git (I think pretty much all
of git's functionality can now be mirrored with Mercurial but you
may have to enable some of the features that are disabled by default).

> So, where should I place trunk/, tags/, and branches/ be
> created? If they're in the overall project root
> (~/development/crm-project/) should I then move that directory's
> contents into the newly made trunk/ subdirectory?

Yes. Though see below about Subversion's partial checkouts.

You'd want the root of your project in the root of your trunk/master
which means Subversion would have

$ROOT_DIR/.svn/
$ROOT_DIR/trunk/.svn/
$ROOT_DIR/trunk/__init__.py
$ROOT_DIR/trunk/settings.py
$ROOT_DIR/trunk/crm/
$ROOT_DIR/trunk/crm/.svn/
$ROOT_DIR/trunk/crm/...
$ROOT_DIR/trunk/urls.py
$ROOT_DIR/trunk/wsgi.py
$ROOT_DIR/branches/...
$ROOT_DIR/branches/.svn/
$ROOT_DIR/tags/...
$ROOT_DIR/tags/.svn

(I understand that more recent versions of Subversion have an option
to refrain from littering your working-directories with .svn/ folders,
having just one at the root level)

while git/mercurial would have

$ROOT_DIR/.git/
$ROOT_DIR/__init__.py
$ROOT_DIR/crm/...
$ROOT_DIR/settings.py
$ROOT_DIR/urls.py
$ROOT_DIR/wsgi.py

Though to be fair, Subversion's lets you do partial check-outs, so
you can check out $ROOT_DIR/trunk/ or $ROOT_DIR/branches/$BRANCH into
a single folder, even if the containing repository is arranged as
described above.

[Mike Dewhirst]

On 24/08/2016 10:19 AM, Rich Shepard wrote:

> On Wed, 24 Aug 2016, Mike Dewhirst wrote:
>
>> I use svn too. I hope git is a passing fad.
>

> Mike,
>
> Since Linus developed it for the kernel devs when BitKeeper became
> proprietary I very much doubt it's a passing fad. From all I've read,
> Git is
> great for large, multi-developer projects such as the kernel.

Yeah. It was a joke.

>
> I develop applications for my own use, but after I learn django with
> this
> current project there's another one where the professional software
> engineer
> paid to develop it walked away and so the project dropped. I'll
> resuscitate
> it when I get the current one going.

>
>> My entire project is in trunk and I always deploy to the staging
>> server directly from trunk
>>
>> I work on the project in the "mike" branch and that's what is used by
>> the dev server
>

> I've not used branches or tags before; everything's in trunk.

You need to make use of branches and tags. Makes life much easier.

Directory structure:
I have a directory tree rooted at ~/envs

My project's internal name is ssds. It is not a good idea to have
~/envs/ssds/ssds because there is also another ssds directory required
for settings. So I use my own convention to differentiate between
development areas in the tree like this:

Trunk
~/envs/ssdstrunk/ssds... for python 2 virtualenv trunk. This is
necessary because both servers run python 2 even though I write in
python3. All the unit tests must pass in python 2 in this dir. I never
adjust any code in this directory. In svn this is
https://svn.mydomain.com/repos/ssds/trunk/ssds and that contains
manage.py and all the app dirs.

Branch mike
~/envs/ssdsmike3/ssds... for python 3 virtualenv branch. This is the
mike branch. This is where I do most of my development and I do heaps of
commits all the time. In svn this is
https://svn.mydomain.com/repos/ssds/branches/mike and that contains
manage.py and all the app dirs.

branches/mike was originally branched from trunk to branches/mike. That
only happens once.

Branch mike_pdf
If I want to do something non-trivial that I eventually want to merge
back into mike I will branch from mike into say ../branches/mike_pdf (to
take a recent example). This just "copies" branches/mike to
branches/mike_pdf. Then I checkout that branch into a new dir called say
... ~/envs/ssdspdfmike/ssds and that checkout contains manage.py and all
the app dirs. I then do the pdf development in ~/envs/ssdspdfmike/ssds
committing changes as I go. Only when completely happy will I merge
those changes back into my normal dev work. I do that in
~/envs/ssdsmike3/ssds by doing a merge from branches/mike_pdf. I can
then delete the ~/envs/ssdspdfmike/ssds directory if I choose because it
is unlikely I'll use it again and it only clutters the place up. If
there is another non-trivial bit of work I'll create another branch and
a directory within which to work.

In the meantime, during the life of the branches/mike_pdf branch I could
keep developing in the mike branch provided it isn't going to clash with
mike_pdf. If I do that I will svn up in ~/envs/ssdspdfmike/ssds to fetch
any changes from mike into mike_pdf just to keep them more less in step
and minimising the deltas for when I eventually want to incorporate the
changes. I would still be running the test suite.

Branch mike
Ok so I have merged all ~/envs/ssdspdfmike/ssds changes into
~/envs/ssdsmike3/ssds and I'm now ready to deploy to staging.

Step 1 is to cd into ~/envs/ssdstrunk/ssds and merge from
~/envs/ssdsmike3/ssds (branches/mike)

Step 2 is to run all the unit tests (always making fixes in
~/envs/ssdsmike3/ssds by first reverting the trunk merge then re-merge
branches/mike with trunk)

Step 3 is to commit the merged changes to trunk (in ~/envs/ssdstrunk/ssds)

Step 4 is to deploy to staging. That is a totally separate topic but it
needs to be an export or checkout from
https://svn.mydomain.com/repos/ssds/trunk/ssds into the web root
directory where manage.py and all the app dirs belong.

Trunk
The concept (which I adopted) is that trunk contains the "current"
version. It is not guaranteed to be perfect but certainly all the unit
tests are passing. Might be more accurate to call it the current release
candidate. My project has a version number which I bump from time to
time based on my own notion of how things are going. I have included
that version number in my code so it is visible when using the software.

At some point, after deploying to staging I will say it is good enough
for production. At that point in ~/envs/ssdstrunk/ssds (trunk) I create
a svn tag from trunk and call it the version number. In my case for
example, https://svn.mydomain.com/repos/ssds/tags/0.5.2 where the
contents of ../ssds/tags/0.5.2 is (at that moment) exactly the same as
in ../ssds/trunk

Step 5 is to deploy to production which will be an export or checkout
from https://svn.mydomain.com/repos/ssds/tags/0.5.2

The golden rule is to never do any development in trunk or in any tags.
All dev has to happen in branches.

In my case I occasionally have other devs contributing. In that case, I
create a new branch for each dev. It can be a branch of /branches/mike
or a branch of trunk depending on where we want their changes to be merged.

There are other branching strategies but the above suits the way I work.

Hope that doesn't confuse too much.

Cheers

Mike

>
>> My svn server is online so other devs can have their own branches.
>

> Mine's strictly local.

>
>> I have the mike branch in a couple of virtualenv directories (for
>> pythons
>> 2 and 3) and trunk lives in its own directory with py2.7 because both
>> servers run 2.7 (which has to stop before I go mad - gotta get to 3.x
>> exclusively).
>

> While all my prior work was in python2 I'm developing the current
> one (and
> all future ones) with python3.
>
> I'm still trying to grok how my project should be laid out on disk,
> particularly with regard to svn (which I'll continue to use since it's
> more
> familiar than learning git).
>
> If I can explain to you what I'm doing will you show me how it
> should all
> be laid out as a directory tree? While I think I understand the
> differences
> between the overall project, the subproject with the same name, and the
> apps, I don't understand whether all components of my application
> belong in
> a single app or in individual ones. I'll probably start over (saving some
> files that can be moved away and back in a new directory tree.
>
> Thanks,
>
> Rich
>
>