[Bf-committers] Let us switch to git, pretty please

[Sergey I. Sharybin]

  Hi, Campbell

I've been moving our work SVN repo to GIT at my previous job* and Nathan 
should have script which moves SVN repo into GIT repo with handling all 
branches and so. So i could make tests too.

But i'd prefer to compare speed GIT vs. Mercurial. I haven't used 
mercurial myself, but there's information that GIT is much faster. I 
want to confirm this :)

* It was script which reads every commit from SVN repo and makes the 
same commit in GIT repo -- this was made to avoid all that additional 
messages in commit logs created with git-svn..

Campbell Barton wrote:
> paroneayea and I discussed moving to GIT at length and he brought up
> some issues which we'd need to resolve.
>
> - binaries may need to be masked out of SVN history so the initial
> checkout of lib/ isn't huge, (paroneayea said its possible with
> filter-branch when making the switch but its not trivial).
> More general issue is how well it performs once we have 500mb+ of
> binary changes in GIT too.
>
> - bf-extensions would also need to be moved, expect its possible but
> another complication, how to merge and keep history for both - not
> sure on this one.
>
>
> Another thing thats been discussed is having an SVN hook in our
> existing repo which keeps a GIT repo in sync. Currently the available
> GIT repos have some lag from trunk, With git matching trunk it would
> help us evaluate GIT without having to switch completely (interested
> in Nathan's opinion on this), it comes up from time to time as
> something we should do.
>
>
> As for moving to GIT (or any DVCS) - It would be good if people
> interested in evaluating this could make a local copy of the entire
> SVN repo to speed up tests and work out the necessary steps to move to
> see if we can even do this.
> Id like to look into this myself (hassling Marco for an account on the
> new SVN server now :) ).
>
> On Fri, May 27, 2011 at 5:02 AM, Mathias Panzenböck
> <grosser.meister.morti at gmx.net>  wrote:
>> As long time bf-committers reader who has committed one or two tiny patches in the past I like to add:
>>
>> Pros for HG:
>> More intuitive to use, especially things like revert.
>> Nicely extensible using Python (e.g. generic keyring integration for repo passwords).
>> TortoiseHg>  TortoiseGit and cross platform (Qt based).
>>
>> Pros for GIT:
>> The SVN bridge seems to be much faster and transfers less data than HGs SVN bridge (last time I tried).
>> Some people like this staging thing much. Never used it.
>> It is said that a repo with many very different branches is smaller in GIT.
>> github/gitourios>  bitbucket (but bitbucket is ok)
>>
>> Many things are possible in both, but the defaults differ. E.g. in HG you have to enable several
>> extensions (that are included, just not enabled) to get things like paging+colors on the shell,
>> rebase, squash (which isn't called like that in HG, I think) etc. But then in HG there is a built in
>> webserver (`hg serve`) that supports pushes (if enabled)! It can also be hooked as CGI script with
>> about two lines of Python code. But currently HG only supports Python 2.x.
>>
>> (I somehow like HG better.)
>>
>>         -panzi
>>
>> On 05/27/2011 05:29 AM, Sergey I. Sharybin wrote:
>>>     Hi,
>>>
>>> I'm not sure switching the whole repo to git is a nice idea. Last time
>>> i've checked this it was very painful to work with libs/ repo cloned
>>> with git -- simple `git status` used to work ages. Maybe this is because
>>> of plenty of binary files, not sure. And size of that local cloned repo
>>> was also incredible big -- several gigabutes, iirc.
>>>
>>> Git for codebase works really nice when you've got plenty of branches --
>>> no pain with all this re-branching and so. Simple `git rebase` and here
>>> we go. There's also advantage for releases -- tagging happens much nicer
>>> with git.
>>>
>>> It'll be also more useful for pre-realse periods while codebase is
>>> frozen -- developers could still commit features to the development
>>> branch, but they wouldn't go to master.
>>>
>>> About clients i could say that git on linux works nice, msysgit works
>>> fine for windows. There's also TortoiseGIT. I haven't used it much, but
>>> it worked also nice. But i have to admit, that some firends of mine had
>>> some occasional troubles with it.
>>>
>>> P.S. as one more disadvantage, we'll be unable to have that r<number>    in
>>> splash screen. It could be short commit SHA, but not sure it'll be useful.
>>>
>>> Tom M wrote:
>>>> It was discussed a bit yesterday on irc as Jason was updating his
>>>> sculpt branch to head that it would haven been much less pain with GIT
>>>> potentially.
>>>>
>>>> Brecht and Ideasman and other core maintainers what are your views on
>>>> moving to git or mercury?
>>>>
>>>> Ultimately the decision will be up to Ton of course, but would be good
>>>> to get a straw poll on sentiment for it.
>>>>
>>>> LetterRip
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>


-- 
With best regards, Sergey I. Sharybin