On Sat, Aug 13, 2011 at 10:33 AM, Lester Caine <les...@lsces.co.uk> wrote:
> I don't have a problem with DVCS, just with projects ploughing into using > git a year ago when it was ( and still is ) not ready for those type of > projects :( > I think you're talking about submodules not being ready - correct me if I'm wrong. We (the Kohana <http://kohanaframework.org> framework and my company) use git submodules very successfully to track isolated parts of the code. Submodules work perfectly. https://github.com/kohana/kohana/blob/3.2%2Fmaster/.gitmodules It was a case of having to work with it at a time when cross platform tools > were not available, and subrepo's did not exist. > I've occasionally used msysgit on windows for Kohana development - cross platform submodules have work perfectly for years! And - I've never heard a complaint from anyone about Git for OS X / Linux not working correctly. > I have a nice working hg setup that works transparently from Linux and > Windows and runs in parallel with my Eclipse development platform. But even > that still has not restored some of the excellent tools that CVS and SVN > provide in Eclipse. MANY of the complaints about CVS and SVN were never a > problem when one used Eclipse. At some point I expect the same facilities to > be restored to Eclipse, but currently TortoiseHg runs in parallel neatly. I > don't have to switch between different tools on the different platforms. In my experience, no GUI VCS tools (for Git/SVN/CVS) have ever measured up to the easy of use, and power of the CLI versions. And honestly - I think choosing a VCS based on the available GUI tools is poor decision making. New and improved GUI's will continue to be released, while the core VCS will remain a relatively stationary target. Again, I'm not explaining things very well ... > What will not work moving forward is a simple dump of the entire SVN > history into a single git repository. What is needed is a managed way to > create a series of subrepos for each of the packages that make up PHP. This has been briefly discussed in the RFC, and I believe the intention is to cover that in detail in a second "Migration RFC". I don't believe anyone is suggesting a simple dump of SVN into Git/Hg. > PECL and PEAR packages then just become extra subrepos which are included > or not in the superproject trunk. The 'single repo' camp point to "feature > branch" as a way of handling that work in a single module without having to > breaking up the repo I don't believe that's what anybody is suggesting (besides - I think - the Drupal document you referenced). I believe people are suggesting that feature/topic branches might be used within a single repo. For example the pecl APC repo might have a "master" (trunk) branch, and a "feature/persistent-opcode-cache" branch. Kiall
