On Wed, Dec 1, 2010 at 9: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 ... > I agree. > > Current discussion on 'git' highlights the fact that there is no clear > solution to source control. Really? There is no silver bullet, we just have to carefully inspect our possibilities, and decide: - do we really need DVCS, do we gain more than we lose? (I think most of the devs support the DVCS) - which DVCS would be a best fit for our specific needs. - what needs to be done for the transitional (I think we can use most of the experience, that we learned from the CVS -> SVN migration) - what are the shortcomings of the selected DVCS, and how could we workaround/fix that > 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. could you explain that in more detail? I mean I can't think a possibility, when a CVS -> SVN could be a bad idea, and didn't really heard bad things about the SVN from the devs (except when they compare it with DVCS). > 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. what projects are you referring? I mean I think every open source project that I follow either use SVN, or already migrated to some DVCS. oh I forgot drupal: they are still using CVS, but the transition to Git is almost done. > > 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? > Uhm, I think you lost me there. We are using version control for all of our "non-compiled" projects, and they working fine for us. Btw: we have build process for building the production version of our codebase (css/js combining, minifying, etc.), so we usually have a final distribution. But you are talking about non-binary stuff, the php core is compiled stuff, so what is the relevance of your sentences for that? Or you are talking about the difficulties of managing the pear/website stuff? > > 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! > we do the following: we have a build machine, we checkout the code there, build the production version, and scp the files to the production server, set the permission, etc. test the staging site, and if everything is ok, then flip the staging to production. but I fail to understand, that how can you use the CVS, where you cant use the hg (the target machines are windows or don't have internet access.) I mean, you can install mercurial on windows, just as you can install SVN, and if the target machine doesn't have internet access, then I fail to see, that why should CVS work when mercurial shouldn't. > > 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. > its not a problem with the tools, it is a problem with the project management: if you support multiple version, then supporting that takes more effort. one of my friend works for a navigation software company, and they have three major version, and HUNDREDS of supported devices, where the manufacturer asked for custom modifications, so they have a really hard time to manage that many branches, and that is a PITA to merge a bugfix everywhere (you have to find out, where is the bug present in the first place, then you can't be sure, that the patch will cleanly apply on every branch) and guess what: last time, when I asked, my friend told me, that they are using SVN. o_O > 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? which project are you referring to? I mean it could be useful to share info and experience about this, but I can't see why should this discussion take place on internals. maybe on webmaster or pear mailing list. > 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! ?? add IDE's? where? I mean you can use any IDE as you like for the development, and we don't use Zend framework here AFAIK. yeah, merging with SVN/CVS sucks, so it is a good idea to use third party stuff to handle the conflicts, but with a DVCS, which has better merging support, than the above mentioned two, that could be unnecessary, but of course, you can use anything you like. Tyrael
