# [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation. - Thread: https://externals.io/message/54433 - Original archive: https://news-web.php.net/php.internals/54433 - Started by David Soria Parra on 2011-08-07T20:50:55+00:00 - Messages: 78 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/54433.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54433 — David Soria Parra — 2011-08-07T20:50:55+00:00 URL: https://externals.io/message/54433#54433 Hi Internals, Distributed Version Control Systems (DVCS) getting more and more popular. In fact they have been discussed within the PHP community and on Internals a few times. It came to my attention that more and more people like to see PHP move to a DVCS to solve some of the current issues (and get other ones). I was asked to put together a RFC, and so here we are. I've created an initial draft. It is mostly based on the very good Python PEP-0374. It compares Git and Mercurial. https://wiki.php.net/rfc/dvcs There are reasons for choosing these systems: * Both are quite popular * I know them * Most PHP devs that I know, know at least on of them * Big projects have recently moved to them, they have similar requirements like PHP The RFC is far from done, so please help me finishing it and get it out. This is a call for participation to help to get a (probably heated) discussed started and work on the RFC to make it good enough to finally choose a system or, and that is a valid option, stay with SVN. So if: - you are interested in DVCS - know a little bit about PHPs requirements for a DVCS - are not a fanboy Feel free to discuss this and add your thoughts to the RFC. I would love to not do this on my own. Feel free to catch me on IRC (dsp_ on php.pecl) and discuss it. NOTE: this is not the place for any religiouise discussion about git vs mercurial whatsover. if you have nothing else to add than "hg is $*** anyway" or think hosting platform XY will solve all our problems without reading the RFC carefully, please post to alt.relgion.* and not here. - David --- ## #54434 — Richard Quadling — 2011-08-07T21:13:32+00:00 URL: https://externals.io/message/54433#54434 · In reply to: #54433 > Hi Internals, > > Distributed Version Control Systems (DVCS) getting more and more > popular. In fact they have been discussed within the PHP community and > on Internals a few times. It came to my attention that more and more > people like to see PHP move to a DVCS to solve some of the current > issues (and get other ones). > > I was asked to put together a RFC, and so here we are. I've created > an initial draft. It is mostly based on the very good Python PEP-0374. > It compares Git and Mercurial. > >    https://wiki.php.net/rfc/dvcs > > There are reasons for choosing these systems: >   * Both are quite popular >   * I know them >   * Most PHP devs that I know, know at least on of them >   * Big projects have recently moved to them, they have >     similar requirements like PHP > > The RFC is far from done, so please help me finishing it and get it out. > > This is a call for participation to help to get a (probably heated) > discussed started and work on the RFC to make it good enough to finally > choose a system or, and that is a valid option, stay with SVN. > > So if: >  - you are interested in DVCS >  - know a little bit about PHPs requirements for a DVCS >  - are not a fanboy > > Feel free to discuss this and add your thoughts to the RFC. I would > love to not do this on my own. Feel free to catch me on IRC (dsp_ on > php.pecl) and discuss it. > > NOTE: this is not the place for any religiouise discussion about git vs > mercurial whatsover. if you have nothing else to add than "hg is $*** > anyway" or think hosting platform XY will solve all our problems > without reading the RFC carefully, please post to alt.relgion.* and not > here. > > > - David I feel I have a major objection to using a DVCS for PHP. Currently, a single source provides a sense of authority. If bad code is committed, it will be quickly dealt with. If good code is incomplete it may be withdrawn or fixed. In most cases the features that exist in a branch are well thought out and many clever brains have seen it and interacted with it to make it what it is. So, when someone like me comes along, someone capable of building the code and playing with it at a very minor level, I can be sure that if things don't work, it is probably me that's broke it and that I can rely on the branch to contain good working code. OK. I know ITRW, things do get left unfinished or plain broken. But it isn't as if the code belongs to a single person who may have not spent all their time with it. Whilst I am happy to use my own builds on my dev setups, I'm also happy to rely on the official releases from The PHP Group. Now let's envisage a DVCS. There will be (not might be, but will be), multiple, and potentially conflicting/incompatible, versions available. Which do I choose? If everyone is capable of forking PHP, which is the official one? In the event of a single official repo, then why bother with a DVCS? (I'll admit I'm naive on the true requirement of DVCS, as I think SVN works very well). The main thing I'm worried about is if feature X splits the core devs so much that there are 2 competing repos, both with a significant number of core devs supporting each repo, how do I choose which is which? If my abilities include being able to code at the core level, which should I support? Both? All 3, 4 or 10 different forks? Having a single repository for the code makes the code the official, authoritative version. A DVCS will have too many champions and I feel would drastically dilute that authority. Regards, Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea --- ## #54435 — David Soria Parra — 2011-08-07T21:19:41+00:00 URL: https://externals.io/message/54433#54435 · In reply to: #54434 > I feel I have a major objection to using a DVCS for PHP. > > Currently, a single source provides a sense of authority. If bad code > is committed, it will be quickly dealt with. If good code is > incomplete it may be withdrawn or fixed. In most cases the features > that exist in a branch are well thought out and many clever brains > have seen it and interacted with it to make it what it is. > > So, when someone like me comes along, someone capable of building the > code and playing with it at a very minor level, I can be sure that if > things don't work, it is probably me that's broke it and that I can > rely on the branch to contain good working code. OK. I know ITRW, > things do get left unfinished or plain broken. But it isn't as if the > code belongs to a single person who may have not spent all their time > with it. > > Whilst I am happy to use my own builds on my dev setups, I'm also > happy to rely on the official releases from The PHP Group. > > > Now let's envisage a DVCS. > > There will be (not might be, but will be), multiple, and potentially > conflicting/incompatible, versions available. Which do I choose? If > everyone is capable of forking PHP, which is the official one? In the > event of a single official repo, then why bother with a DVCS? (I'll > admit I'm naive on the true requirement of DVCS, as I think SVN works > very well). The objection is valid, but it's just a minor concern. A main repository in a DVCS is not defined by being the only existant repository, but rather by common sense and knowledge where to find the main one. For PHP this is easy: there will be (git|hg).php.net where you will find the main repository. There is the github.com/php and bitbucket.org/php user that we own. They will be used to host the main repository. I think it's very easy to figure out what the main repository is and what not (particularly as github and bitbucket have fork views where you see relations and where they've forked from). So using conventions and common sense tend to work rather well. An example: it is known that the main linux tree is Linus one, and not mine, so if you search for the main linux tree you will clone Linus tree and not mine. > The main thing I'm worried about is if feature X splits the core devs > so much that there are 2 competing repos, both with a significant > number of core devs supporting each repo, how do I choose which is > which? If my abilities include being able to code at the core level, > which should I support? Both? All 3, 4 or 10 different forks? > > Having a single repository for the code makes the code the official, > authoritative version. A DVCS will have too many champions and I feel > would drastically dilute that authority. I think no Open Source project has yet suffered from what you've described. -David --- ## #54436 — johannes@schlueters.de — 2011-08-07T21:21:15+00:00 URL: https://externals.io/message/54433#54436 · In reply to: #54434 > So, when someone like me comes along, someone capable of building the > code and playing with it at a very minor level, I can be sure that if > things don't work, it is probably me that's broke it and that I can > rely on the branch to contain good working code. OK. I know ITRW, > things do get left unfinished or plain broken. But it isn't as if the > code belongs to a single person who may have not spent all their time > with it. you can fork it as you want on github (you can do that already btw.) but you won't be able to push it on git.php.net (as you can't do know). No real difference there. Only difference is that code can be tracked and manged before reaching php.net's main tree. There already inofficial versions out there, sometimes containing "strange" patches. They are called "distribution packages" - even harder to detect. johannes --- ## #54437 — Stas Malyshev — 2011-08-07T21:24:09+00:00 URL: https://externals.io/message/54433#54437 · In reply to: #54433 Hi! As somebody that have seen reasonably big project switch from SVN to git and worked quite actively with git since then, I think describing my experience might be useful for those that never tried it. 1. git is much better than svn especially as applied to complex projects with multiple participants which need to accept outside patches, maintain multiple branches and port fixes between branches. You never know how much you needed cheap branching/merging until you worked with it some. 2. Switching from svn to git requires one to undergo some mental shift, and for the first couple of weeks you may be confused and somewhat frustrated by too many things that look like but not exactly like the old system. It would appear too complex and unnecessarily complicating workflows. However, as you develop new routines, you'll find out how it makes sense and will become more effective than with svn. Note that git IS much more complex conceptually than SVN and allows to do much more crazy things - including rewriting history in all kinds of weird ways - so while I don't think I had to ask SVN question in forums for years - I still have to google "how to do this in git" and ask around for some of the more complex things. I think it's still worth it. Don't know if it makes me a fanboy :) 3. Having system like github around it adds a lot - maintaining multiple repositories, forks and pull requests is a real boon. I'm not sure if it would make sense for php, all things considered, but there are very significant benefits of using such a system where many workflows are already built-in. Please note that it's not "hg vs git" argument as I know very little about hg and have no experience working with it, but I've read what people write about it and I'm sure many of git's strengths are present in hg too. I hope somebody with experience in hg (or both, even better) will voice in. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54438 — Stas Malyshev — 2011-08-07T21:26:00+00:00 URL: https://externals.io/message/54433#54438 · In reply to: #54434 Hi! > There will be (not might be, but will be), multiple, and potentially > conflicting/incompatible, versions available. Which do I choose? If > everyone is capable of forking PHP, which is the official one? In the > event of a single official repo, then why bother with a DVCS? (I'll > admit I'm naive on the true requirement of DVCS, as I think SVN works > very well). You can build single-source workflows around DCVS too. The fact that everybody is keeping the copy of the history doesn't mean there can't be one "main" repository. The point of DCVS is not as much in doing different things from what we're doing now as doing roughly the same things in a better way - more efficiently. > The main thing I'm worried about is if feature X splits the core devs > so much that there are 2 competing repos, both with a significant > number of core devs supporting each repo, how do I choose which is > which? If my abilities include being able to code at the core level, > which should I support? Both? All 3, 4 or 10 different forks? This can happen right now - take the code, put it on any of the hosting facilities and declare yourself the new king of PHP. DCVS changes nothing here. It's the process that defines the workflows, not the technology. Technology just makes the workflows easier to execute. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54439 — David Soria Parra — 2011-08-07T21:32:14+00:00 URL: https://externals.io/message/54433#54439 · In reply to: #54437 > Hi! > > As somebody that have seen reasonably big project switch from SVN to git > and worked quite actively with git since then, I think describing my > experience might be useful for those that never tried it. > > 1. git is much better than svn especially as applied to complex projects > with multiple participants which need to accept outside patches, > maintain multiple branches and port fixes between branches. You never > know how much you needed cheap branching/merging until you worked with > it some. > > 2. Switching from svn to git requires one to undergo some mental shift, > and for the first couple of weeks you may be confused and somewhat > frustrated by too many things that look like but not exactly like the > old system. It would appear too complex and unnecessarily complicating > workflows. However, as you develop new routines, you'll find out how it > makes sense and will become more effective than with svn. Note that git > IS much more complex conceptually than SVN and allows to do much more > crazy things - including rewriting history in all kinds of weird ways - > so while I don't think I had to ask SVN question in forums for years - I > still have to google "how to do this in git" and ask around for some of > the more complex things. I think it's still worth it. Don't know if it > makes me a fanboy :) > > 3. Having system like github around it adds a lot - maintaining multiple > repositories, forks and pull requests is a real boon. I'm not sure if it > would make sense for php, all things considered, but there are very > significant benefits of using such a system where many workflows are > already built-in. having a dvcs will enable us to use pull requests in github. (maybe you will not able to use the big merge button but rather do it yourself, but still it's a huge improvement). > > > Please note that it's not "hg vs git" argument as I know very little > about hg and have no experience working with it, but I've read what > people write about it and I'm sure many of git's strengths are present > in hg too. I hope somebody with experience in hg (or both, even better) > will voice in. yes hg offers most of this too. your arguments are general arguments in favor of DVCS. There are some minor differences in branching and file handling so some people call hg easier to learn when coming from SVN. Particularly branching is different in hg as outlined in the RFC, making pure lightweight branches a little bit more difficult to handle than in git, but allowing non-lightweight branches which don't exist in Git (this mean that you can forever tell on which branch a changeset was comitted) --- ## #54440 — Richard Riley — 2011-08-07T21:37:53+00:00 URL: https://externals.io/message/54433#54440 · In reply to: #54439 David Soria Parra writes: > > > […] > having a dvcs will enable us to use pull requests in github. (maybe > you will not able to use the big merge button but rather do it yourself, > but still it's a huge improvement). Its really simple. Use git. It works, is fast and is rapidly becoming the industry standard. Do not sue something for "moral grounds" like the awful bzr used for emacs. Its designed as a fast, efficient DVCS. --- ## #54441 — Nikita Popov — 2011-08-07T21:55:53+00:00 URL: https://externals.io/message/54433#54441 · In reply to: #54433 If a transition from SVN to Git were to be done, the question most relevant question for me is whether it will be possible to properly transform the EN-Revision fields in the documentation translation files. I.e. will we be able to keep the current SVN history (just make it a Git history) and also automatedly rewrite those EN-Revision fields to use the appropriate sha1 hashes? I'm all in favor of using Git, but missing EN-Revisions are really a pain and drastically increase the time required for updating translations. I would better keep SVN, if a transformation wouldn't be possible. > Hi Internals, > > Distributed Version Control Systems (DVCS) getting more and more > popular. In fact they have been discussed within the PHP community and > on Internals a few times. It came to my attention that more and more > people like to see PHP move to a DVCS to solve some of the current > issues (and get other ones). > > I was asked to put together a RFC, and so here we are. I've created > an initial draft. It is mostly based on the very good Python PEP-0374. > It compares Git and Mercurial. > >    https://wiki.php.net/rfc/dvcs > > There are reasons for choosing these systems: >   * Both are quite popular >   * I know them >   * Most PHP devs that I know, know at least on of them >   * Big projects have recently moved to them, they have >     similar requirements like PHP > > The RFC is far from done, so please help me finishing it and get it out. > > This is a call for participation to help to get a (probably heated) > discussed started and work on the RFC to make it good enough to finally > choose a system or, and that is a valid option, stay with SVN. > > So if: >  - you are interested in DVCS >  - know a little bit about PHPs requirements for a DVCS >  - are not a fanboy > > Feel free to discuss this and add your thoughts to the RFC. I would > love to not do this on my own. Feel free to catch me on IRC (dsp_ on > php.pecl) and discuss it. > > NOTE: this is not the place for any religiouise discussion about git vs > mercurial whatsover. if you have nothing else to add than "hg is $*** > anyway" or think hosting platform XY will solve all our problems > without reading the RFC carefully, please post to alt.relgion.* and not > here. > > > - David --- ## #54442 — Kiall Mac Innes — 2011-08-07T22:46:43+00:00 URL: https://externals.io/message/54433#54442 · In reply to: #54433 Hi David, Think I may have spotted a mistake in the RFC: Decentralized version control system have some drawbacks: *... Snip .. * no svn:externals, no svn:eol-style Later on in the doc, you go into detail about submodules, and CRLF -> LF support in both Git and Hg. Thanks, Kiall > Hi Internals, > > Distributed Version Control Systems (DVCS) getting more and more > popular. In fact they have been discussed within the PHP community and > on Internals a few times. It came to my attention that more and more > people like to see PHP move to a DVCS to solve some of the current > issues (and get other ones). > > I was asked to put together a RFC, and so here we are. I've created > an initial draft. It is mostly based on the very good Python PEP-0374. > It compares Git and Mercurial. > > https://wiki.php.net/rfc/dvcs > > There are reasons for choosing these systems: > * Both are quite popular > * I know them > * Most PHP devs that I know, know at least on of them > * Big projects have recently moved to them, they have > similar requirements like PHP > > The RFC is far from done, so please help me finishing it and get it out. > > This is a call for participation to help to get a (probably heated) > discussed started and work on the RFC to make it good enough to finally > choose a system or, and that is a valid option, stay with SVN. > > So if: > - you are interested in DVCS > - know a little bit about PHPs requirements for a DVCS > - are not a fanboy > > Feel free to discuss this and add your thoughts to the RFC. I would > love to not do this on my own. Feel free to catch me on IRC (dsp_ on > php.pecl) and discuss it. > > NOTE: this is not the place for any religiouise discussion about git vs > mercurial whatsover. if you have nothing else to add than "hg is $*** > anyway" or think hosting platform XY will solve all our problems > without reading the RFC carefully, please post to alt.relgion.* and not > here. > > > - David --- ## #54443 — Stefan Neufeind — 2011-08-07T23:35:59+00:00 URL: https://externals.io/message/54433#54443 · In reply to: #54440 > David Soria Parra writes: > > > […] [...] > Its really simple. > > Use git. > > It works, is fast and is rapidly becoming the industry standard. Do not > sue something for "moral grounds" like the awful bzr used for emacs. > > Its designed as a fast, efficient DVCS. Hi, The TYPO3-folks migrated to git some while ago. And lately their review-system "review.typo3.org" (readonly now also without a login) went live. The review-system itself is actually another git in front where changes for review can be pushed, can be reviewed, changed and be mangled around, can be finally be abandoned or merged. At merge it's pushed into the main repo. That was a huge win in terms of formal reviews, transparency, speed and ease of reviews etc. And it even helped bug-tracking since now there are no few lines of code hidden in the bugtracker as some kind of "patch" or "quickfix" but that is actually a git-change that you can checkout from review.typo3.org using your git (the system tells you which commandline to use for that). Imho it's dead-simple. I believe it would help PHP a lot to have this kind of transparency and increase both the quality as well as the speed/ease of reviews. Regards, Stefan --- ## #54444 — Ferenc Kovacs — 2011-08-07T23:44:02+00:00 URL: https://externals.io/message/54433#54444 · In reply to: #54443 > > > […] > > [...] > > > […] > > Hi, > > The TYPO3-folks migrated to git some while ago. And lately their > review-system "review.typo3.org" (readonly now also without a login) > went live. The review-system itself is actually another git in front > where changes for review can be pushed, can be reviewed, changed and be > mangled around, can be finally be abandoned or merged. At merge it's > pushed into the main repo. That was a huge win in terms of formal > reviews, transparency, speed and ease of reviews etc. And it even helped > bug-tracking since now there are no few lines of code hidden in the > bugtracker as some kind of "patch" or "quickfix" but that is actually a > git-change that you can checkout from review.typo3.org using your git > (the system tells you which commandline to use for that). Imho it's > dead-simple. > > I believe it would help PHP a lot to have this kind of transparency and > increase both the quality as well as the speed/ease of reviews. > > > Regards, >  Stefan > > -- > > > > btw. for code-review and change control there are also existing open source tools like gerrit for git. http://code.google.com/p/gerrit/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54445 — Hannes Landeholm — 2011-08-07T23:48:56+00:00 URL: https://externals.io/message/54433#54445 · In reply to: #54443 Hi, I'd +1 moving to git. I just moved my own project to github from our own SVN. Mainly for economical reasons as this allowed us to not have to maintain our own repository and because github had excellent features. Another point was of course git's superiority over svn when it comes to many basic features such as keeping your own local repository, branching, tagging etc. I'd also recommend that you see this insightful and hilarious talk by Linus Torvalds if you haven't already: http://www.youtube.com/watch?v=4XpnKHJAok8 ~Hannes --- ## #54446 — Kiall Mac Innes — 2011-08-08T00:14:30+00:00 URL: https://externals.io/message/54433#54446 · In reply to: #54444 Yes - Gerrit is what Typo3, CyanogenMod, OpenStack and of course, Android are using... The OpenStack guys have a good introduction on how to use Gerrit from a developers point of view - http://wiki.openstack.org/GerritWorkflow The CyanogenMod guys have a good introduction on how to use Gerrit AND Repo (a multiple repository management tool) from a developers point of view - http://wiki.cyanogenmod.com/wiki/Howto:_Gerrit Also - There is a Gerrit plugin for the Jenkins CI server that allows for pre-testing commits if desired - https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Plugin Thanks, Kiall > > > […] > > btw. for code-review and change control there are also existing open > source tools like gerrit for git. > http://code.google.com/p/gerrit/ > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #54447 — Stefan Neufeind — 2011-08-08T00:24:05+00:00 URL: https://externals.io/message/54433#54447 · In reply to: #54444 > > > […] > > btw. for code-review and change control there are also existing open > source tools like gerrit for git. > http://code.google.com/p/gerrit/ They use gerrit. It's just configured with a few nice hooks like to automatically update a ticket-status when a new patch is sent to the review-system or when it is merged (issue referenced by "Resolves: #xxxxx" in the comment is closed). Also a build-bot is triggered which sends its results for each patchset into the review and things like that. Regards, Stefan --- ## #54448 — Lester Caine — 2011-08-08T00:46:11+00:00 URL: https://externals.io/message/54433#54448 · In reply to: #54440 Richard Riley wrote: > Its really simple. > > Use git. And stick two fingers up at the windows developer base ;) > It works, is fast and is rapidly becoming the industry standard. Do not > sue something for "moral grounds" like the awful bzr used for emacs. Mercurial is just as popular, especially if you want to support windows projects in parallel with Linux ones ... TortoiseHg just works on both windows and Linux, integrates nicely into file managment and plays nicely in Eclipse ... TortoiseGit is windows only and has compatibility problems. > Its designed as a fast, efficient DVCS. Ditto ... But it does not matter two hoots which one you go for ... http://lsces.co.uk/hg/ we can quite happily use either locally. All that needs to be agreed on is HOW a master distribution clone is managed. Managing transfers of patches between sites requires a lot more management which SVN simply provides by default. Keeping the 'master' as SVN may not be such a bad thing as long as git/hg mirrors also exist. I've been through many hoops over the last year since git was forced on me by other projects ... git needs to start playing better with windows users, as it's current offering does NOT work on sites where other SSH activities are already installed. WHile hg just worked out of the box. The current problem is that neither play well together in the area of sub-repos and this is an area that is still very much work in progress? Manually cloning each individual element does currently work though, and that is how I'm currently remaining sane ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #54449 — Stas Malyshev — 2011-08-08T01:03:08+00:00 URL: https://externals.io/message/54433#54449 · In reply to: #54448 Hi! > > […] > And stick two fingers up at the windows developer base ;) What's the problem with git and windows? I understand there is a good GUI-installable package with all needed and everything works just fine - at least I know people using it without any trouble. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54450 — Kiall Mac Innes — 2011-08-08T01:05:13+00:00 URL: https://externals.io/message/54433#54450 · In reply to: #54448 > Richard Riley wrote: > > > […] > And stick two fingers up at the windows developer base ;) I admit I don't use windows often, but when I do, TortoiseGit has always worked fine for me! > It works, is fast and is rapidly becoming the industry standard. Do not > > […] > Mercurial is just as popular, especially if you want to support windows > projects in parallel with Linux ones ... > TortoiseHg just works on both windows and Linux, integrates nicely into > file managment and plays nicely in Eclipse ... TortoiseGit is windows only > and has compatibility problems. > > Compatibility problems? I assume you mean CRLF -> LF conversion? CRLF -> LF conversion (IIRC) is on by default, unless you choose otherwise during installation. Re: Windows Only - I'm yet to meet a Linux developer who prefers a git GUI over the git CLI ;) Thanks, Kiall --- ## #54451 — Ryan McCue — 2011-08-08T06:57:47+00:00 URL: https://externals.io/message/54433#54451 · In reply to: #54448 Lester Caine wrote: > Richard Riley wrote: > > […] > And stick two fingers up at the windows developer base ;) The CLI works exactly the same as on any other platform, and the graphical tools are fairly good. I've found that they're at least as good as Hg's Windows tools. FWIW, I manage a whole bunch of projects on Git from Windows and I've never had an issue. (Forgot to send this to the list, again.) -- Ryan McCue Later on in the doc, you go into detail about submodules, and CRLF -> LF > support in both Git and Hg. To be fair, submodules don't work exactly the same. Unlike svn:externals, which are linked to a repository, submodules are linked to a repository *and a commit*. That means that if an external is updated, the submodule must be updated, and that change must be committed. (Forgot to send this to the list as well, gah!) -- Ryan McCue > > […] > > What's the problem with git and windows? I understand there is a good > GUI-installable package with all needed and everything works just fine - > at least I know people using it without any trouble. Things have improved somewhat over the last year ... A year ago even the git people would admit that they did not do windows well ... Having to deal with many sites that are 'windows only', but now supplying them Linux boxes with FLAP installations, we make them 'look' like windows boxes for the IT department, so WinSCP and Putty are the order of the day. I've not tried again in the last few months, but last time I installed the msysgit, parts of my SSH process stopped working! If one has a working cygwin install then it should be possible to run it on that, but it appears now that it may have been that which caused some of my own problems since there was a cygwin installation as well. TortoiseGit prefers msysgit installed but it can now be installed using the existing putty installation now. But it is still a windows only option, while the TortoiseHg package works transparently on both. I'll put my hand up that it clashes with Powerdesk on Windows, but I've been lucky up to now that Powerdesk worked at all, and M$ HAS now provided most of its facilities now anyway, and I tend to work from a Linux box anyway so don't really need it. Another method of working cross platform is Eclipse ... Jgit/Egit are making progress, but do not currently support the git subrepo. The hg plugin still has a few problems but on the whole it is now usable, although I do still prefer TortoiseHg via Nautilus for managing updates. I'm not sure on the current situation with git, but Hg does transparently connect with git, which is how I have been working for a long time now. I've moved my own CVS archives over to Hg, and manage the SVN repo's via it as well. SO at the end of the day I'm not that bothered if the consensus is Git. I'm just laying out all the reasons why I never got on with it, many of which still currently apply. I've been using a package called BeyondCompare since long before it was ported to Linux, and this integrates seamlessly into Eclipse and TortoiseHg on both platforms ( and I understand Mac ). Kiall > Re: Windows Only - I'm yet to meet a Linux developer who prefers a git GUI over the git CLI ;) That I think sums up the problem with much of the Linux development process? For years I have been using Eclipse for all my software development. On CVS and SVN archives I can SEE a list of the files that have changes, compare things that I am working on, select what I apply to my local copy. Currently neither git nor hg provide the same level of control, I have to run a separate clone of the 'master' and run BC to view the same details. I know I am in a minority and probably a dinosaur, but I've wasted months trying to get back to a level of productivity that I had last year, and yet still have on projects that have not moved to DVCS! Personally I expect a conversion to DVCS would create more sustainable forks of PHP, perhaps we can maintain our own personal builds ignoring some of the 'unnecessary' stuff added since 5.2 :) This is exactly what is happening on other projects, since one can pull what you want and branch on what you don't. There are no restrictions which is why the management process becomes more important! ( CRLF -> LF conversion is never a problem - just don't use notepad in windows :) ) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #54470 — Ferenc Kovacs — 2011-08-08T14:47:09+00:00 URL: https://externals.io/message/54433#54470 · In reply to: #54433 > Hi Internals, > > Distributed Version Control Systems (DVCS) getting more and more > popular. In fact they have been discussed within the PHP community and > on Internals a few times. It came to my attention that more and more > people like to see PHP move to a DVCS to solve some of the current > issues (and get other ones). > > I was asked to put together a RFC, and so here we are. I've created > an initial draft. It is mostly based on the very good Python PEP-0374. > It compares Git and Mercurial. > >    https://wiki.php.net/rfc/dvcs I've extended the rfc with links with the previous DVCS related discussion from the list. I think it would be good if we could summarize the mentioned ideas and possible problems in the RFC. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54472 — Lester Caine — 2011-08-08T15:07:11+00:00 URL: https://externals.io/message/54433#54472 David Muir wrote: > John Szakmeister, who is a Subversion developer himself, has a good > comparison of svn, hg, bzr and git: > http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ > > Long story short, his company went with git. Makes good reading ... many other comparisons are now getting long in the tooth, and so don't cover the current playing field. Still it looks like 'best of a bad job' rather than 'this wins hands down' and does make a fair comparison of all the current problems, but I think the fact that he has not investigated submodules may actually negate their final results :( This was the main area that I needed to work well, but is still work in progress everywhere? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #54474 — johannes@schlueters.de — 2011-08-08T16:34:57+00:00 URL: https://externals.io/message/54433#54474 · In reply to: #54433 > I was asked to put together a RFC, and so here we are. I've created > an initial draft. It is mostly based on the very good Python PEP-0374. > It compares Git and Mercurial. > > https://wiki.php.net/rfc/dvcs Two comments: * It is said that the preferred way to get a patch from one branch to another is by doing a merge operation in the VCS. Depending on the timing we will most likely end up with two (trunk + 5.4) or, more likely, three (+ 5.3) old branches which are active. Will it be possible to merge between them using the VCS's merge facilities or will we end up cherry-picking there? If this is possible and we continuously merge these branches what are the strategies for preventing specific changes from being merged with the suggested systems (git and hg)? * There is a section "Moving extension from/to core to/from pecl" which seems to describe the "to core from pecl" route, not the other way round. johannes --- ## #54477 — Stas Malyshev — 2011-08-08T17:44:12+00:00 URL: https://externals.io/message/54433#54477 · In reply to: #54474 Hi! > * It is said that the preferred way to get a patch from one branch > to another is by doing a merge operation in the VCS. Depending > on the timing we will most likely end up with two (trunk + 5.4) > or, more likely, three (+ 5.3) old branches which are active. > Will it be possible to merge between them using the VCS's merge > facilities or will we end up cherry-picking there? If this is Depending on the direction of merges, it may work as merge (if you want all changes, i.e. merging up) or as cherry-pick (if you want to merge down). Or you may make a branch from your changes and merge it where you like. What's good with cherry-picking, you can still have full commits so you know who did it and why and can relate to the original source. > possible and we continuously merge these branches what are the > strategies for preventing specific changes from being merged > with the suggested systems (git and hg)? I'd suggest putting changes always in the lowest (oldest) branch first and then merge the branches up to newest. This way we ensure the changes are always in sync. But there can be challenges if there is substantial code change between branches, of course, so sometimes we'd have to cherry-pick or even do something more interactive, git merge is good but not *that* good :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- Next page: https://externals.io/message/54433.md?page=2