On Sun, May 04, 2014, JonY wrote:
> On 5/4/2014 12:17, NightStrike wrote:
> >
> > Now... that said, there's a few things that I didn't see addressed
> > anywhere in this thread.
> >
> > 1) Jon, you had asked me to setup a mailing list for svn commits. I
> > did so. Then SF added their own thing that just sends the commit
> > message without the patch in the body. So now we have both. What is
> > your plan with doing that for git? Are you going to still email
> > messages to a list? Are you going to do it per commit, or per merge?
> > Binutils recently tackled this same question, and they settled on 1
> > email per commit. Also, would you only want emails on a certain
> > branch?
> >
>
> Per commit please, all branches.
>
> > 2) Seeing as how it just came up on the mingw list, how does
> > authenticity verification of changes happen when someone wants to
> > merge in a big change? On said list, people made the claim that this
> > project doesn't check that commits are legally safe. Under svn, every
> > change gets checked by someone before it is committed. What will be
> > the new procedure, if a person has a giant blob to merge in?
> > Admittedly, the problem is still there in svn (like that time you
> > merged in the vista headers... lol :) but it's more common under git,
> > I think. Consider putting some thought into how you will accept large
> > changes from a "was this copied from proprietary sources?" standpoint.
> >
>
> It is the same situation under SVN, 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.
> > 3) svn history is impossible to change. git history is purposely
> > malleable, usually so that a user can merge a clean branch without all
> > the false starts that come from development. How will you stop users
> > from (possibly inadvertently) changing the history of whatever "trunk"
> > becomes in an undesirable way? Maybe it's a non-issue? I don't
> > expect malice, but I could easily see a user accidentally doing that.
> > I've done it myself, actually, on two occasions, the first of which
> > required a restore-from-backup (oops..).
> >
>
> git would reject the push if the commit checksum before it did not
> match. As with SVN, it will block if your changes if it is not based on
> the latest revision.
Moreover, git has the ability to allow forcing such operations and to
deny forcing them. The master branch should never allow them and the
rage from users who have to endure such changes is most often enough to
deter anyone from doing so anyway (and I'm ready to send a snail-mail
handwritten letter to anyone doing so).
> > 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.
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.
> > Anyway, those are my questions. Obviously I'm just an outsider at
> > this point, so feel free to ignore the whole email if you want. I
> > mainly felt compelled to read the thread because completely
> > coincidentally, another project I'm on is switching from a very old
> > system to git, and doing it very poorly. Then, of course, after
> > reading, I saw that the primary reason has to do with a concern I
> > raised 3 years ago...... But anyway, take it all for what it's worth
> > -- just another email in the inbox. Have fun, happy hacking.
>
> Please come back, we miss you :)
=)
--
Adrien Nader
------------------------------------------------------------------------------
"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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
