Hurray! Our project Zveriki got “The best online game” award at KRI-2009(analogue of GDC in Russia) 
The game is still in active development and we provided demo access only to the press and members of the jury. Earlier we hoped the game would be launched in November 2008, however the World Crisis changed our plans quite a bit and now we are aiming at the mid of summer 2009.
I wonder if there are any “best git-svn practices”? Particularly for the following scenario:
1) There is a common svn repository
2) There are several developers who track/sync this common svn repo with their own local git repos using git-svn bridge(via git svn rebase/dcommit)
3) From time to time these developers using git need to share their changes without affecting the svn repository. For this purpose they setup a shared git repo and exchange their work using pull/push commands
4) It turns out these developers may face conflict problems due to usage of “git svn rebase” for syncing with the main svn repo. This happens because rebase operation rewrites history of the local git branch and it becomes impossible to push into the shared git repo and pulling from it often leads to conflicts.
Anybody having the same problem?
Update: Here is what official git-svn man page says about this problem:
For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git-svn users clone, fetch and dcommit directly from the SVN server, and avoid all git-clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git-format-patch and git-am, or just ‘dcommit’ing to the SVN repository.
Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you’ve made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.
Looks like my whole svn workflow should be revised 
Update: All my problems were resolved by migrating the whole repository to Mercurial Why Mercurial? That’s simple - it has almost all git features plus very smooth Windows support which is very important for many members of my team.
What I’ve been really missing in vim is a general mechanism of applying any arbitrary processing to the results of :vim[grep] command. What I usually did was to record a macro and apply it manually(using :cp) to every entry in a quickfix window - believe me, that’s very boring. Big thanks goes to Ben Schmidt who showed me a couple of vim script commands(in the official vim mailing list) which make it possible to automate this dull process. Here they are(put them into your ~/.vimrc):
:com! -nargs=1 Qfdo try | sil cfirst |
\ while 1 | exec <q-args> | sil cn | endwhile |
\ catch /^Vim\%((\a\+)\)\=:E\%(553\|42\):/ |
\ endtry
:com! -nargs=1 Qfdofile try | sil cfirst |
\ while 1 | exec <q-args> | sil cnf | endwhile |
\ catch /^Vim\%((\a\+)\)\=:E\%(553\|42\):/ |
\ endtry
It’s dead simple to use them. For example, you have a macro @q which makes some changes in a single line and you want to apply it to every line found by :vim command. Here’s a possible sequence of vim commands:
#search for foo string in all .cpp sources recursively
:vim /foo/ **/*.cpp
#apply q macro to all found lines
:Qfdo normal @q
Qfdofile command is a bit different to Qfdo - it applies your command not every line but to every file found by :vim search.
As you may have noticed I haven’t been around for quite some time and here is the reason for that - I have been totally occupied with my company’s new project zveriki.com, an online multiplayer browser game simulating pets life. The project is not yet complete, the release is scheduled for November 2008, still you can view some demo videos and screenshots.
Sergey Yudin(syfisher) did really great job by making {{macro}} template engine examples available on-line.
If you are wondering who in the world in his sane mind might need yet another PHP templating engine, well…I blogged about {{macro}} some time ago where, I hope, I presented some unique arguments in its favour. Here’s the quote from that post which, probably, most nicely and concisely describes the main idea behind {{macro}}:
To be short, the main idea behind {{macro}} is to use C/C++ alike(but way more sophisticated) macro tags to simplify usage of raw PHP in templates.
Ok, going back to the subject of this post, the mentioned page has runnable examples for mostly all core {{macro}} tags. You can browse the template rendering result page, template sources and PHP code which actually works behind the scene.
You can also download the source code of these examples from projects page(where, by the way, you can find some other real life Limb3 usage samples).
We are going to update examples on the regular basis presenting other interesting {{macro}} usage patterns in the future, so, if you are interested, stay tuned.
Update: Sergey also made a “Generated PHP code” link for each example, so it’s possible to view what PHP code is generated for each case. Cool stuff 
Actually Limb3 2007.4 was released on the 31st of the December 2007 but we(here in Russia) have 10 days of official holidays and I simply was too lazy to blog anything during those crazy days of champagne-with-vodka-fest-and-early-morning-hangovers
If you are wondering what Limb3 actually is and why world needs another PHP…er…framework(btw I hate this word too!), here’s a brief introduction. Limb3 is just a bunch of relatively independent packages, it is not a monolithic framework. Some packages are pretty unique(e.g {{macro}}) while others were inspired by cool stuff available for other than PHP platforms(e.g. active_record inspired by Rails’ ActiveRecord). And no, Limb3 was never intended to be “the one and the only one true PHP framework”. I personally believe in well thought code re-usability, thus the end application may contain bits of ezComponents, ZendFramework, PEAR, Limb3 and name-your-favorite-PHP-libraries-here.
Anyway, it’s better late than never, so here’s the list of the most notable changes made during past 6 months:
* ACTIVE_RECORD package: better invalid fields handling using
exceptions, support for different names of the primary key added
* CORE package: cruft cleanup, refactoring and misc. code
optimizations
* CACHE package: cleanup and better implementation, added
initial APC and Memcached support
* DATETIME package: major refactoring, renaming lmbDate into
lmbDateTime, etc
* {{macro}} alternative to WACT templating engine added with almost
all WACT alike functionality(and even more!)
* IMAGEKIT package: complete redesign using filters and fluent interfaces
* TESTS_RUNNER package: test groups and methods filters, better
coverage support
* JS package: upgraded jQuery to 1.2.1
* MAIL package: upgraded phpmailer to 1.73
* WEB_APP package: major cleanup, removed all commands and obsolete
controllers
* VIEW package: support for view selection based on template extension
added(currently MACRO and WACT)
* TREE package: ArrayAccess and ArrayIterator interfaces compatibility fixes
* FS package: more generic file system iterators added
Please note, this is rather a general changelog above, see the specific package changelog for more details.
The bundled release of all packages is available in the SourceForge downloads section of Limb3-2007.4
An experienced PHP developer might be wondering why posting this topic in a blog if PHP already has universal and almost transparent tools for this job, specifically serialize and unserialize built-in functions.
The key statement here is “almost transparent” which means you have to include all class definitions before invoking unserialize or use some __autoload schema. Otherwise you are going to face the dreaded “The script tried to execute a method or access a property of an incomplete object” fatal error.
The whole problem is due to the fact a serialized object has no idea about its class definition except the class name(the reason behind that is absolutely valid).
Working with windows shares in Linux is kinda painful, especially if you are a console geek and don’t like all that magic Gnome and KDE network applets do for you during connection to some smb server(what even worse these connections are only “visible” in GUI not in console).
I just needed something as low-level as possible and at the same time simple and convenient. Using smbmount with friends(smbumount, smbclient) is a possible way to go but I’m too lazy to type it each time and remember all its options
After some googling around it turned out that autofs could be the right tool. I only had to configure it properly… It took several hours of heavy googling, reading scarce blog posts, hacking with autofs and tearing lots of my hear before I finally got more or less acceptable solution for this problem.
Here are my Russian “AOP in PHP” slides from secon conference which took place on the 13th of the November 2007 in Penza, Russia.
Go grab it if you are interested in Aspect Oriented Programming in PHP or simply want to practice your Russian
Setting up Chiara_PEAR_Server with Crtx front end is a little bit confusing(even if you follow the official guide) but at least it happens just once
Another important matter is maintaining your lovely PEAR channel up-to-date which, of course, assumes nice and easy way of uploading new packages. Actually Crtx’s web interface provides such a way and it works just fine for a couple of packages but if you have more than a dozen of them uploading new packages quickly becomes a boring process(e.g. we have 20+ packages at Limb3 PEAR channel)
That’s why I hacked up a script which automates this process quite a bit