Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50763
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.127 cause and error)
Message-ID: <4CF61DF2.7030306@lsces.co.uk>
Date: Wed, 01 Dec 2010 10:05:38 +0000
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.14) Gecko/20101013 SUSE/2.0.9-2.1 SeaMonkey/2.0.9
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <4CF60351.4030101@lsces.co.uk> <AANLkTinrAVFb2FEH9Nd1G5mGv6peeEEoq=0t-s-3sb8m@mail.gmail.com>
In-Reply-To: <AANLkTinrAVFb2FEH9Nd1G5mGv6peeEEoq=0t-s-3sb8m@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Project Management
From: lester@lsces.co.uk (Lester Caine)

Ferenc Kovacs wrote:
> On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine <lester@lsces.co.uk
> <mailto:lester@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

Yep ... those are the basic questions ... git, hg, brz or 'another'
Since we do have SVN now does the MASTER source need to change. We hould be able 
to do our own thing locally on your prefered DVCS if that is your choice, but 
mirroring from SVN ... if the problem of git-svn and the like can be addressed!

>     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).

There were a few comments on the 'git anybody' thread, but cloaning CVS to a 
DVCS seems to be less hassle than mirroring an SVN master?

>     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.

Drupal was my first thought and I'm fighting the mess on bitweaver at the 
moment. Other projects I've been half playing with seem to be in the same state 
of flux ...

>     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?

Exactly ... while the base discussion here is for the compiled modules, a 
decision there should not be at the expense of being able to support the 
website/pear stuff as well.

>     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.

Again this is more website than binary files. And not just a PHP problem, but 
I've had great trouble with fixing Python code in hg and syncing those changes 
with submissions from others. The CVS header is an ideal way to be able to check 
the version of a file in use. SVN can do the same thing, but the tool guys don't 
seem to understand THAT problem as yet?

>     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

Fine ... Do they have any plans to change to DVCS ;) Probably not ...

>     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.

As already said ... PLEASE do not force something on us which is totally alien 
to the whole process ....

>     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.

The point I am trying to make here is that *I* have never had a problem with 
merging simply because my third party tools have always provided the facility, 
and CVS or SVN both simply work, while currently NONE of the DVCS systems 
properly integrate with Eclipse. Also a lot of the discussion on 'traits' and 
'hinting' also seem unnecessary when PHPEclipse provides all the cross linking I 
need. NOT being able to access DVCS from Eclipse is the main part of my own 
problems!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php