Cleaning up VDrift source tree

[BiGBeN87]

Hello joevenzon,

first of all thank you for your elaborate reply. In fact I haven't considered locking and in fact it seems that git does not have any equivalent mechanism:

http://stackoverflow.com/questions/11944...rol-system

I agree that the distributed nature of Git puts an stronger emphasis on this problem, because people might not get notice of a lock, when they work offline. GitHub also adds to this, because it encourages spontaneous contributions more than the svn on sourceforge.

I have never used locking in subversion, myself. The comments on StackOverflow suggest that even though SVN has locking, one can run into the same problems as without it. Was it usual for VDrift to use subversions locking in the past? Were your experiences positive?

I am working on a project (8 developers) that till recently used a mailing list for locking and releasing an unmergeable database dump. That worked pretty well, we only had one situation where two persons made changes concurrently and one had to redo them on the dump of the other.

We did move away from this method because we did not want the overhead of checking/writing emails anymore. Instead we now export our changes in code and automate the import/export of them via scripts. The binary files of VDrift however are not substitutable with more atomic files, as far as I understand.

Therefore I think, handling them is only possible with proper communication and sticking to the necessary protocol of editing. I am in doubt, whether the locking in svn really helps avoiding conflicts better than having split the code into individual cars/tracks/etc on github. With more atomic code and easier and therefore more frequent commits the maximum possible damage could actually be lowered.

I would suggest having a lockfile in the root each repository, that needs to be touched before and after working on the data repositories. An obligatory guide on how to fork, lock, edit, commit and release could be given in each repo's readme, too.

Other stuff specific to git: I had heard that a git repository size grows much faster with binary file changes than an SVN repository. I had also heard that the way git works on a blob level (versioning the content of files, not the file itself) makes it really slow at scanning for updated files (since it needs to hash everything to determine if it changed) while subversion can cheat by looking at file properties. This info may be out of date. If you set up a test git data repo we can do some experiments.

I would be happy to help testing this. I will deploy something later today or tomorrow.