Re: Using version control with django

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
>
>

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@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/6498966b-ee8e-0730-649a-82bae3e42091%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.