Overwriting folders with git - django

I'm learning how to use django on a EC2 server, but i am editing the code on my local computer. When i run things like :
python manage.py startapp polls
It creates a folder with various files inside. Instead of individually adding the files to git, which leaves the possibility of me forgetting to add every newly created file, is it good practice just to:
git add (the root django project directory)
everytime django creates new files?
If this isn't good practice, what methods do you guys use to ensure that all files get added to git everytime new files are created?

I think you're over-thinking this. Ignore files you think you should (like *.pyc). Add all the files or do them individually, whichever you prefer. If you accidentally added one you shouldn't have, do a checkout of that file so that you don't add it. If you already committed with a file, git delete the file and commit.

You use git status, it will give you the list of all the files it's currently not tracking, so you can use that as a reference if you're afraid you'll forget something.
Additionally, I would say that you don't want to forget to properly setup your .gitignore, and then you can instruct git to add everything, otherwise, like Mark suggested, you would potentially be adding **.pyc* files, which you don't want to do.

Related

What do these lein folders do?

In my project directory, there are two folders named as follows:
./.repl-1.7.170
./.cljs_node_repl
I believe these folders are automatically generated. What are they for? Is it OK to delete them periodically when cleaning up?
I think these are both working directories used by the REPL when compiling REPL-related code.
In either case, why do you need to delete them?
The only consideration around this I can think of is wanting to make sure they don't somehow get committed to source code control. For that you can just use ignores or excludes if for example, you are using git.

Migration to SVN, confused about deleting old files

I have a StarTeam repo that I'm trying to migrate to SVN. Unfortunately the repo is HUGE, so I can't use any of the polarion scripts, etc. I'm resorting to checking out snapshots of each release in StarTeam and then manually adding/committing them to SVN.
However, I'm confused about what to do for old files. In StarTeam, we had to move deleted files to an "obsolete" folder since the purge command removed all copies of the file. I know that I don't need to do that in SVN, but how does SVN deal with files which have been deleted/are missing?
Say I have three files in the following structure:
trunk/
Src/
A.cpp
B.cpp
C.cpp
If from one release to another I deleted "C.cpp", do I just need to commit all of src for the deletion to be reflected in the SVN repo?
Likewise, if I deleteed "C.cpp" but added "D.cpp", I would need to call add on all of "src/" before committing. Would that cause any problems with detecting and deleting the missing files? There are too many of them to go through manually and delete every one individually.
As a separate question, is there a reason why it takes tortoiseSVN almost 3 hours to detect which files are changed before I can add/commit? All I see is the "Please wait..." message in the dialog box, and it takes FOREVER.
Thanks!
Any change you make to the repo needs a commit, so yes after doing svn delete you need to svn commit. Similarly when you add files, that's a change that needs to be committed. In both cases it's possible to undo the add and delete without commiting.
In terms of adding and removing files in one transaction, again that "just works", you'd effectively issue:
svn delete C.cpp
svn add D.cpp
svn commit
If you want to recover a deleted file, then you can just recover the file from an earlier revision of the svn repo, then recommit (see also What is the correct way to restore a deleted file from SVN?).
The main thing you must remember though when deleting files: you must delete it using subversion tools (i.e. from the command line as svn delete or using Delete within TortoiseSVN. Just deleting it using del, rm, or a file manager like windows explorer will have SVN see the file as "missing" and not "deleted", and a commit of the repo will not commit the delete; thus the next time you update your working copy, the missing files will be restored. Thus you use subversion to delete the file so subversion knows that you do actually want it deleted.
For your last question -- what version of SVN and how big is the repo (in terms of file-count). Essentially T-SVN has to walk the tree and check each file against the repo-version to see it it's changed. As of SVN 1.7, the working copy format changed with a lot of metadata being held in the database, and improvements to the storage of pristine copies (i.e., what the file looked like when it came out of svn) means that it's faster than it was. If you aren't using 1.7, then it's worth checking out. Also, if you have a large repo but only work in a small part of it then consider using sparse checkouts to reduce the size of your local working copy. See this answer to Checkout one file from Subversion for a brief overview or sparse checkouts.

Mercurial ignore the ".idea" folder form PyCharm?

I am developing a Django app and it's my first time with Mercurial(using bitbucket).
I have done some commits without adding ".idea" folder from PyCharm to hgignore. Now I have added it to hgignore and want to remove .idea from the central repository but obviously do not want to delete the actual folder locally.
What's the proper way to handle this? I know this is a common thing, but I'm in the learning stage.
Thanks for the help in advance.
What it sounds like you want is for Mercurial to stop tracking everything under .idea. This should work (command issued in the repository root):
hg forget .idea\*
Use hg forget .idea. It's like hg remove, only it doesn't delete the file from your working directory.
hg forget .idea\* should be your solution!
you could read up more on forget / remove here
http://www.selenic.com/mercurial/hg.1.html
just for reference you can delete the .idea folder. pycharm will generate it the next time you open up your project files using it.

Mercurial ignore part of a directory

Been fighting with Mercurial's .hgignore for a while under Windows.
I have a folder named Upload which is currently empty. I do want it tracked so I added a .empty file in it which work fine. I want this so that new developers doing an hg clone get the Upload document required for the application.
Thing is I never want the folder to be populated with anything on the source control itself (test uploads from a development machine).
Example:
If I add Public/image.jpg it wouldn't be tracked.
Additionally I would like it for sub directory to be tracked. So if developer adds
Upload/users/.empty I would like this to be tracked.
Is this possible with regex voodoo?
In mercurial (and unlike in svn and cvs) adding a file overrides the .hgignore file, so you can put this in your .hgignore:
^Uploads/.*
and your Upload/.empty that you added will still be created on update and thus they'll get the directory.
Getting it to ignore files in upload but not not ignore files in subdirectories in Upload could be done with:
^Uploads/[^/]*$
which says: ignore anything that Starts with Uploads and has no further slashes in it.
Really though, you should be creating Uploads with your build/install/configure script when possible, not with the clone/update.
Try putting
Uploads/(?!.empty)
in .hgignore in the root of the repository
Try
^Uploads\b.*/(?!\.empty)[^/]+$
This should match any path starting with Uploads where the text after the last slash (=filename) is anything but .empty.

Excluding a single project file from an SVN repository

I have a django project that I have been working on as a solo developer, and have been using TortoiseSVN to keep the code managed in a repository on a work server. I work on this on a local installation of django etc.
There is now a second person who will be working on this project, and the possibility of working on some other PCs.
Now, there should, for the time being, only be one development version (branch?) of this project, but the configuration file (settings.py) will need to be different on each computer that is being used. I want to create one local version of this file on each PC which should not need to be changed again.
How can I set the repository (preferably within TortoiseSVN) to exclude this one file? E.g. the repository should not include settings.py. When a checkout occurs, it should update all files in the local folder but not change/remove the local copy of settings.py. When a commit occurs, settings.py should be ignored and not uploaded.
At the moment settings.py is overwritten/updated as per any other file in the project folder/repository.
Any nudges in the right direction would be useful - I'm new to SVN generally and would like to know if this is something that's going to need detailed understanding of branching or if there is a simpler way.
Thanks
In TortoiseSVN, when you try to commit your files, in the file list dialog, right click the file and look for the Ignore option. You can ignore by complete filename or extension.
If the file is already in the repository, and you want to remove it from there and ignore it, you can simply right-click the file and in the TortoiseSVN menu look for the 'Delete and add to ignore list' option.
You'll be looking for the svn:ignore property, which tells subversion to not version files matching a pattern or patterns you specify.
There's some guidance on using it with TortoiseSVN at:
http://arcware.net/tortoisesvn-global-ignore-pattern-vs-svn-ignore/
These should help:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
Excluding Items from the Commit List
The typical solution is to do what bgever said and ignore the settings file itself, and then commit a file with example values, something like settings.py.example. That file should only be updated when you add or remove settings. When deploying, you'd copy that to settings.py and edit the values.