Ferenc Kovacs wrote:
On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine <les...@lsces.co.uk
<mailto: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
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
