On 5/5/2014 04:27, Adrien Nader wrote:
> tl:dr; agreed
>
> Also, something not mentioned elsewhere and which I didn't know where to
> put: a large appeal of git in mingw-w64 is coherency with other source
> repositories. One less tool to master.
>
> On Sun, May 04, 2014, NightStrike wrote:
>> Responding to both of you inline... sort it out :P
>>>> any developer with write access can
>>>> simply push their changes since, by definition they do actually have
>>>> write access, although sending for review highly recommended. Git does
>>>> open an avenue to "pull" style reviews, so even the authors without
>>>> write access have the chance to publicly host their code (eg github)
>>>> before it is pulled into mingw-w64. The vista headers was more of a
>>>> miscommunication, I really thought you gave the green light to commit.
>>
>>> It is also possible to have users changes on a branch on the SF
>>> repository and have someone merge them in the master branch.
>>> For instance at work we have branches named
>>> "users/${user}/${branch_name}", i.e. users/adrien/break-everything.
>>> It was possible to finetune the rights to such branches and to the
>>> master branch independently. While this was enforced by the software,
>>> I'm confident it could also be a process enforced through the ancestral
>>> method of hitting with a baseball bat people who do things wrong (in the
>>> event SF does not allow restriction through software).
>>>
>>> I'm happy with restricting the rights to the main branch because there
>>> is a strong guarantee the commits have been reviewed.
>>
>> This idea of Adrien's is a good one. It is common in many projects,
>> and usually works well. However, am I understanding it correctly this
>> workflow?
>>
>> A) Alice has a change, works in a branch, finishes.
>> B) Alice posts the change for reviewing somehow (patch to ML, link to
>> git repo, etc)
>> C) Someone with expertise approves
>> D1) Someone with super rights does a git pull into master
>> D2) Alice does a git push into master
>>
>> D1 or D2?
>>Why does it matter who pushes? This is the same under SVN, if Alice has write access, she commits/pushes, if not, someone else does. Under git, the commit log/user ID isn't affected by whichever route you take. I do prefer Adrien's pull method though. > > This is a simple change in vim's configuration file (in the case SF > doesn't changing that in some Web UI). I don't think I can check on > jon_y's repo (seems I don't have the rights to access it through ssh). > Right now, I made it readonly except to administrators, I'll try to allow you access to it. >>>>> 6) Is there any way to do a partial checkout with git? Right now, >>>>> someone can check out just a small piece of the whole repo, whatever >>>>> is interesting. How do you do that in git? I have only ever been >>>>> able to figure out how to do the whole thing. On one project that I'm >>>>> on, the svn repo is a few terabytes. That's a blocker for that >>>>> project switching to git -- it doesn't scale well at all. If you know >>>>> how to deal with that, I'd be interested. The only answer we've ever >>>>> found was "split it into many repos", which obviously isn't a viable >>>>> solution or we would have done it already. >>>>> >>>> >>>> Actually, git cloning the entire repo turns out to be faster than SVN >>>> doing partial checkouts, I don't see this as much of a hurdle. >> >> I wasn't asking about mingw-w64. I was asking in general. For >> instance, cloning binutils takes FOREVER. > Have you compared it to CVS checkout? It too took forever. > I had witnessed the slowness before so I did a clone on two machines. > Below are the results (for curiosity). > One is residential DSL, the other is 100Mbps in a datacenter. > 210MB to download, bandwidth of the DSL was maxed (was at most 600KB/s), > bandwidth of the DC'ed machine wasn't maxed either but was around 5MB/s. > > This is heavily influenced by internet connectivity. I guess > sourceware's connection isn't incredible and my paths to it weren't > great either. > > Binutils is a large repositoy. There are many large files for the > testsuites. History in git goes back to 1988. Probably the other reasons > it is such a big download. > > And as said earlier this is not avoidable with git and shallow clones > don't save that much space either. This is unfortunate and I'm not aware > of work on that aspect (not sure it's possible to improve). > It isn't so bad if you realize you clone only once, you can use local references if you want to speed up related git repos. >>> More precisely, git is fast to clone by batching files: it packs them >>> and transfers the packs. When I tried JonY's read-only git repo, I ended >>> up cloning at 2MB/s (max of the line) and was done in 10 seconds. >>> The download was a bit more than 20MB. I had previously mentionned 67MB >>> or so but that was a "git-svn" clone which most often produces bigger >>> files than a regular git repository. So 20MB or so and 10 seconds it is >>> for me. >> >> The mingw-w64 repo is tiny. I've worked with terabyte repos. with a T. > > I know Microsoft has a lot of dead bodies hidden but I doubt there's > _that_ _much_. :P > > More seriously, I don't think git scales to huge repositories, at least > yet. It scales well to lots of contributors however. Mingw-w64's > codebase and history would have to grow a hundred times for git's memory > requirements to start being an issue for machines which are already > considered as fairly old today. I think we're safe on this aspect. > Right, we're a long way to get to even reach the Linux kernel's complexity. Even then, git still works.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
