On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak <[email protected]> wrote: > > It seems like there are a couple of different issues here that affect how we > do version control. Currently we have an SVN primary repository, some > contributors use SVN, and others use git via git-svn. > > It seems like there are two possible changes we can make, and it is not > really clear to me which is being advocated: > > 1) Offer only a git repository; everyone uses git. > 2) Use a git central repository; but some form of svn access is provided (is > this even possible?) > > And then there is the status quo: > > 3) Continue doing what we're doing; central repository is svn, but anyone is > free to use git and we try to make it convenient to do so. > > One interesting asymmetry here is that, while many git users proseltyze git > and advocate total removal of svn support from our tools and infrastructure, > no one seems to advocate completely removing git support. So I left that > option off. There are also other distributed version control systems out > there such as Mercurial or Bazaar, but no one seems much in favor of using > them for WebKit, so those options are also left off. > > If we are to assess these options in a deeper way than just everyone saying > what they personally like, we need to identify the pros and cons of options > (1) and (2) relative to (3). That's assuming (2) is even possible. It seems > like there are at least a few factors to consider: > > A) Future quality of life for current git users. > B) Future quality of life for current svn users. > C) Benefits of the master repository being either git or svn, regardless of > what clients are supported. (For example, many folks seem to think > human-understandable revision identifiers is a benefit of the master being > SVN). > D) Cost to the project of maintaining support for two different version > control systems. > > Git advocates on this thread have mostly focused on convincing svn users how > much they'd like using git instead. It seems at least some svn users do not > believe their quality of life would improve by switching to git, including > some who have actually tried git. No one has really identified what benefits > there would be to git users if a change is made. Could someone describe > those?
To the global infrastructure : - Local history for git. svn log access to the server every time you call that command. Will improve the load of the server. - Performance of checkouts/pull as data are send compressed from the server. To git user : - Using git push rather than having to use git-svn (which you need to keep in sync). - Simplified workflow, we don't need to mess with git-svn. - Companies who fork (we all do) can simplify their workflow a bit regarding branches. To svn user : - Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn). - Local history/blaming/... - Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff). - The staging area, upload what you want/need and keep some work local - Smaller checkouts The real downside is for the svn users to learn a bit git workflow. I'm forgetting stuff for sure. > > Regards, > Maciej > > > On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote: > > (For those valuable contributors who are against Git and have manifested > somehow here, please do not take it personally) > > IMO, none of the arguments used here so far seem like a real problem for a > switch. Of course, SVN people would have to adapt their workflow and it > could take days (no more than that, trust me), but it is for a greater goal > at the end. > > In my opinion, SVN concepts are completely obsolete these days. It is hard > to me to even hear someone arguing in favor of SVN against GIT, but I > respect anyone's opinion. I just do not feel them strong enough given the > whole context. > > On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason <[email protected]> wrote: >> >> It seems to me that there's no need to use multiple local branches in git >> if you find it confusing - it's an additional feature, but I don't see >> anything that requires it. >> >> What workflow do you have that requires you to have multiple branches >> locally in git, and how do you solve it in svn without using branches? >> >> What precisely do you find difficult about merging remote changes, and how >> is the svn equivalent easier? >> ________________________________ >> From: [email protected] >> [[email protected]] on behalf of Ryosuke Niwa >> [[email protected]] >> Sent: Thursday, March 08, 2012 3:00 PM >> To: Ashod Nakashian >> Cc: WebKit Development >> Subject: Re: [webkit-dev] Moving to Git? >> >> On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian >> <[email protected]<mailto:[email protected]>> wrote: >> >And that's a show stopper for me. For build bot maintenance, regression >> > fixes, etc... being able to easily tell the number of commits between two >> > revisions (in my head as opposed to using a tool) or the ordering of >> > commits >> > is crucial. >> >> I think this is an interesting point. It seems there are two solutions. We >> can enforce fast-forward as many have pointed out and we can maintain an SVN >> mirror. Although I don't like the idea of maintaining an SVN repo, and it's >> almost universally agreed that git offers superior tools to SVN. >> >> I don't think so. I like the simplicity of svn. While git client works >> great, I always get frustrated by the complexity of having multiple branches >> locally and the amount of work required to merge the remote changes on the >> branch I'm working on. >> >> - Ryosuke >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from your >> system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > -- > --Antonio Gomes > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
