Re: Project Management
| From: | Lester Caine | Date: | Wed, 01 Dec 2010 10:05:38 +0000 |
| Subject: | Re: Project Management | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-50763@lists.php.net to get a copy of this message | ||
Ferenc Kovacs wrote:
On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine <lester@lsces.co.uk <mailto:lester@lsces.co.uk>> wrote: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!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.