Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.05.2014 20:06, LRN wrote: On 04.05.2014 19:50, Dongsheng Song wrote: On Sun, May 4, 2014 at 10:09 PM, 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. Due to git merge, the commit maybe out of order, could you consider 1 email per push? Do rebase-with-history instead \o/ Just tested git-imerge rebase --goal=rebase-with-history on a simple situation: Feature-branch split off master at a forkpoint, advanced by 2 commits (commit1 and commit2) past the forkpoint; master branch advanced by 1 commit (master1) past the forkpoint: 00c812f - master1 \ commit1 - commit2 the result is: $ git log --graph --oneline --all * 1c1b38e imerge 'feature-branch': automatic merge 1-2 |\ | * 8feb020 commit2 * | af7c2da imerge 'feature-branch': automatic merge 1-1 |\ \ | |/ | * acad1b5 commit1 * | 442456a master1 |/ * 00c812f _chgsignl: Add ARM implementation Normal git log is: $ git log -6 --format=fuller commit 1c1b38e51c5acb5478733bcf55f61e327a594994 Merge: af7c2da 8feb020 Author: LRN AuthorDate: Mon May 12 00:00:24 2014 +0400 Commit: LRN CommitDate: Mon May 12 00:00:24 2014 +0400 imerge 'feature-branch': automatic merge 1-2 commit af7c2da4c1e0d8101b44ffd9827b7cdf7a3c3b5f Merge: 442456a acad1b5 Author: LRN AuthorDate: Mon May 12 00:00:24 2014 +0400 Commit: LRN CommitDate: Mon May 12 00:00:24 2014 +0400 imerge 'feature-branch': automatic merge 1-1 commit 442456ae2db4a507360b09ef16881ff8300e9c3a Author: LRN AuthorDate: Sun May 11 18:19:21 2014 + Commit: LRN CommitDate: Sun May 11 18:19:21 2014 + master1 commit 8feb0205b8a6b0500d52f86e2661bcfde2f575ed Author: LRN AuthorDate: Sun May 11 18:01:43 2014 + Commit: LRN CommitDate: Sun May 11 18:01:43 2014 + commit2 commit acad1b5a387c795f60908734b95b7c45dff83caa Author: LRN AuthorDate: Sun May 11 18:01:31 2014 + Commit: LRN CommitDate: Sun May 11 18:01:31 2014 + commit1 commit 00c812f1a1422e89791932d6c814acbe51c31226 Author: André Hentschel AuthorDate: Fri May 9 21:58:25 2014 + Commit: André Hentschel CommitDate: Fri May 9 21:58:25 2014 + _chgsignl: Add ARM implementation git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@6620 4407c894-4637-0410-b4f5-ada5f102cad1 - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTb9vYAAoJEOs4Jb6SI2CwGRgH/jxSzEdnJtE5pcTUaAkcMMCk kerglo7iKkIT2KtEV5+HXALxGTWvJwoLwnMJFw69RTLiP5BN+7OystMVPcAU2IFW n4b9yDoaGVGeXOSI0nznFTEktSOad0r1vBfRr5RQe11O+0r0Gbl9m+xtc1O73/ab REZbQUMbk8AkLPsnB9LU5Ja2YEQYKVmFeXI8EBcjcPGgxjNVepK3IjDfN5NQRw3h APc4Yu2Fb/C+x+j1BIow0615wyaKwMKNvgOYjhs0abDfbroKvDiONxtb6NDjIrtE sHgtxfLw5p67ROBIci0Ts2HXAjqcRjjnF+7CQxrOWhtIxO1oo5+r7lK5WALA3ps= =kAst -END PGP SIGNATURE- -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, May 05, 2014, JonY wrote: 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. Thanks, works. From /home/git/p/mingw-w64/mingw-w64.git/config: [receive] denyNonFastforwards = true I don't know if you're the one who put it there or if it's by default but in any case, this is what forbids rewriting history. -- Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
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. 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. 4) How does the release process change as documented here: http://sourceforge.net/apps/trac/mingw-w64/wiki/VersionSpec It's still the same, we branch on major versions and tag for every release. 5) This is kind of a pie-in-the-sky thing, but is it at all possible to keep an svn mirror of the git repo, so that all those many links out there in the wild still work? Might be nice, probably not possible. Oh well. It is possible to keep it in sync, the major hurdle is that git doesn't handle SVN metadata, understandably. I opt to keep it read-only and locked. 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. 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 :) 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 Mingw-w64-public@lists.sourceforge.net
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Sun, May 4, 2014 at 10:09 PM, JonY jo...@users.sourceforge.net 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. Due to git merge, the commit maybe out of order, could you consider 1 email per push? -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
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?
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 **bad** 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Wow, I really have been away for a long time. I found this thread while cleaning things out now that my 578493578943 projects at work are finally finishing. Also, I'm trying to see if we can incorporate winpthreads in one project :) I have to say, this is kind of sad, mostly because of 1) misinformation and 2) negative treatment toward a user with a different opinion. I'll address a little of (1) down below. For (2)... Jon, why so angry? If you have good technical reasons for proposing a switch to git, you should be able to present them cogently, ideally from the standpoint of We need to solve problem X; here's my solution., and they should easily stand on their own merit. Users are allowed to be dicks.. they're users. Be nice in return. Kai taught me that a long time ago. Some German idiom about not plucking chickens before they hatch or something I dunno. On Wed, Apr 30, 2014 at 2:05 PM, JonY jo...@users.sourceforge.net wrote: On 4/30/2014 21:34, Rodny Spillig wrote: Because it was a pain to track down patches applied to other branches and reapply it again and again, cherry-pick is god sent. Not to mention merging is quick and simple. It is also far far easier to do a long term private branch in git than in SVN, not to mention, multi-part commit patches are nice. SVN does all of that easily. Are you sure you aren't just using it wrong? The notion that it does not branch and merge is very outdated. There is even a whole section in the manual called Cherry Picking. Does SVN allow you to manage a local-only branch that allow merging from multiple remotes? As far as long term branches, how is svn merge ^/trunk any different than git pull ? Will SVN allow change tracking of said branch if it is never committed to the server? The big problem here that git might actually fix is that nobody ever used svn correctly, despite my requests. I posted a very long email to the developer list back in 2011 that basically said don't manually patch files, use svn merge before making edits. Search the list for subject Proper merging of patches, 8/7/11. I was aggressively shot down by both Ozkan and Kai, who vehemently defended the notion that we should never use the merge capabilities of the version control software. That's the primary reason why patches between branches are impossible to tie together. Fixing this would be great. If switching to git makes people finally keep accurate merge metadata, then that is a pretty good thing. But to be clear, the current difficulty in tracking down patches and applying them elsewhere is a facet of how we chose to misuse svn, not the tool itself. We use svn where I work, and we branch and merge all day long. It's wonderfully easy to do. It does require a net connection, but for our purposes, that's fine. Besides, I'd rather push my work to a server, given how many laptops I broke this past year :) How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Already mentioned in the original email. Not really. The entire workflow changes drastically, and you've not indicated at all how users should deal with that. I have already mentioned branches and tags are migrated, they're all there. If you haven't already noticed, git-svn migration preserves history fine. Experimentals are outdated and unused and has not seen any changes for a long time, and unlikely to see any significant changes soon. I was about to change a few things in experimental, actually, because I got a nagging email that buildbot can't handle the binutils switch from git to cvs. Although I question whether anyone actually needs buildbot anymore. This change will equally break buildbot, so I may just shut it down. I don't really maintain it, haven't seen Mook log in in a while, and I'm not really part of this project anymore (or haven't been in a long time, and probably haven't been missed). Other than that, the buildroot makefile is in there, which though being out of date is still referenced in a lot of places. And it's used by buildbot. It should likewise be updated or removed, pending what happens to buildbot. I'll send a separate email for that. We chose git because it is far more familiar to the bulk of our contributors, namely the ReactOS and Wine developers. Some contributors are already using their own git band-aid over SVN. None of our developers have even mentioned Mercurial over the years. Bazaar is out of the question because SF doesn't have that option. ReactOS uses SVN, not git. They even have svn posting to their IRC, like we used to have with CIA. Maybe they use both? This page says svn, tho: http://www.reactos.org/development/source-control I looked back through a month or so of IRC
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, I have enabled read-only access to the git repos for testing purposes, the experimental directory is mostly outdated and can be left in SVN. Do try out the repos (git clone URL): mingw-w64 proper - git://git.code.sf.net/p/mingw-w64/git webpage - git://git.code.sf.net/p/mingw-w64/git-web ironcrate - git://git.code.sf.net/p/mingw-w64/code-ironcrate The repos should be accessible over http too. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
2014-04-30 12:45 GMT+02:00 JonY jo...@users.sourceforge.net: Hi, I have enabled read-only access to the git repos for testing purposes, the experimental directory is mostly outdated and can be left in SVN. Do try out the repos (git clone URL): mingw-w64 proper - git://git.code.sf.net/p/mingw-w64/git webpage - git://git.code.sf.net/p/mingw-w64/git-web ironcrate - git://git.code.sf.net/p/mingw-w64/code-ironcrate Just a small nit: I would name the repo mingw-w64 so that git clone URL clones into mingw-w64 instead of the current git. Another small nit: the branches still have tags, (v1.0 and v2.0), maybe get rid of these for confusion's sake. Cheers, Ruben The repos should be accessible over http too. -- 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 -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/30/2014 19:18, Ruben Van Boxem wrote: 2014-04-30 12:45 GMT+02:00 JonY jo...@users.sourceforge.net: Hi, I have enabled read-only access to the git repos for testing purposes, the experimental directory is mostly outdated and can be left in SVN. Do try out the repos (git clone URL): mingw-w64 proper - git://git.code.sf.net/p/mingw-w64/git webpage - git://git.code.sf.net/p/mingw-w64/git-web ironcrate - git://git.code.sf.net/p/mingw-w64/code-ironcrate Just a small nit: I would name the repo mingw-w64 so that git clone URL clones into mingw-w64 instead of the current git. Sf doesn't allow repo renaming, but sure, I can move it the hard way :) Another small nit: the branches still have tags, (v1.0 and v2.0), maybe get rid of these for confusion's sake. Thanks for spotting them, I thought I removed them. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/30/2014 19:52, JonY wrote: On 4/30/2014 19:18, Ruben Van Boxem wrote: 2014-04-30 12:45 GMT+02:00 JonY jo...@users.sourceforge.net: Hi, I have enabled read-only access to the git repos for testing purposes, the experimental directory is mostly outdated and can be left in SVN. Do try out the repos (git clone URL): mingw-w64 proper - git://git.code.sf.net/p/mingw-w64/git webpage - git://git.code.sf.net/p/mingw-w64/git-web ironcrate - git://git.code.sf.net/p/mingw-w64/code-ironcrate Just a small nit: I would name the repo mingw-w64 so that git clone URL clones into mingw-w64 instead of the current git. Sf doesn't allow repo renaming, but sure, I can move it the hard way :) Done: git://git.code.sf.net/p/mingw-w64/mingw-w64 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Tue, Apr 29, 2014 at 6:00 AM, JonY jon_y@... wrote: On 4/29/2014 14:49, Rodny wrote: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. There seems to be no possibility of discussion, only talks of acceptance. A pity. If you do not intend to ever accept an option other than the one you propose, then do not ask for discussion. It just adds insult to injury. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Because it was a pain to track down patches applied to other branches and reapply it again and again, cherry-pick is god sent. Not to mention merging is quick and simple. It is also far far easier to do a long term private branch in git than in SVN, not to mention, multi-part commit patches are nice. SVN does all of that easily. Are you sure you aren't just using it wrong? The notion that it does not branch and merge is very outdated. There is even a whole section in the manual called Cherry Picking. As far as long term branches, how is svn merge ^/trunk any different than git pull ? How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Already mentioned in the original email. Not really. The entire workflow changes drastically, and you've not indicated at all how users should deal with that. Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. What does Linus have to do with the decision? If anything, I'll use it because Linus recommends it. You ignored the question, which implies the answer is no. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? Because git commits cannot easily push back to SVN, and great, you have all the power of git and the inconvenience of SVN. SVN seems to be an inconvenience to you because you aren't using it correctly. That's not a deficiency in the tool. And as pointed out, many projects successfully use a git mirror, including GCC itself. Your original message said that the project may switch to git. I now understand that this was not true. It should have said that the project will switch, and you are entertaining zero other options. Why even bother asking your community? Why not just tell instead of ask? Your responses reek of Keith Marshall. This is the kind of thing that drove us away from mingw.org in the first place. This is not what we have come to expect over the years. -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/30/2014 21:34, Rodny Spillig wrote: Because it was a pain to track down patches applied to other branches and reapply it again and again, cherry-pick is god sent. Not to mention merging is quick and simple. It is also far far easier to do a long term private branch in git than in SVN, not to mention, multi-part commit patches are nice. SVN does all of that easily. Are you sure you aren't just using it wrong? The notion that it does not branch and merge is very outdated. There is even a whole section in the manual called Cherry Picking. Does SVN allow you to manage a local-only branch that allow merging from multiple remotes? As far as long term branches, how is svn merge ^/trunk any different than git pull ? Will SVN allow change tracking of said branch if it is never committed to the server? How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Already mentioned in the original email. Not really. The entire workflow changes drastically, and you've not indicated at all how users should deal with that. I have already mentioned branches and tags are migrated, they're all there. If you haven't already noticed, git-svn migration preserves history fine. Experimentals are outdated and unused and has not seen any changes for a long time, and unlikely to see any significant changes soon. The only gem left in experimental is ironcrate, which is still far from complete, I doubt there are actually active ironcrate users. Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. What does Linus have to do with the decision? If anything, I'll use it because Linus recommends it. You ignored the question, which implies the answer is no. I can reply with the same rhetoric, why choose Mercurial or Bazaar over git when they have roughly the same functionality? Do you actually know any command-line phobic end users that want to download mingw-w64 and build gcc and binutils from source to benefit from the supposedly more user friendly GUI frontends others have? Does Linus using git somehow cause it to be a bad choice? We chose git because it is far more familiar to the bulk of our contributors, namely the ReactOS and Wine developers. Some contributors are already using their own git band-aid over SVN. None of our developers have even mentioned Mercurial over the years. Bazaar is out of the question because SF doesn't have that option. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? Because git commits cannot easily push back to SVN, and great, you have all the power of git and the inconvenience of SVN. SVN seems to be an inconvenience to you because you aren't using it correctly. That's not a deficiency in the tool. And as pointed out, many projects successfully use a git mirror, including GCC itself. If you're going to work on the existing SVN WC anyway, why setup an online git mirror in the first place? What is the benefit of setting up a read-only DVCS that can only pull from a single source? Your original message said that the project may switch to git. I now understand that this was not true. It should have said that the project will switch, and you are entertaining zero other options. Why even bother asking your community? Why not just tell instead of ask? Your responses reek of Keith Marshall. This is the kind of thing that drove us away from mingw.org in the first place. This is not what we have come to expect over the years. May here hinges on the amount of migration effort required, which was surprisingly light. So yes, it is now a definitive will. For the record, I have no idea what Keith did to you (what exactly did he do anyway?) to even bring him up in this conversation. Are you saying you moved just because some source code repo was shifted to another VCS you disagreed with? 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.
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
2014-04-30 20:05 GMT+02:00 JonY jo...@users.sourceforge.net: Experimentals are outdated and unused and has not seen any changes for a long time, and unlikely to see any significant changes soon. The only gem left in experimental is ironcrate, which is still far from complete, I doubt there are actually active ironcrate users. That isn't true. There are a lot of things of interest in experimental. To clear up with such rumors. Just that something changed for a while doesn't make it necessarily useless! Kai -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? And, this is just an observation from an admitted relic in this advanced age (been doing this for over 40 years, I'm at the end of my career now..) this looks like a spur of the moment idea that has inadequate planning and far reaching consequences. This is more like what a certain competitor of yours often does -- from the hip radical change for the sake of change with poor planning and no business case for it. That only works when running for president (ba dum!) I've seen this happen many times over the decades, and the story is always the same. I guess I'm just hopeful that people today would learn from the mistakes of those that came before them. Or maybe the net just has no place for an old engineer anymore. Obviously, like I said, this is a minority post. I realize that. And it will probably be met with very little that's positive. But at least understand that you have users here that aren't that vocal that would appreciate you not jumping on the latest bandwagon. -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
2014-04-29 8:49 GMT+02:00 Rodny spillig...@gmx.com: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? The better question you should ask yourself is: why is the open source world changing? I'm not going to sum up the pro's and cons, you can find them yourself. git is just a lot more flexible and robust. This does not make it any better than any other distributed VCS, it just makes it better (i.e. more flexible) than stuff like CVS/SVN/... Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) You are aware that a) TortoiseGit exists? Along with a bunch of other graphical clients b) Visual Studio 2013 has native git integration? I'd hardly say git doesn't work on Windows... Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? Google git for subversion users. There's a ton of migration help for you and everyone. There are no hard numbered revisions, instead, there's branches and tags and commit hashes, which offer the same flexibility. There are things like a shallow clone (see git clone --depth=N), which allows you to checkout the latest N commits. Note a git clone is often smaller than the equivalent svn checkout, because git compacts the commit history quite efficiently. See the previous mails about repo sizes. How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? And, this is just an observation from an admitted relic in this advanced age (been doing this for over 40 years, I'm at the end of my career now..) this looks like a spur of the moment idea that has inadequate planning and far reaching consequences. This is more like what a certain competitor of yours often does -- from the hip radical change for the sake of change with poor planning and no business case for it. That only works when running for president (ba dum!) I've seen this happen many times over the decades, and the story is always the same. I guess I'm just hopeful that people today would learn from the mistakes of those that came before them. Or maybe the net just has no place for an old engineer anymore. Obviously, like I said, this is a minority post. I realize that. And it will probably be met with very little that's positive. But at least understand that you have users here that aren't that vocal that would appreciate you not jumping on the latest bandwagon. I'm sorry to say this, but git (or any other distributed VCS) isn't just the latest bandwagon. There's a reason github is so popular. There's a reason more than half (watch me pull statistics out of nowhere) of major open source projects are
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, On Mon, Apr 28, 2014 at 11:49 PM, Rodny spillig...@gmx.com wrote: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? And, this is just an observation from an admitted relic in this advanced age (been doing this for over 40 years, I'm at the end of my career now..) this looks like a spur of the moment idea that has inadequate planning and far reaching consequences. This is more like what a certain competitor of yours often does -- from the hip radical change for the sake of change with poor planning and no business case for it. That only works when running for president (ba dum!) I've seen this happen many times over the decades, and the story is always the same. I guess I'm just hopeful that people today would learn from the mistakes of those that came before them. Or maybe the net just has no place for an old engineer anymore. Obviously, like I said, this is a minority post. I realize that. And it will probably be met with very little that's positive. But at least understand that you have users here that aren't that vocal that would appreciate you not jumping on the latest bandwagon. Sorry, I am replying only because you've written your email in a way you must have realized was near guaranteed to start a flame war, which is very unlikely to be useful. There was a time, maybe 5 years ago, when it was common to assert that git was a fad and subversion was fine, but you must have noticed that that conversation died off a long time ago. I assume that you haven't used git or mercurial on a project with many distributed developers. For some reason it is very difficult to explain in the abstract why DVCS is so much better in this situation than centralized one-commit systems like svn. It only becomes clear after using these systems for a while. In case it is helpful, there's a very good explanation by Joel Spolsky (for mercurial) here: http://hginit.com/00.html See also Distributed Version Control is here to stay, baby http://www.joelonsoftware.com/items/2010/03/17.html Best, Matthew -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Rodny writes: Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) Take git extensions for a spin: https://code.google.com/p/gitextensions/ -- Alberto -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29.04.2014 11:31, Ruben Van Boxem wrote: On 2014-04-29 8:49 GMT+02:00 Rodny: JonY writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? Google git for subversion users. There's a ton of migration help for you and everyone. There are no hard numbered revisions, instead, there's branches and tags and commit hashes, which offer the same flexibility. There are things like a shallow clone (see git clone --depth=N), which allows you to checkout the latest N commits. Note a git clone is often smaller than the equivalent svn checkout, because git compacts the commit history quite efficiently. See the previous mails about repo sizes. He's right on this one. Just yesterday i was frustrated when i couldn't download a *particular* revision of binutils to build. Shallow clones, as mentioned, give you HEAD or something near HEAD or a tagged commit. Usually i work around it by abusing the snapshot feature of a particular repo, but sourceware had that disabled. AND their snapshot tarballs on ftp are rolling (meaning i can't just download a particular snapshot that way either, they change over time). That said, this just breaks the use-case when you have to work with a particular revision of upstream for the first time. If you need a tag or the HEAD - it's fine, since shallow clones help. If you've done this before - also fine, since you have the repo clone, and just need to update and checkout to the commit you need. And since we're speaking of revisions, for the record, it should be possible to emulate incremental revision numbers in git, as long as master is kept linear. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTX2V5AAoJEOs4Jb6SI2CwMskIANtdlBEP1cTmVOL8lDzjJohx 3Mb2Ah+z2BSn2TTh96R/N2pag15uje6YmRkGJRRTUlv03jI4XTn50sj0AJyFNWko SskOxkBUbivKIP7k9qJFTAyvMpsf4n9hHAuE/PJ7QjBySBXwZsmxP7F8u7Tarh9E QqHcbrh4W+AFYQFNqRqQVHFyBg4zLPbPLIPOQZhiMp7qecSsPAOm2L5UG2AxPh+K /YlBadG1DsP0qaSCiiz9Fhg2ijvWMii0U2cehrG9dgUmzrGiCuQZNiw2NF34YPnm A7iJUPSKxsb6h23y0wATiK3p5X5R+yTwOE259oX2n81bnoQ0QUljr0VOX37iO+M= =JZOG -END PGP 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/29/2014 14:49, Rodny wrote: JonY jon_y@... writes: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Hello, world. First time poster, long time user. I know I'm in the minority, but I'd just like to say that I'm actually against this change. We use your products in house here almost constantly (Bob's your uncle for that!), and we really love how easy it is to use your code base. We always build our own toolchains, and we are setup to interface directly to you. Switching this up for no apparent reason throws a giant wrench into our operation. With our staffing, we will be fubar bundied for all you WW2 buffs out there. I noticed that everyone in this thread, including this original post, is coming from the standpoint of why not use git? while I'd like to ask you the question, Why are you changing? Because it was a pain to track down patches applied to other branches and reapply it again and again, cherry-pick is god sent. Not to mention merging is quick and simple. It is also far far easier to do a long term private branch in git than in SVN, not to mention, multi-part commit patches are nice. Ignoring the endless holy wars, some practical concerns that we have here are the dismal support on native windows for git. TortoiseSVN makes browsing your changes and picking the ones we want extremely easy in a graphical environment on the platform that you're built to provide compilers for. It just seems natural for a Windows Compiler Project to use tools that... you know... work on windows. (Yes, I know of msysgit. My statements stand.) TortoiseGit. And no, you are not expected to work using Windows tools just because it is for Windows. You'd be surprised to learn most of the changes are not done on Windows at all. Another practical concern -- do we now have to checkout your entire repository just to get one revision? git lets you get All or Head. What about the equivalent of 1234? Will you provide documentation for users like us to adapt to this new model? Or are we stuck? Just grab it once (or use a local cache) and then checkout the revision you want. How will you handle all the various things that you currently distribute? You have a lot of stuff in your repository, and it all works nicely because of how svn treats each directory as essentially a separate repo. What are you going to do about the branches, tags, and experimentals? Already mentioned in the original email. Have you even considered other distributed systems? Mercurial, Bazaar? Or is it git all the way just because it's git? Git is much more of a Do what Linus says project, than it is a tool that's solving a problem. What does Linus have to do with the decision? If anything, I'll use it because Linus recommends it. I'd actually like to see you move to a more recent version of svn that has a lot of new whiz-bang features that make it more desirable to stay with the status quo. Contrary to popular belief, git doesn't merge/branch any better than svn, unless you compare brand new git to svn v1.0. Finally... why not just set up a git mirror like so many other projects do? Because git commits cannot easily push back to SVN, and great, you have all the power of git and the inconvenience of SVN. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64 may move to git in the future
Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, as JonY said, do we think about switching to git. Of couse such a step might shows side-effects to our users. So we would like to get your opinion and thoughts for this step. As svn-repository works a bit different as git, we will need to restructure our branches, tags, trunk, and experimental. We need a plan how we might do transition here. Open questions from my POV are: - How do we maintain different branches? Well, this shouldn't be the big problem, just naming and how to handle them we should agree on. - Where stuff from experimental should do, which aren't fitting to a branch of master-repository. So how many separate repositories we might neeed? (ironcrate, tools, POSIX-emulation stuff like getrusage, etc) For sure there are other things too. Thanks for you thoughts, and opinion. Regards, Kai 2014-04-28 13:17 GMT+02:00 JonY jo...@users.sourceforge.net: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. -- 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 -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-Original Message- From: JonY [mailto:jo...@users.sourceforge.net] Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. +1 Just because I'm a daily git user, and I'm having a hard time doing anything beyond a mere check-out in svn. Again and again :) Just this morning I was searching for a semi-official github clone of Mingw-w64 ... It obviously depends from what you know, but git really has established itself as 'the' versioning system in the open source world by now. Regards Kai PS: Maybe interesting: Why the ICU project won't move from svn to git any time soon: http://sourceforge.net/p/icu/mailman/message/31814825/ . It comes down to references to svn revisions all over the place. -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
2014-04-28 13:30 GMT+02:00 Kai Tietz ktiet...@googlemail.com: Hi, as JonY said, do we think about switching to git. Of couse such a step might shows side-effects to our users. So we would like to get your opinion and thoughts for this step. As svn-repository works a bit different as git, we will need to restructure our branches, tags, trunk, and experimental. We need a plan how we might do transition here. Open questions from my POV are: - How do we maintain different branches? Well, this shouldn't be the big problem, just naming and how to handle them we should agree on. - Where stuff from experimental should do, which aren't fitting to a branch of master-repository. So how many separate repositories we might neeed? (ironcrate, tools, POSIX-emulation stuff like getrusage, etc) Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. The simplest setup would be to have these branches: - master |- 1.x |- 2.x |- 3.x |- experimental_feature_x |- experimental_feature_y ... And each release's git tag is in its release branch. Note a git tag is not a full copy of a branch as with SVN, but just a ref to a certain commit. One can easily and quickly diff branches and cherry-pick particular commits between them, which will allow for simple git-based backporting of changes as far as the different branches are similar) A new release branch is as easy as git branch --track 4.x origin/master Same for a new feature branch. This ensures changes in the master branch are automatically pulled in when you do a git pull. As a start for the conversion, check out this step-by-step plan: http://stackoverflow.com/a/11918337/256138 I haven't tested it myself, but this should provide the cleanest transition possible, removing unnecessary svn stuff and transforming that as much as possible into git structure. The good thing is you can try it locally without touching the original repo. I could give it a whirl myself and push to github so you can see what the result would be if you think this would be useful. Cheers, Ruben For sure there are other things too. Thanks for you thoughts, and opinion. Regards, Kai 2014-04-28 13:17 GMT+02:00 JonY jo...@users.sourceforge.net: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. -- 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 -- 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 -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/28/2014 19:53, Ruben Van Boxem wrote: Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can exclude files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). The simplest setup would be to have these branches: - master |- 1.x |- 2.x |- 3.x |- experimental_feature_x |- experimental_feature_y ... And each release's git tag is in its release branch. Note a git tag is not a full copy of a branch as with SVN, but just a ref to a certain commit. One can easily and quickly diff branches and cherry-pick particular commits between them, which will allow for simple git-based backporting of changes as far as the different branches are similar) A new release branch is as easy as git branch --track 4.x origin/master Right, this is given. Same for a new feature branch. This ensures changes in the master branch are automatically pulled in when you do a git pull. As a start for the conversion, check out this step-by-step plan: http://stackoverflow.com/a/11918337/256138 I have done a fairly large svn to git conversion recently, so I'm mostly familiar with the steps. I haven't tested it myself, but this should provide the cleanest transition possible, removing unnecessary svn stuff and transforming that as much as possible into git structure. The good thing is you can try it locally without touching the original repo. I could give it a whirl myself and push to github so you can see what the result would be if you think this would be useful. I want to avoid duplicate efforts, I have already started the git svn clone process. If it goes badly on my end, you can give it a go. I will push to an unofficial repo on SF for preview. Speaking of our current svn repo, it isn't usually busy, so the svn lock down will only be done once migration completes, users should be able to jump right over by then. Until it is done, the git repo will need to track svn manually. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 17:04, JonY wrote: On 4/28/2014 19:53, Ruben Van Boxem wrote: Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can exclude files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). My experience so far: 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt and winpthreads not together, but separately, at different points of time. To this end i'm svn-checkouting from a subdirectory to get only one of the three. I don't remember whether git has that ability; possibly not. If that is the case, these may need to go into separate repos (possibly submodules?). 2) The git branches are for branching out from the main development line (and merging back at some later point), not for completely separate stuff. If you keep completely different stuff in different branches, switching branches (which usually takes less than a second) will take a long time (depending on the size, up to 10 seconds or more). The svn branches are more like git repos - completely independent, they just live together :) - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTXl/DAAoJEOs4Jb6SI2Cw+LoH/jeC5Gu884aNkcEk1k19/q7+ kVmM8Sb0b2WW+v063xb7ZqcWxtQUf/egXaRUFQJTgYYsOKPF+5SeJWpxyuGpjsjN 2mLzo2LtygqaIl/XI+rtGO2LipJW3d7Uo1Puq1oWctcH3LG1QQJLvkOqQLJzwnpF M7niIwtspZpOtRHGPEQAespVpY3mH2hkvRd6tPAj51w1Ix/d4OwfAjsW80EGJIwC oT/qvM4gAADIGz11zmIzplGCOmOvsi8JENEgQB1szKQ2vih8bFwaOhM433a38zCZ ehx4JIasVL13TtJRliSSgEHCh6kKJGD+V6+nOyD5TNrCfL9NIRV7YWbyQu9sC78= =Qy6h -END PGP 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) -John E. / TDM -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 17:04, JonY wrote: On 4/28/2014 19:53, Ruben Van Boxem wrote: Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can exclude files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). My experience so far: 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt and winpthreads not together, but separately, at different points of time. To this end i'm svn-checkouting from a subdirectory to get only one of the three. I don't remember whether git has that ability; possibly not. If that is the case, these may need to go into separate repos (possibly submodules?). This is definitely not doable and is at odds with the way git works. Checking the sizes in the 3.1.0 release I get: % du -hs mingw-w64-* 21M mingw-w64-crt 48K mingw-w64-doc 45M mingw-w64-headers 4.4Mmingw-w64-libraries 4.1Mmingw-w64-tools Separating tools, libraries (which includes winpthreads), doc would not be useful to save download time. Anothe experiment: size taken by git itself (remember there is from a tarball and there is no history): git add . git commit -m 'Initial commit' du -hs .git: 27M .git same for each mingw-w64-* directory: 13M mingw-w64-crt/.git 120Kmingw-w64-doc/.git 13M mingw-w64-headers/.git 2.3Mmingw-w64-libraries/.git 1.4Mmingw-w64-tools/.git A single repository would save 10% download size or so. I also have a git clone of the current SVN repository. The size of the .git directory is under 70MB and that's with full history; shallow clones would use even less, possibly not much more than the download for only the headers. Note also that, SVN fetches are slow while git's are much faster. IIRC SVN does one request per file in a sequential manner or something like that. Git will download the data packed in a few files and will be able to max out your connection (or the server's). I'd say you can expect fetches to be 10 times faster with git than with svn for the same amount of data. If you do these operations really frequently, you should probably setup local clones of the git repository: serving them locally is absolutely trivial (i.e. nothing to do) and updates should be near-instantaneous. -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. Best, Matthew -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014 at 10:03 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 17:04, JonY wrote: On 4/28/2014 19:53, Ruben Van Boxem wrote: Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can exclude files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). My experience so far: 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt and winpthreads not together, but separately, at different points of time. To this end i'm svn-checkouting from a subdirectory to get only one of the three. I don't remember whether git has that ability; possibly not. If that is the case, these may need to go into separate repos (possibly submodules?). 2) The git branches are for branching out from the main development line (and merging back at some later point), not for completely separate stuff. If you keep completely different stuff in different branches, switching branches (which usually takes less than a second) will take a long time (depending on the size, up to 10 seconds or more). The svn branches are more like git repos - completely independent, they just live together :) While you're investigating different git repo structures, I highly suggest you investigate git's lightly documented orphan branches. These allow multiple disparate branches to exist in a single repo. They allow you to create blank slate style branches based upon a very early initial commit. They work quite different than the merge friendly git branches you typically see documented. You can still cherrypick from other branches if needed. https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html For example, say you want winpthreads on it's own branch that doesn't contain winpthreads unrelated commits. Create the orphan branch similar to # start_point is an initial commit that typically includes only your `.gitattributes` and `.gitignore` files. Consider # start_point to be the primordial branch commit. git checkout --orphan winpthreads start_point # discover that the primordial branch commit start_point is already staged; commit it # as the winpthreads branch initial commit git commit -m Initial commit; project attributes and ignores # add all the winpthreads specific code to this otherwise git commit -am Add winpthreads source # tag the commit with a well-known tag (IIRC, these types of tags are isolated to a single branch so you # likely want some namespacing) git tag winpthreads-0.5.1 # what have I just done? git log --decorate --oneline # make it so git push git push --tags Regarding git vs. mercurial on windows, I use both on a daily basis, like both, but prefer git. The only performance complaint I've had relates to garbage collection. If you try to `git gc --aggressive --prune=now` a large repo, you'll often find that the gc fails due to memory issues even on my 23GB x64 laptop. This is easily solved by setting the `gc.aggressivewindow` config option to a lower value. I'm interested in hearing what perf issues John E. has run into. -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014, JonY wrote: Hi, mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. Structure wise, everything under trunk will still stay together in the new repo, but any externals, /experimental/* and /web may move into its own repo. Discuss. Stating here a few things I mentionned on IRC. I think it would be better to only do the switch after the next point release since it could happen soonish (but this is Ozkan's decision). Of course that doesn't prevent initial work on the matter. A subdirectory of an SVN repository is a valid SVN repository. This is not true with git repositories. This prevents tracking only parts of other repositories like it has been done with ReactOS. Git doesn't have SVN's externals; it has remotes: paths to branches on other repositories. Some of the use cases are the same for both but there are large differences. IIRC git doesn't have per-file attributes like eol-style and mime type. Are they really needed? Should it be only LF for every file(*)? (*) this would break editing the files under notepad and probably only notepad, i.e. that would be a feature :) I think that's it for now. -- Adrien Nadr -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014, Jon wrote: On Mon, Apr 28, 2014 at 10:03 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 17:04, JonY wrote: On 4/28/2014 19:53, Ruben Van Boxem wrote: Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can exclude files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). My experience so far: 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt and winpthreads not together, but separately, at different points of time. To this end i'm svn-checkouting from a subdirectory to get only one of the three. I don't remember whether git has that ability; possibly not. If that is the case, these may need to go into separate repos (possibly submodules?). 2) The git branches are for branching out from the main development line (and merging back at some later point), not for completely separate stuff. If you keep completely different stuff in different branches, switching branches (which usually takes less than a second) will take a long time (depending on the size, up to 10 seconds or more). The svn branches are more like git repos - completely independent, they just live together :) While you're investigating different git repo structures, I highly suggest you investigate git's lightly documented orphan branches. These allow multiple disparate branches to exist in a single repo. They allow you to create blank slate style branches based upon a very early initial commit. They work quite different than the merge friendly git branches you typically see documented. You can still cherrypick from other branches if needed. https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html For example, say you want winpthreads on it's own branch that doesn't contain winpthreads unrelated commits. Create the orphan branch similar to # start_point is an initial commit that typically includes only your `.gitattributes` and `.gitignore` files. Consider # start_point to be the primordial branch commit. git checkout --orphan winpthreads start_point # discover that the primordial branch commit start_point is already staged; commit it # as the winpthreads branch initial commit git commit -m Initial commit; project attributes and ignores # add all the winpthreads specific code to this otherwise git commit -am Add winpthreads source # tag the commit with a well-known tag (IIRC, these types of tags are isolated to a single branch so you # likely want some namespacing) git tag winpthreads-0.5.1 # what have I just done? git log --decorate --oneline # make it so git push git push --tags Aren't they a bit difficult to manipulate and error-prone (accidental merges or data exchange between branches)? At least that's my feeling. Regarding git vs. mercurial on windows, I use both on a daily basis, like both, but prefer git. The only performance complaint I've had relates to garbage collection. If you try to `git gc --aggressive --prune=now` a large repo, you'll often find that the gc fails due to memory issues even on my 23GB x64 laptop. This is easily solved by setting the `gc.aggressivewindow` config option to a lower value. I'm interested in hearing what perf issues John E. has run into. When looking at the size of the git-svn clone I have a few minutes ago, I tried git gc --aggressive and it took a bit over 2GB of memory. As you said, it's a matter of setting the right values (and I believe the default ones in git are not sane) but the first thing is that --aggressive is usually not needed nor very useful. It is nice to save as much space as possible but during my test it saved only around 5% (from
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 22:42, Adrien Nader wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. You can do pull-requests with mailing lists [1] [1] http://stackoverflow.com/questions/6235379 - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTXqcYAAoJEOs4Jb6SI2CwR6cIAMPnaQ6e7kGUgnOqjS2qKvM4 zKWjGQbkkSM2Wmb02sj8W8A/gT5S5BaE5qv+P9A672xNumz0eP0DfhF15NIMpc8v d8/SrhofOoj/OZ270MSoSBhLlMuNJUJtS/HEHoAsw1ZgDQ56UN4C9ob6duuyiaJl nvWu1ut9aT911u0YEhh0KUw9lKfoD4fLxrJHsn14jVztUsAF31hp0tVQkgGNm0SD V4BWC5nUkpvPU928ZmxllfpcRLCmRbfPCyg3pab41ODQ7DJfmmZg+uf4B/YlhF0/ 5fp6EeUGPWx8+l7dSiYgxrJrtRIj31fdeMV0IQ+VQ0bYljIqGNpW0jgtHNK8Vlk= =ERLc -END PGP 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, On Mon, Apr 28, 2014 at 11:42 AM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. Sometimes it doesn't seem as if small things will make much difference, but when you try them, they do. Things really change when you're using git - because a) work is naturally arranged in commits (this helps review and organization) b) you can make more substantial changes because branching / merging is so easy This makes it harder to review patches as text in email, because patches usually don't carry the commit info, and because it's only comfortable to review small changes in email text. It's very inconvenient reviewing larger work-in-progress changes via patches, because it's easy to lose track of the relationship of previous comments and code changes. If the author responds to comments, they either have to email the whole revised patch again, or you the developer need to keep a branch of your own in sync with theirs, in order to test their changes. This is why the pull-request mechanism is so remarkably good in github - it makes proposing changes part of ordinary workflow. A proposed change is always just a branch. 1) Start work on your own branch 2) Push to your own fork on github while you're working 3) Make pull request via a few clicks or 'hub' command line tool 4) Anyone can comment on whole pull request, individual commits or individual lines, using github email interface or web form interface. 5) Comments remain on web interface for public record. 6) Developer can rebase on master as needed using same pull request pages. I think this isn't very obvious at first because svn is so hard to branch that you very rarely get substantial / long-lived changes except by the lead developers. I really like the command line, I use vim as my editor, never use GUIs for git - but I couldn't live without the github pull-request interface for my projects. Cheers, Matthew -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 22:42, Adrien Nader wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. You can do pull-requests with mailing lists [1] [1] http://stackoverflow.com/questions/6235379 I'm aware of most of the things available to minimize contact with the Web UIs of github; I find there's something telling about their availability. ;p -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 04/28/14 13:17, JonY wrote: Discuss. I will just add a huge YEAH from me. I'm happy to help with the migration. Cheers, Jacek -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014 at 12:10 PM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 22:42, Adrien Nader wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. You can do pull-requests with mailing lists [1] [1] http://stackoverflow.com/questions/6235379 I'm aware of most of the things available to minimize contact with the Web UIs of github; I find there's something telling about their availability. ;p Yes, some people really don't like web UIs. These people are usually experienced developers who are not easily deterred from working out their own tools for doing stuff the way they want. I think the point of the github interface is lowering the barrier for people who are not (yet) in that camp, or who are in that camp but don't yet know how to automate their work with git in a satisfying way. Actually, I usually really don't like web UIs, with the single exception of the github pull request interface. For example, I usually use the 'hub' command line tool to interact with github [1]. I just found 'git-pulls' [2] which also looks useful. For commenting on large blocks of changes, I want the web interface. For example - maybe take a look at some of the 'how to contribute' pages for github projects. Here's an example from project I know well: http://sympy.org/en/development.html In there you'll see: The github pull request is a preferred method, as that makes it easy for us to review and push the code in. That said, you can also clone the latest git repository (see the link on the right), prepare a branch with your code, upload it somewhere (for examplegithub) and send us a link to the sympy-patches mailinglist, or you can even send us raw patches --- but it will be more work for us to integrate it. Cheers, Matthew [1] https://github.com/github/hub [2] https://github.com/schacon/git-pulls -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 11:42 AM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. Sometimes it doesn't seem as if small things will make much difference, but when you try them, they do. Things really change when you're using git - because a) work is naturally arranged in commits (this helps review and organization) b) you can make more substantial changes because branching / merging is so easy This makes it harder to review patches as text in email, because patches usually don't carry the commit info, and because it's only comfortable to review small changes in email text. It's very inconvenient reviewing larger work-in-progress changes via patches, because it's easy to lose track of the relationship of previous comments and code changes. If the author responds to comments, they either have to email the whole revised patch again, or you the developer need to keep a branch of your own in sync with theirs, in order to test their changes. This is why the pull-request mechanism is so remarkably good in github - it makes proposing changes part of ordinary workflow. A proposed change is always just a branch. 1) Start work on your own branch 2) Push to your own fork on github while you're working 3) Make pull request via a few clicks or 'hub' command line tool 4) Anyone can comment on whole pull request, individual commits or individual lines, using github email interface or web form interface. 5) Comments remain on web interface for public record. 6) Developer can rebase on master as needed using same pull request pages. I think this isn't very obvious at first because svn is so hard to branch that you very rarely get substantial / long-lived changes except by the lead developers. I really like the command line, I use vim as my editor, never use GUIs for git - but I couldn't live without the github pull-request interface for my projects. I see, thanks. When the amount of code to review gets larger, I simply run gitk which is not pretty but works really well. Gives the commit history and diffs and files modified; it's one of the 3 non-CLI applications I run on a daily basis. I also like that once the changes are available locally (not necessarily checked out on disk), I can use the usual tools to find and grep while github's search has never helped me find something interesting (and same for everyone around me). -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
One more note on the TODO: chose how commits are organized. I like: feature branches (I think everyone does) and rebase on master before merge provided the branch hasn't been merged elsewhere too. This gives a linear history which is much nicer than octopuss-shaped graphs. In case anyone doubts it I'll screenshot the result at work. -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, On Mon, Apr 28, 2014 at 12:38 PM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 11:42 AM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. Sometimes it doesn't seem as if small things will make much difference, but when you try them, they do. Things really change when you're using git - because a) work is naturally arranged in commits (this helps review and organization) b) you can make more substantial changes because branching / merging is so easy This makes it harder to review patches as text in email, because patches usually don't carry the commit info, and because it's only comfortable to review small changes in email text. It's very inconvenient reviewing larger work-in-progress changes via patches, because it's easy to lose track of the relationship of previous comments and code changes. If the author responds to comments, they either have to email the whole revised patch again, or you the developer need to keep a branch of your own in sync with theirs, in order to test their changes. This is why the pull-request mechanism is so remarkably good in github - it makes proposing changes part of ordinary workflow. A proposed change is always just a branch. 1) Start work on your own branch 2) Push to your own fork on github while you're working 3) Make pull request via a few clicks or 'hub' command line tool 4) Anyone can comment on whole pull request, individual commits or individual lines, using github email interface or web form interface. 5) Comments remain on web interface for public record. 6) Developer can rebase on master as needed using same pull request pages. I think this isn't very obvious at first because svn is so hard to branch that you very rarely get substantial / long-lived changes except by the lead developers. I really like the command line, I use vim as my editor, never use GUIs for git - but I couldn't live without the github pull-request interface for my projects. I see, thanks. When the amount of code to review gets larger, I simply run gitk which is not pretty but works really well. Gives the commit history and diffs and files modified; it's one of the 3 non-CLI applications I run on a daily basis. I also like that once the changes are available locally (not necessarily checked out on disk), I can use the usual tools to find and grep while github's search has never helped me find something interesting (and same for everyone around me). Sure, if the changes get large, then I often find myself checking out the branch locally as well. The pain comes when commenting on changes line by line using email, and that soon becomes very annoying on a commit - by - commit basis, and tough for the author to track. I haven't found it much of a problem going between the web interface for comments and using local tools to look at diffs, but ``git-pulls browse`` looks like a nice way do to that. Cheers, Matthew -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 23:29, Matthew Brett wrote: On Mon, Apr 28, 2014 at 12:10 PM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 22:42, Adrien Nader wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. You can do pull-requests with mailing lists [1] [1] http://stackoverflow.com/questions/6235379 I'm aware of most of the things available to minimize contact with the Web UIs of github; I find there's something telling about their availability. ;p Yes, some people really don't like web UIs. These people are usually experienced developers who are not easily deterred from working out their own tools for doing stuff the way they want. I think the point of the github interface is lowering the barrier for people who are not (yet) in that camp, or who are in that camp but don't yet know how to automate their work with git in a satisfying way. Actually, I usually really don't like web UIs, with the single exception of the github pull request interface. For example, I usually use the 'hub' command line tool to interact with github [1]. I just found 'git-pulls' [2] which also looks useful. For commenting on large blocks of changes, I want the web interface. For example - maybe take a look at some of the 'how to contribute' pages for github projects. Here's an example from project I know well: http://sympy.org/en/development.html In there you'll see: The github pull request is a preferred method, as that makes it easy for us to review and push the code in. That said, you can also clone the latest git repository (see the link on the right), prepare a branch with your code, upload it somewhere (for examplegithub) and send us a link to the sympy-patches mailinglist, or you can even send us raw patches --- but it will be more work for us to integrate it. For the record, i've had a nasty squabble with a hexchat developer, because he wouldn't accept contributions in any format other than a git pull from github. Since i wasn't about to create a fork of hexchat on github (because github is not free, as in free speech) to send pull requests from, i couldn't accommodate that policy. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTXrR2AAoJEOs4Jb6SI2CwqfMH/0qN54FOl2tjSsqSr5AEOrVB mtmHS11lMgNIZXXdZ+g1Bmir9HLi5eAs8HPLbCS8Xb5CyOsWZlltX6sURV9ShncB 1PdcHzi1CrgxafAtp3B+mOzum55huhTCZWuFLYIVCFgS6gQ23wyMpTKQR2+gYwcF qEIrRPe+itInM0sf5pFQdtpE8DyGsmU9IlRGoEP06lUVbZ+0RS2q2mpT8GWKL1cF zwbjfkbknWp0A0fOp1mXf94zSka1DK19Pn+UHcQirgshzyzisUyCGYweqIanOCR6 /hHwQBSt57dKxjiQvkmMXQ0PZFg2iGcHvUXtyimV8J/BGVqzfNHwrr4+3nebaW8= =hcH/ -END PGP 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Hi, On Mon, Apr 28, 2014 at 1:05 PM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 23:29, Matthew Brett wrote: On Mon, Apr 28, 2014 at 12:10 PM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 22:42, Adrien Nader wrote: On Mon, Apr 28, 2014, Matthew Brett wrote: Hi, On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM tdra...@tdragon.net wrote: On 4/28/2014 5:17 AM, JonY wrote: mingw-w64 may migrate from svn to git in the future, seeing that sf can now do multiple repos per project. *snip* Discuss. I'm a bit surprised at the choice of Git -- in my experience, Windows developers usually prefer Mercurial (http://mercurial.selenic.com/) because on Windows it is more lightweight and performant than Git. I also prefer Mercurial to Git because I find its syntax and workflow more intuitive. This is of course personal taste. Mercurial repositories are also available in SourceForge. But if the primary MinGW-w64 contributors are all more familiar with Git then I suppose it shall be Git. My two cents. :) From the sidelines - a big yes please for switching to git. In my experience, the ease of git branching makes it far more comfortable making and proposing changes, even substantial changes. I hear the same is true of mercurial, but I know it much less well. I very much like the github pull-request system for code review - does sourceforge have something similar? I know bitbucket does. For the projects I'm involved in, pull requests make proposing changes very fluid, and they are good for recording discussion as well. I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. Anyway, is there an advantage github's pages over doing it on the mailing-list like it is currently done? The amount of messages which comes from that doesn't seem to be an issue. You can do pull-requests with mailing lists [1] [1] http://stackoverflow.com/questions/6235379 I'm aware of most of the things available to minimize contact with the Web UIs of github; I find there's something telling about their availability. ;p Yes, some people really don't like web UIs. These people are usually experienced developers who are not easily deterred from working out their own tools for doing stuff the way they want. I think the point of the github interface is lowering the barrier for people who are not (yet) in that camp, or who are in that camp but don't yet know how to automate their work with git in a satisfying way. Actually, I usually really don't like web UIs, with the single exception of the github pull request interface. For example, I usually use the 'hub' command line tool to interact with github [1]. I just found 'git-pulls' [2] which also looks useful. For commenting on large blocks of changes, I want the web interface. For example - maybe take a look at some of the 'how to contribute' pages for github projects. Here's an example from project I know well: http://sympy.org/en/development.html In there you'll see: The github pull request is a preferred method, as that makes it easy for us to review and push the code in. That said, you can also clone the latest git repository (see the link on the right), prepare a branch with your code, upload it somewhere (for examplegithub) and send us a link to the sympy-patches mailinglist, or you can even send us raw patches --- but it will be more work for us to integrate it. For the record, i've had a nasty squabble with a hexchat developer, because he wouldn't accept contributions in any format other than a git pull from github. Since i wasn't about to create a fork of hexchat on github (because github is not free, as in free speech) to send pull requests from, i couldn't accommodate that policy. I can certainly see the argument that github is not open-source, and therefore implies some level of vendor lock-in. There are open-source alternatives, but I haven't used them for anything more than playing with. I also agree it should always be possible to submit changes without github. So if the author of the change prefers to email the patch, it seems silly to object. The key thing surely is to reduce the barrier for contribution as far as possible while keeping the barrier for maintainers at a reasonable level. Cheers, Matthew -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On 4/28/2014 12:11 PM, Jon wrote: Regarding git vs. mercurial on windows, I use both on a daily basis, like both, but prefer git. The only performance complaint I've had relates to garbage collection. If you try to `git gc --aggressive --prune=now` a large repo, you'll often find that the gc fails due to memory issues even on my 23GB x64 laptop. This is easily solved by setting the `gc.aggressivewindow` config option to a lower value. I'm interested in hearing what perf issues John E. has run into. In general, the larger and older the codebase, the more Git's performance on Windows worsens in comparison to Mercurial's. I've noticed this for day-to-day operations (commits, merges, patch queues / quilts), and even more so for operations requiring deeper historical data -- blames, change histories, etc. This has been my experience with a couple of large codebases (for example, GCC's git mirrors) and I see it corroborated in many other places ([1] for example). Not that I want to start a new VCS holy war. If MinGW-w64 switches to Git, I will grin and bear it. :) -John E. / TDM [1] - http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ (see also http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/) -- 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
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, Apr 28, 2014 at 2:32 PM, Adrien Nader adr...@notk.org wrote: On Mon, Apr 28, 2014, Jon wrote: On Mon, Apr 28, 2014 at 10:03 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.04.2014 17:04, JonY wrote: On 4/28/2014 19:53, Ruben Van Boxem wrote: Different repositories may sound like a nice idea, but keeping them in sync can be a pain, depending on the complexity of the subprojects. I believe stuff like ironcrate, winpthreads and perhaps the mingw-w64-tools folder deserve their own repo, as they are very seperate from the headers+crt. These latter two I'd suggest to keep together, as that will reduce the chances of wrong versions being used together and allow 1 commit to change both to keep them aligned without any hassle. In contrast, I would try to move away from a seperate experimental directory, and instead inject these changes into a branch (or several, so that each finished feature can be merged easily). Branches and merging are the git way, and rebasing allows for clean merges. For ease of migration, every module in trunk would go into the same repo, so that would include winpthreads and mingw-w64-tools. I'm not sure if we can exclude files from the import unless we want to completely break apart trunk into components. However, I am also trying to avoid too many separate repos and git submodules. Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper (with anything from experimental if applicable), web, and experimental (if it actually justifies a separate repo, otherwise, it might be archived and left as is on SVN). My experience so far: 1) When i build gcc, i often need to build mingw-w64-headers, mingw-w64-crt and winpthreads not together, but separately, at different points of time. To this end i'm svn-checkouting from a subdirectory to get only one of the three. I don't remember whether git has that ability; possibly not. If that is the case, these may need to go into separate repos (possibly submodules?). 2) The git branches are for branching out from the main development line (and merging back at some later point), not for completely separate stuff. If you keep completely different stuff in different branches, switching branches (which usually takes less than a second) will take a long time (depending on the size, up to 10 seconds or more). The svn branches are more like git repos - completely independent, they just live together :) While you're investigating different git repo structures, I highly suggest you investigate git's lightly documented orphan branches. These allow multiple disparate branches to exist in a single repo. They allow you to create blank slate style branches based upon a very early initial commit. They work quite different than the merge friendly git branches you typically see documented. You can still cherrypick from other branches if needed. https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html For example, say you want winpthreads on it's own branch that doesn't contain winpthreads unrelated commits. Create the orphan branch similar to # start_point is an initial commit that typically includes only your `.gitattributes` and `.gitignore` files. Consider # start_point to be the primordial branch commit. git checkout --orphan winpthreads start_point # discover that the primordial branch commit start_point is already staged; commit it # as the winpthreads branch initial commit git commit -m Initial commit; project attributes and ignores # add all the winpthreads specific code to this otherwise git commit -am Add winpthreads source # tag the commit with a well-known tag (IIRC, these types of tags are isolated to a single branch so you # likely want some namespacing) git tag winpthreads-0.5.1 # what have I just done? git log --decorate --oneline # make it so git push git push --tags Aren't they a bit difficult to manipulate and error-prone (accidental merges or data exchange between branches)? At least that's my feeling. I don't see how using orphan branches are any more error-prone than any other type of branch. That said, since stand-alone orphan branches likely are not used as much as feature branches, perhaps this could be a valid concern. Try creating a clean history orphan branch and play with it. I think you find it useful for certain scenarios. It's an easy way to emulate a repo-within-a-repo type structure without too many mental hijinks. Regarding per-file (emulated) attributes, check out https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html While EOL and binary file issues are easily solved, I'm not sure how mime type issues are best solved, if at all, with gitattributes.
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
Adrien Nader adr...@notk.org writes: I quite dislike github and its UI in particular. Uses flash on every page (no idea what for) and lots of javascript which makes my laptop heat and get noisy when displaying something as small as a 3-lines diff. I see no flash at all on Github (it is activated only on request on my web browser) and CPU usage is almost zero. Some months ago I tried using Github with Javascript disabled and it worked fine for opening/commenting on issues and for browsing commits. I don't recall if I tried pull requests too, but the message I got was that Github cares about people who doesn't want Javascript. Not that I'm suggesting a switch to Github... [snip] -- 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
