Re: [RFC] Choosing a distributed version control systemfor PHP (or not). Call for Participation.
| From: | Justin Rovang | Date: | Mon, 15 Aug 2011 20:33:13 +0000 |
| Subject: | Re: [RFC] Choosing a distributed version control systemfor PHP (or not). Call for Participation. | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-54628@lists.php.net to get a copy of this message | ||
On 8/14/2011 3:42 PM, Lester Caine wrote:
Gwynne Raskind wrote:If one is made from scratch, I propose calling it "Phit"! Submodule support in both still leaves something to be desired. Instead of divergence, a large project like PHP could swing enough influence and developer base to benefit development for one or both of the DVCS's. (Probably a pipe dream :o )it, people might start converting from PHP;) Although phphgadmin isThe only real disadvantage to hg is having to handle python code to maintainto improving the php interface support and could be a good start ata startPHP managed interface to a PHP repo?a fullyI'm starting to think we should take a cue from Linus and just do as we did with bugsweb, newsweb, and so forth: Build our own (Hg/Git-compatible) DVCS from scratch! (I'm joking... mostly.)It's not such a silly idea ... In reality both git and hg get modified to provide custom facilities, so creating at least a clean php based front end to a DVCS engine makes perfect sense. Especially if it links in with bugsweb and perhaps highlights hotfix or other patch information directly in the code base? Commits tag the relevant bug report automatically? And patch accepts both hg and git inputs for those without karma, or would commit for those with? I have been more than happy with hg working into git repos I did simply assume that there would be an extension for git to handle hg in the same way, but it would appear not? As far as I can tell from the hggit extension, mirroring the git information is not particularly difficult, so a 'hybrid' that could provide both hg.php.net and git.php.net views seems practical, and commits need to be managed via karma, so processing that should not be difficult? But the problem area I still see is the handling of submodule/subrepo commits where they cross several submodules ... that was an area where custom scripts used to exist for a couple of the projects I work with and I think THIS may be an area where a scratch built interface may be a possible option.