The service service_name command command can be used to start, stop, or restart anything in your /etc/init.d directory. From the command line, use it like this:
$ sudo service apache2 start
$ sudo service apache2 stop
$ sudo service apache2 restart
I wish this was in huge type on the front page of the Bazaar web site because it is essential to understanding just what the heck is going on when you place you files under version control.
I’m going to use an example to explain this. These events are listed in the order that they usually occur, at least when I use Bazaar. If you want to understand this at all, you better read the Bazaar in five minutes tutorial first.
When I start a new project I usually create a folder named after my project, say ‘foo/’, and in folder ‘foo/’ I might put my first file I’ll be working on called, say, ‘bar.py’, and a file to hold some data called ‘data.py’. So as soon as I initialise Bazaar, ‘bar.py’ and ‘data.py’ will make up my working tree – the files I actually edit.
The next thing I do is initialise Bazaar by typing the command ‘bzr init’ in the terminal, which creates a hidden folder in the ‘foo/’ directory called ‘.bzr/’. This hidden folder and its contents is a branch – the state of a project including all its history.
A branch usually includes a working tree too, but it doesn’t have to. If you get a branch and it doesn’t have a working tree, you can run ‘bzr update’ to make one.
Among other things, ‘.bzr/’ contains a folder called ‘repository’. This, not surprisingly, is your repository – the place where all commited changes to your working tree are stored.
There isn’t much to a repository until you run ‘bzr add’, which adds all the files and folders in your project to the branch, and ‘bzr commit’ which records all the changes to your working tree in your repository.
Your repository works like a database. Each file you put under version control gets a unique identifier and each commit is numbered so you can go back to any revision and see what you did. A common thing to do if you have more than one person working on your project is to use the same repository for everyone. The command ‘bzr init-repo’ (as opposed to just plain old ‘bzr init’) creates a shared repository.
So I created a folder and put some files in it, then initialised Bazaar which made my project a branch. Then I ran ‘bzr add’ and ‘bzr commit’ to add the files in my working tree and revisions therein to my branch. Now suppose someone else wanted to add code to my project? That is where checkout comes in.
If the hobo living behind the Safeway wants a stand-alone version of my branch that he can stare at or create a competing project that has nothing to do with mine, he can run ‘bzr branch [BRANCH_LOCATION] [TO_LOCATION]‘. This will create a copy of my branch on his computer, but his commits will not effect my branch.
But if Sally Smartypants and I are friends and she wants to contribute to my project, she would run ‘bzr checkout [BRANCH_LOCATION] [TO_LOCATION]‘, which would create a copy of my branch on her computer just like the hobo, with the major difference that Sally and my branches share the same repository. So when Sally runs ‘bzr commit’, the changes that she made would be reflected in the branch I have. I won’t see them right away though. If I want Sally’s changes to show up in my working tree, I have to run ‘bzr update’ to sync my working tree with our shared repository.
But what if a storm hits and Sally’s Internet goes down? No prob, her commits will just go on her local repository (since she has a full branch that works all by itself) until she’s back online and runs ‘bzr merge’ to sync up her local repository with the main branch.
Hope that clears things up. I know I’ve learned a lot.
LastPass, my fave password manager, was doing funny things with WordPress, reposting and deleting my blog posts. Weird. Fixed now.
You were right Evan, I was lost but now I’m found:
http://ipython.scipy.org/moin/
HUGE improvement on the beautiful Python interpreter. Tab completion! Bash commands! Yes!
Microsoft has now made it impossible to test their stupid browsers with IE Application Compatibility VPC Images on anything but their crappy Virtual PC running on a Windows machine:
http://forums.virtualbox.org/viewtopic.php?f=2&t=21712
Ooooohhhh the hate. I hope Bill Gates gets the hugest hemroid in the world for this. I hope it explodes all over his wife’s face.
It keeps deleting posts. I’ll figure it out tomorrow.
>>> execfile('myscript.py') # Execute 'myscript.py'
This is comes in very handy when working in the Python interpreter:
>>> import os
>>> os.getcwd() # Returns the current working directory; usually the directory you were in when you started the interpreter
>>> os.chdir('/path/to/directory') # Change the current working directory to 'path/to/directory'. Also accepts bash commands like '..' and '/'
Sometimes I am forced to use windows, and for some reason (although I can’t blame anyone not giving a crap) there is no easy_install for Python 2.6 on Windows. So I followed these instructions from monkut on the Stack Overflow forum:
For installing setuptools for 2.6 download “ez_setup.py” from:
http://svn.python.org/projects/sandbox/branches/setuptools-0.6/#egg=setuptools-dev06
And run it [In the terminal, navigate to the folder where the ez_setup.py file downloaded to and type
python ez_setup.py]. setuptools should be installed. This will place easy_install in your python26/Scripts directory, make sure this is in your PATH, and then you should be able to use easy_install.
This worked great. In order to add python26/Scripts to your Windows path:
I find myself needing this all the time, especially when I’m doing a tutorial on something nerdy.
$ touch filename