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.mo...@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@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > -- With best regards, Sergey I. Sharybin _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers