On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine <les...@lsces.co.uk> wrote:
> Drak wrote: > >> At the current time I think that PHP would need to restructure how >> it is packaged up to provide a single repo in both HG or GIT. >> Keeping SVN ( I'd still prefer CVS here it works BETTER as a master >> for DVCS! ) as the master from which we CAN currently sync using HG >> or GIT is the best of a bad job currently. Unless some knows better >> >> I know what you mean. There are solutions like submodules in GIT but it >> does require some small restructuring usually. By the way, TortoiseGIT >> is now quite excellent for Windows GUI. A new version 1.7.0 is just >> about to be released too. I'm a bit biased against GIT but overall, GIT >> is getting way more traction than Hg and github.com <http://github.com> >> >> excels in features compared to anything else. >> > When TortoiseGIT runs in Linux as well - they will have caught up! > TortoiseHg works transparently in both and on Mac I believe. My customer > base is mainly windows biased while I've been running on Linux here for some > years now. I need both platforms to do the same thing - which Eclipse has > provided for several years, but the DVCS camps still need to address. > Windows GIT is something different from Linux GIT at the moment - which is > probably all that is putting me off it. Actually when I was forced to used > GIT the windows side simply did not work at all, so I HAD to use hggit to > get anything! > > > From what I have seen also, IDE integration with GIT is starting to >> catchup both in NetBeans and Eclipse - and already way ahead of the pack >> is phpStorm for VCS integration, but it's not free. >> > hggit + Mercurial Eclipse + Eclipse means I could not care less what the > target is EXCEPT that one can't write a project that is JUST the set of > sub-modules that you want to pull together. IDEALLY - both GIT and HG would > just pull stuff from which ever is providing a particular library? So say > Smarty could be on one while ADOdb is on the other ... The core PHP code > does not need to be so distributed, but being able to pull PECL modules from > a number of sources to add to a core clone of the code could be useful? > > Perhaps, it would depend how teams are structured, but even it was a single repository for everything I think stuff would work fine. My opinion is that the reason behind sub-repositories is to include code from vendors, not that much to modularize development of a single big project, why?, because of the distributed nature of a DVCS: imagine that there is a PECL team, and that team makes a fork of the main PHP repository, and they focus on that "fork" (every separate repository can be regarded as a fork) and they handle all their work integration, and then someone (after an ammount of work is done) pulls back from the main repo (the one where last integrations are agreed to be added, "central" if you must call it that) to ensure everything still runs ok, and then ask to the final integrator to pull and merge their work: done. Oh, and HG supports svn and git as subrepos now. Regards, David
