I ran across a peculiarity with google mail’s spam checking today. I’m running a bay area firewood delivery site for a buddy of mine, and it has, among other awesome features, an order form containing a few ‘phone’ strings. When the order form is submitted, an email is sent out to a private email list which is ran using google site’s email app.
I made a few changes to the email script, tested them in the dev environment, pushed the changes to production, then made one final test in the production environment… and holy snikes it doesn’t work! I don’t get an email at my google email list when I submit the order form. What?? It just worked 10 seconds ago on my dev site!
- Revert the production code.
- Recreate problem in my dev environment.
- Track down source of problem.
Long story short, it turns out if I send an email to an email list handled by the google sites email app, and if it contains the string ‘555 555 5555′ then it doesn’t go through. Or at least it gets delayed by 1 hour+. I haven’t seen any of them yet.
Change that ‘555 555 5555′ ever so slightly – say to ‘555 555 5554′ and it goes through in seconds. Who would a thunk it.
I guess spam often has ‘555 555 5555′ in it? Moral of the story is a) to not get that phone number and b) don’t use common strings like that in your testing. (firstname.lastname@example.org?) It can introduce unexpected variables.
Let’s say you wanted to transfer a complete copy of an existing SVN repository, all history included, from a googlecode.com project to a subdirectory in another preexisting repository. This takes a few steps since us mere mortal non-googlers (and former googlers) don’t get direct command line access to the googlecode.com servers.
- Make a local copy of the full googlecode.com repository.
svnadmin create local_repos
echo -e "#\041/bin/sh" > local_repos/hooks/pre-revprop-change
echo "exit 0" >> local_repos/hooks/pre-revprop-change
chmod 755 local_repos/hooks/pre-revprop-change
svnsync init file://`pwd`/local_repos https://urproject.googlecode.com/svn
svnsync sync file://`pwd`/local_repos
- Now, you can make a dump of that local repository.
svnadmin dump ./local_repos > thedump
- Copy that dumpfile over to wherever your preexisting destination repository is located. -C is for gzip compression during transfer, and is helpful if you have a big repository full of text.
scp -C ./thedump yourhost.com:~/
- Now, we load that dumpfile.
svn mkdir file://path/to/your/repos/dir_for_googlecode_copy
svnadmin load /path/to/your/repos --parent-dir dir_for_googlecode_copy < thedump
Revision number will be incremented correctly (ending at the sum of the two previous repositories), all the commit logs and such are transfered intact, including the authors (even if they’re not users on the new system). Pretty smooth.