On Wed, Dec 1, 2010 at 1:12 AM, Lester Caine <les...@lsces.co.uk> wrote:
> While a little off topic, I feel that it is worth our having a discussion > on project management. Source control, and the like ... > > Current discussion on 'git' highlights the fact that there is no clear > solution to source control. The switch TO SVN was pushed through even though > a few problems with that were then coming to light and now that move is > probably questionable. Projects that had not jumped have now put that on > hold since DVCS is obviously the next step, but none of the current > solutions are ideal and each have as many minus as plus points. > > The real problem that I am finding is that all of these 'systems' work on > the basis that we are handling source code which will then be compiled. > Managing code that is not compiled becomes something of a mess especially > when it would be nice to maintain file versions in those script files, and > running a 'build' process to restore the tidy CVS type headers then makes > things difficult between different DVCS systems. Many core DVCS developers > simply do not understand that there is NOT a final binary distribution? > > Personally I've been getting into something of a mess trying to manage > distributing PHP projects that are version controlled via hg since the only > real way is to install hg on all the target machines ... something which is > not really practical? I do get told to just use rsync to clone the files to > other machines, which is a little impractical when the target machines are > windows or don't have internet access. Fortunatly the CVS original is still > running and back porting is sorting out the distribution problem! > git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) > On top of that managing the release process to combine updates from other > distributed code bases has already created the situation where there are > 'sub-projects' which it is now difficult to integrate back with the original > main project. > this happens all the time in centralized models as well, its just a matter of how often the code is being synchronized. in the case of dvcs, it's likely the peripheral project has not re-based or merged recently / frequently enough. and on top of that, the main project maintainers didn't see enough merit to ever sync up the peripheral project anyway.., so the onus would rest on the developers of the sub-project. not too unlike those good ol svn days at the office.., where someone wouldn't commit for weeks at a time, wouldn't even update very often, and then shocked to find out their code isn't merging completely w/ other new features and production support going on the whole time... if you think about it, having the projects disjoint like that is actually doing favor to the maintainers of the main project. less clutter in the 'official' repo. this is actually impossible to attain in svn, since all branches in svn are tied directly to the central server. > I think we need to start a more integrated discussion on the whole of this > project management process so that we can come up with a usable approach > that works more generally for scripted language projects? Add IDE's like > Eclipse and to some extent Zend framework, and there is another layer of > complexity that further fragments the overall requirements. I've never had a > problem with 'merging' simply because Eclipse/BC handles that and is > currently allowing me to untangle the current niggles! graphical tools are nice, but I think the underpinnings are more important in deciding which is best for use. svn merging has performance bound tightly to the network meaning, if you aren't running the merge on the box actually hosting svn, you'd better be running it from a box physically close or w/ a really high bandwidth connection. of course dvcs lets you run fast merges no matter where you are and let the actual synchronization run after the merge is done, like while you're sleeping say :) also, the svn merge tracking is convoluted, there's a lot to have to know at the user level just to get around it. I've found it a lot easier to trust the merges from git than I ever did svn, and actually ran svn 1.5 for a while with their merge-tracking, which doesn't work correctly without proper user interaction read: --reintegrate .. I'm not a core php dev, but I have dealt w/ a lot of version control, and frankly moving to git from svn was an even better move than cvs to svn, no doubt about it. -nathan
