include "../_i/1.h"; ?>
http://www.flickr.com/photos/mccord/23367874/
Don't hg add
something unless you know what it is and
you know why it needs to be in your repo. Emacs backup~ files and
#autosave# files don't belong in your repo. Python .pyc files don't
belong in your repo.
Neither does your SQLite database file: because it's a binary file
and will change frequently (every time you test your site), it will
cause conflicts every time you try to merge changes. Regenerating it
on a new clone of your repo is as simple as python manage.py
syncdb
. If you want to distribute some test data with your
repo, you do that by dumping the data into fixtures
using python manage.py dumpdata
, which we'll probably
talk about later; or you can ask me or look it up in the docs.
And your virtualenv definitely doesn't belong in your repo. Not only is it huge (it includes all of Django, some 75MB), it also doesn't even work anywhere except where it was first created, so there's really no point in putting it in your repo. Virtualenvs are disposable, you just recreate one whenever you need one.
Most of you are using directory structures where your virtualenv is
outside your repo directory anyway, but a few of you have it inside
your repo dir, in which case it needs to be
in .hgignore
What to do if your repo has a bunch of junk in it that shouldn't be
there? Use hg rm filename
to remove the files you don't
want, then commit. You can do things like hg rm *~
or hg rm *.pyc
to remove a number of offending files at
once.
If you remove a file using the regular rm
command
instead of hg rm
, hg status
will show it
with a ! next to it, meaning "help, this has disappeared and I don't
know why!". Just run hg addremove
to tell it "any missing
files are missing because I intentionally removed them". Be careful if
there are any ? files around, though; hg addremove
will
also hg add
all those, which may not be what you
want. Update your .hgignore
first to ignore any you don't
want added.
If you added your virtualenv to your repo (or some other big huge file or directory), the above cleaning won't get rid of the massive version history you now have to carry around everywhere. Because hg lets you go back in time, even removing files from the repo doesn't remove them from the version history. In this case unfortunately the only solution is to create a new repo, copy in the stuff that you want there, commit it, and ditch the old repo.
Early on I showed you a .hgignore
file with the first
line syntax: glob
. This line lets you use Unix
shell-style "globs": *.pyc, *~, etc. Alternatively, you can just use
the default .hgignore syntax, which gives you the full power
of regular expressions. You've already seen those
briefly in your tutorial URLconf, and we'll cover them in more detail
in a week or two. In the meantime, here's a
sample .hgignore
file you may want to use for your
project repos:
\.pyc$ ~$ \#$ db.sqlite$
That last line will vary depending on your DATABASE_NAME
setting. Here's that very same .hgignore file using syntax:
glob
- use whatever makes more sense to you:
syntax: glob *.pyc *~ *\# db.sqliteinclude "../_i/3.h" ?>