Well, this quick blog post is a sort of a quick rant.
That’s the second time I see someone trying to use GIT for binary files synchronization. That’s true, it’s quite easy to create a local GIT repository, then adding a remote is a piece of cake and “TADA” local commits could be pushed to the remote than from there cloned / pulled into another machine. But! Because there’s a really big “BUT”!
Remember for what GIT was designed. That’s right, source file handling, with history and merging. What are source files? They are text files, yes. That’s not binary. GIT can actually compare successive version and only handle diffs (patches). Have you tried using the patch tool with binary files? That makes you laugh, isn’t it! So why using GIT for file sync won’t you also make you laugh? Should I continue now? 😉 Well, I should continue, because GIT also has history. So you’ll force it to store every binary version you ever had, into it’s little .git directory. Is that what you really want?
If file synchronization is needed, then consider rsync, unison or equivalent tools, pretty please.
Well, SVN is not yet dead. Enterprise world still uses it, or at least it’s still used at my workplace 🙂
When it comes to merging, one has the choice of TortoiseSVN or svnmerge from Orcaware. Each of these has their drawbacks. For example, TortoiseSVN is very mouse-intensive, so it’s click-error prone (yes, yes). The script from Orcaware is somewhat strict, and it even requires one to use it from the very beginning of the project. But what if you didn’t use it at that time? So, how to get a small improvement to this situation? Enter svnmerge2.py. I put the sources on, well, GitHub! 😉
There are instructions in both French and English. However, the script only shows French strings. I plan to add English translation later, when I’ll have some spare time. Meanwhile, if you need it, feel free to translate it and add a pull request on GitHub. I’d be glad to integrate it.
Le nouveau système de gestion des versions créé par Linus n’a plus besoin d’être présenté. Il est très pratique et cela se voit dans sa vitesse d’adoption. Mais la petite commande “cherry-pick” me fait réagir. C’est trop pratique ! Elle permet de reporter un jeu de modifications d’une branche vers une autre sans passer par la case “checkout de la branche cible + fusion”. Cette commande est tellement puissante qu’il est plus long de la décrire que de la mettre à l’oeuvre. Voir l’article (en anglais) que j’ai écrit sur la techbase KDE.