asiby wrote:
I was already reading it. I have also notice the a simple "emerge git" will install it on gentoo
You expected otherwise?
I don't know how this thread has escaped my attention for so long. How are you getting on with git? I must admit due to having a very usable private subversion+trac repository (almost as easy to install on Gentoo as git) I've not spent as much time looking at git as I should have.
I appreciate you prefer git, xrg. From a technical standpoint, so do I. Verily! It's a far superior solution in every possible way. For the moment, however, I shall continue to use my SVN repo, and the 'svn merge' command to easily apply changesets/patches to the various branches within it.
The Svn book's section about 'vendor branches' describes what you need to in order to be able to easily merge changesets to Areski's repo into your own private repo. Doing the opposite is even easier.
By means of demonstration I should point out that I have xrg's git repo as a vendor branch in my own svn repo so I'm now enjoying easily extractable history of commits there too. There are only four drawbacks compared to using git directly that I'm aware of:
1) for history earlier than when I initially imported your vendor branch I have to resort to using gitk/gitview.
2) i have to update my vendor branch once for each revision up to the most recent commit, unless I'm happy with collapsing your history a bit.
3) the speed: with a system with little free RAM and/or slow storage performing the svn vendor branch dance is at least 2-3 orders of magnitude slower than git's blink-and-you'll-miss-it responses. Honestly. Even on the initial clone (over a network) git was finished so quickly I thought it must have failed!
4) repo size. in six months mirroring Areski's repo's history closely, and making 500 revisions myself my repo has grown from ~150MB to ~300MB. Almost all of this is due to the vendor branch method being very wasteful of space.
3 & 4 combine to encourag merging trees less frequently to minimise repo disk space bloat, not A Good Thing.
I have an idea for a few lines of Bash to workaround 4) completely, and greatly speed up 3), yet still keep the door open for easy merging and maintain complete history.. I'm surprised the SVN devs didn't implement it, as it seems fairly obvious and I can't see how it could fail. I can't find any record of them having discussed it. I'm hoping it will be lightweight enough to consider running a svn vendor branch merge triggered by an RSS feed of new commits to areski's tree.
Another factor in my desire to stick with svn for my personal usage for a little while yet is the installer. Some of you may have seen the A2B installer script I have been honing over the past weeks. For those that haven't, it supports near seamless upgrades of A2B, even on live systems (I do it regularly). I'm just adding support for updating (and creating) the SQL schema automatically. That will work for upgrades from release tarballs, but if you install from a svn working copy it has extra functionality to automatically update the minor SQL schema changes that can happen from revision to revision. In short to upgrade you should only have to type 'svn up && addons/install' and then ensure you merge changes to the configuration file, if instructed.