Re: Starting new project -- version 1.10

[Michal Petrucha]

On Mon, Aug 22, 2016 at 07:48:44AM -0700, Rich Shepard wrote:
>   One clarification on projects vs applications will help my learning.
> Rather than using the same name for both (based on prior advice), the
> project name is clientmanagment and that directory contains
>   clientmanagement/  crm/  manage.py*
> 
>   The clientmanagement/ subdirectory contains
>   __init__.py   __pycache__/  settings.pyc  wsgi.py
>   __init__.pyc  settings.py   urls.py
> 
> and I wonder why the project-related files in this subdirectory are not
> under the parent project directory. In other words, why is there a project
> subdirectory under the project directory?

This is mostly an issue with how we name things. You have a project,
which is a CRM application. That's the entire thing, which consists of
a bunch of different Python packages. So, each of the subdirectories
in the top-level “clientmanagement” directory is one Python package.
For better or for worse, Python packages containing Django models,
views, URL patterns, and whatnot, are referred to as “Django apps”.

So you have a project named “clientmanagement”, which contains two
Python packages (in other words Django apps), called “crm”, and
“clientmanagement”.

Usually, it's a good practice to split your project into smaller
self-contained packages. Those all live together inside the project
directory, and each of them can have its own URL patterns, models,
views, static files, templates, and pretty much anything else. They
can even depend on each other, although it's often a good idea to keep
the coupling between as low as possible.

Finally, you need one Python package that serves as the “app” that
glues all the other packages together. This is the package (or app)
that contains the settings module, the root URL configuration, the
WSGI entry point, and often also static files, templates, views and
other stuff that only make sense in the context of the project itself,
and cannot reasonably be spun out into a separate package (that would
be things like the base template, or sometimes the landing page view).
This is what you referred to as the “project-under-the-project”.

The reason why this is inside a separate subdirectory is that you want
Python to be able to import it. In theory, you could just put
everything one level higher (and, in fact, that used to be the default
layout created by startproject until a few years ago), but it's
troublesome in practice, because with such layout, all of those files
end up in the global Python import namespace, which can easily lead to
conflicts.

As a final note, if your entire project is really small, and only does
one single thing, it's not entirely unreasonable to use a single
Python package (Django app) for everything – if there are no more than
a couple-three models in the entire project, and just a handful of
views and forms, I just stuff everything into the single package
created by startproject.

I hope this explanation makes sense, and feel free to ask if there's
anything unclear.

Cheers,

Michal

-- 
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+unsubscr...@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/20160823121159.GO27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Starting new project -- version 1.10

[Carsten Fuchs]

Am 23.08.2016 um 14:11 schrieb Michal Petrucha:

Finally, you need one Python package that serves as the “app” that
glues all the other packages together. This is the package (or app)
that contains the settings module, the root URL configuration, the
WSGI entry point, and often also static files, templates, views and
other stuff that only make sense in the context of the project itself,
and cannot reasonably be spun out into a separate package (that would
be things like the base template, or sometimes the landing page view).
This is what you referred to as the “project-under-the-project”.

The reason why this is inside a separate subdirectory is that you want
Python to be able to import it.


I cannot remember where is was stated, but iirc another reason for the 
“project-under-the-project” subdirectory was that it is considered not as app, 
but rather as “site”.


That is, if you deployed the same project in a different context (with different 
configuration), you would have another such “site” directory, e.g. 
clientmanagement/clientmanagement-internal/ or 
clientmanagement/test-other-webserver/ etc.


Best regards,
Carsten

--
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+unsubscr...@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/be36f2a7-8f38-9c5d-3a90-b836aead863b%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Curl PUT Request With JWT Authorization Header

[Peter Boyles]

 

I am still getting a hang of using curl for testing API request from the 
terminal. I have a particular issue with formatting because the API request 
I am attempting requires a JWT Token to be passed with every call. The 
request I am attempting to pass is PUT request and my question is where to 
place the header for the JWT token authorization. I have tried the 
following format and I get a error Could not resolve host: —H curl: (6) 
Could not resolve host: Authorization:


curl -X PUT -H "Authorization: JWT " -d "field=value" 
"https://url/update_record//"
 

Any ideas?

-- 
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+unsubscr...@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/676040dc-a7fc-4ca8-96ce-8fd09559ab87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URLconf problem: why I'm geting 404 error when I should'nt?

[Lao Zzi]

read the django tutorial first. There is good django tutorial on the official site and also there is "django girls" tutorial on the internet. Both of them is good. Django doesn't see your urlconf. See at error, django find only ^admin/ regex. Your regex is not finded, so you have to edit you urls.py file. There is so mess inside it. Write it like this:urls.py filefrom django.conf.urls import url, includefrom django.contrib import adminfrom . import viewsurlpatterns=[    url('r^admin/', admin.site.urls),    url('r^hello/', views.hello),] The dot sign '.' means the current directory. You are importing views.py file from current directory, and then call hello view from it, like this views.hello.I think, it's also possible to write "from .views import hello", and use this view just by name 'hello', without writing "view." before it, but I don't this way, because using views.hello is more logical and clear.20.08.2016, 17:36, "Anahita Hedayati-Fard" : Hello I'm a beginner in Django. I'm trying to write my first URlconf but it doesn't work and it shows me 404 error just like this: And this my code on urls.py: And this is my code on views.py : And I ran the python manage.py runserve too. What is the problem here? *Sorry for my English. -- 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+unsubscr...@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/967673b8-07f4-416e-ad61-ad489c9826d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.



-- 
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+unsubscr...@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/340541471880459%40web13o.yandex.ru.
For more options, visit https://groups.google.com/d/optout.

Re: Starting new project -- version 1.10

[Rich Shepard]

On Tue, 23 Aug 2016, Carsten Fuchs wrote:

I cannot remember where is was stated, but iirc another reason for the 
“project-under-the-project” subdirectory was that it is considered not as 
app, but rather as “site”.


Carsten,

  Thanks for the clarification. That helps.

Rich

Re: Starting new project -- version 1.10

[Rich Shepard]

On Tue, 23 Aug 2016, Michal Petrucha wrote:


This is mostly an issue with how we name things. You have a project, which
is a CRM application. That's the entire thing, which consists of a bunch
of different Python packages. So, each of the subdirectories in the
top-level “clientmanagement” directory is one Python package. For better
or for worse, Python packages containing Django models, views, URL
patterns, and whatnot, are referred to as “Django apps”.


Michal,

  Yesterday evening I started reading a book I bought several years ago
(when django was at version 1.5) for a project that got sidelined. With your
explanation and the book I'm starting to understand the django terminology
and project organization.


Usually, it's a good practice to split your project into smaller
self-contained packages. Those all live together inside the project
directory, and each of them can have its own URL patterns, models, views,
static files, templates, and pretty much anything else. They can even
depend on each other, although it's often a good idea to keep the coupling
between as low as possible.


  Let me test my understanding by explaining my crm project. Getting it
right from the beginning will help me a lot.

  First, this is a single-user project for my business; I'm not a
professional application developer but have built scientific and business
tools for my use for several decades. Since this, and the other django
application that has been put off for a while, are the only two that I plan
to develop I am not convinced that I need virtualenv and its wrapper. Each
will use python3 and I'll keep django upgraded to the latest version.

  Second, now that I better understand the project/app design and disk
layout I'll rename some directories so the distinctions are clearer. Which
leads to my question about apps in a project.

  Yesterday, in models.py, I set up the schema based on what I want. The crm
has several components: companies, contacts, activities, opportunities, etc.
Each of these is a single class within models.py. My question is whether
each should be a separate app since there will be methods for adding,
modifying, and deleting rows in the database tables as well as report
generation and views that incorporate data from multiple tables. If so, is
each named as a distinct python module and imported into the main models.py?

  Or, should they all remain in models.py with separate modules for adding,
editing, deleting, and reporting that are imported to models.py?

  My python2/wxPython applications have an organization that makes sense to
me and works. Since building a browser-based django application is a new
experience I want to learn how best to organize everything.

Thanks for the insights,

Rich

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

Re: Curl PUT Request With JWT Authorization Header

[Ricardo Daniel Quiroga]

I using Postman, is a plugin of chrome for test xhr petitions

2016-08-22 23:42 GMT-03:00 Peter Boyles :

> I am still getting a hang of using curl for testing API request from the
> terminal. I have a particular issue with formatting because the API request
> I am attempting requires a JWT Token to be passed with every call. The
> request I am attempting to pass is PUT request and my question is where to
> place the header for the JWT token authorization. I have tried the
> following format and I get a error Could not resolve host: —H curl: (6)
> Could not resolve host: Authorization:
>
>
> curl -X PUT -H "Authorization: JWT " -d "field=value" 
> "https://url/update_record//"
>
>
> Any ideas?
>
> --
> 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+unsubscr...@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/676040dc-a7fc-4ca8-96ce-8fd09559ab87%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Ricardo Daniel Quiroga

-- 
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+unsubscr...@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/CAO2-wHbxedWu%3DmzqPUhCvxo93-tr_fFP9aKk7Qov%2BzRtkzucQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[HELP] To make a basecamp like - project management site

[Ravi Sharma]

Hi all, 

I'm trying to make a basecamp(http://basecamphq.com/) like project 
management site, for the simple reason that I want to have one by 
myself and using it for a better project management in my company. 

Based on the comparison within different python web framework, I think 
django is the good choice. I'm thinking that is there any similar open 
source django project in the world? Or is there any web 2.0 like 
software development management which was build on django? I don't 
want to reinvent the wheel. 

I'd appreciate it if you would give me some suggestions about how to 
get started. 

Thank you, 

-- 
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+unsubscr...@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/d6b09569-efdc-45ec-9611-765878500060%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Postcode Search

['dtdave' via Django users]

I am looking to add the facility to "find my nearest" by postcode to my 
django app.

Does anyone have any recommendations for this facility?

Many thanks in advance.

-- 
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+unsubscr...@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/66586c55-0f98-4232-8b06-4bb1e0045b43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using version control with django

[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

On Tue, Aug 23, 2016, 21: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'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
>

-- 
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+unsubscr...@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/CACczBUJ3apCi5pgsm%3D768HA3dU0-%3DL%2B8Q16fgTaMjKXttRMuTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using version control with django

[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

> On Aug 23, 2016, at 5:22 PM, Gergely Polonkai  wrote:
> 
> 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
> 
> 
> On Tue, Aug 23, 2016, 21: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'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
> 
> -- 
> 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+unsubscr...@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/CACczBUJ3apCi5pgsm%3D768HA3dU0-%3DL%2B8Q16fgTaMjKXttRMuTg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@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/D5B83A74-F704-4722-A6E6-AACF7FE30D64%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using version control with django

[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

Re: Using version control with django

[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

Re: Using version control with django

[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


  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



--
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+unsubscr...@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/1370e23f-1ae6-973c-1fde-d84409f4b580%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Using version control with django

[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

Re: Using version control with django

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

-- 
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+unsubscr...@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/20160823193357.20d88554%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: Using version control with django

[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