The smalles instance of a DigitalOcean droplet only provides 512GB of RAM. Do not forget that this rather low in comparison with other Web servers. If you do not check your configuration files for Apache and MySQL and leave them at defaults, you can easily run out of memory, because DO droplets come without swap by default. In the case of MySQL, your will be confronted with this error message:
InnoDB: Fatal error: cannot allocate memory for the buffer pool
The solution is rather simple, as provided by a comment in the support forum. Just follow this guide in order to enable some swap space. As the system is completely on a SSD, you should not have a huge performance impact.
There are many settings where you still require Microoft Windows and for those purposes, where I can’t use Linux directly I run a VirtualBox instance of Windows 7. The Windows 7 guest shares my subversion repository with my Mint 15 host system via shared folders and this works surprisingly well. Nevertheless it happend that I deleted a file on the host and tried to check it in on the guest. This corrupted the subversion database and I was unable to perform any operations (update, commit, cleanup) in the repository of the guest anymore. The 1.7 version of subversion comes with a small sqllite database for the management of the repository. You simply have to delete the node from this database directly to get a working copy back. With the following steps, you do not have to delete the working copy and check it out again, which can save you a lot of time with large repositories.
1) Download sqllite and open the database of your local working copy.
2) Find the root of all evil (provide the filename of the file that blocks your subversion repository). I here added a wildcard % so that we can ommit the full path. Only do that if you know that there is only one file with this name.
sqlite> SELECT checksum FROM NODES WHERE local_relpath LIKE "%filename";
The system returns a checksum like this:
This is the checksum of the file that causes the trouble. The checksum ensures that you delete the correct node, because it is unique for every file, in contrast to filenames for example.
3) Dry run (does not change the database)
The following SELECT statement returns the data from the specific file for a last check.
SELECT * FROM NODES WHERE checksum = "$sha1$36fed30ab5ed74a1234569729b9dd1bb54ab5634";
4) Delete the Node with the given checksum
Warning, there is no undo possible!
DELETE FROM NODES WHERE checksum = "$sha1$36fed30ab5ed74ab110f69729b9dd1bb54ab5634";
This node is now deleted.
Leave the database management system and proceed with your work. Now you should be able to update the repository again.