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

[Campbell Barton]

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
>



-- 
- Campbell