Responding to both of you inline... sort it out :P
On Sun, May 4, 2014 at 10:24 AM, Adrien Nader <adr...@notk.org> wrote:
> 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.
Just to be clear here, I was pointing out the open issue, not
volunteering to do it. I don't have a clue how to make git do that.
>> > 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,
Yes, I explicitly pointed that out :) The difference is in the likelihood.
>> 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?
If it's D1, you get the security, but that's going to get old real
fast for the few people allowed to do a pull. D2 opens the door for
irrevocably butchering the whole repo (As I said, I've done this --
it's not hard.) It also means that everyone is going to be merging
and resolving conflicts differently, based on their own style. This
is probably the worse of two evils.
If you look at Linux, it uses D1. There are people who pull changes
into modules, and Linus pulls changes from them into the Real Deal.
This is very different than working in svn, where after a green light
on the ML, Alice would just "svn ci".
Actually, there are parallels to svn. In svn, Alice should do:
svn copy ^/trunk ^/branches/Alice // Create branch
...work in branch...
svn merge ^trunk // Keep branch up to date
svn co ^trunk // Checkout trunk to merge back
svn merge ^/branches/Alice --reintegrate (or not reintegrate for cherry picking)
svn ci
Instead, what usually happens is:
svn co ^/trunk
svn ci
The nature of my August 2011 email was basically this -- we currently
as a project do not branch and merge correctly, or often at all. Svn
has superb branch/merge capabilities, but they just aren't used. Now,
what that means is that if you change the VCS to git, you have to
REALLY spell out how to change that workflow, or else you'll be stuck
in an even worse spot. That means writing down in the wiki a set of
procedures that all developers have to follow:
0) This list is just off the top of my head, surely not exhaustive
1) how you expect changes to propagate
2) who is in charge of what branch
3) how and when is the right time to rebaseline
4) how to keep a branch commit history clean
5) how to branch << This is a big one. I'm not talking about the
syntax of the command.. I'm talking about what things to consider when
making a new branch. Just grabbing HEAD is a **baaaaaaaaad** idea.
This is a somewhat decent reference that you should understand:
http://www.kdgregory.com/index.php?page=scm.git Specifically the
sections "Master is for Integration, not Development", and "Have an
Integration Czar".
That last one is paramount. What I see currently happening is the following:
A) Jon gets a spur of the moment idea to change everything to git
B) Everyone goes gaga because git's cool
C) Now we're in git, and everyone knows how to use it..... differently
D) 3 weeks later, the repo is a mess, and you've lost any gain you
might've had (try doing git-bisect now)
You've done the technical work -- put up test repos, asked people to
try them, raved about the speed. But I've not seen any administrative
work that documents the mingw-w64 way of doing git business. That's
not something you're going to throw together in ten minutes using a
script. You really need to think about the implications of the
workflow that's right for THIS project.
This is an issue that you *NEED* to work out before you make this
thing live, as doing this wrong in git is a LOT harder to clean up
than doing it wrong in svn. >>> If you don't understand how
important this is, then you are not qualified to be doing this
conversion. <<<
>> > 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.
My experience differs. I've corrupted master history before by trying
to clean up my branch.
> 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).
You need to expand on this, and not talk in the theoretical. How do
you set that up? What are the implications of doing so? What does SF
support?
>> > 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.
> 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.
>> > 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 :)
>
> =)
Thanks :)
------------------------------------------------------------------------------
"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
