# Project Management

- Thread: https://externals.io/message/50756
- Original archive: https://news-web.php.net/php.internals/50756
- Started by Lester Caine on 2010-12-01T08:12:01+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #50756 — Lester Caine — 2010-12-01T08:12:01+00:00

URL: https://externals.io/message/50756#50756

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!

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.

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!

-- 
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

---

## #50758 — Ferenc Kovacs — 2010-12-01T09:03:52+00:00

URL: https://externals.io/message/50756#50758 · In reply to: #50756

> 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

---

## #50759 — Nathan Nobbe — 2010-12-01T09:19:42+00:00

URL: https://externals.io/message/50756#50759 · In reply to: #50756

> 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

---

## #50763 — Lester Caine — 2010-12-01T10:05:38+00:00

URL: https://externals.io/message/50756#50763 · In reply to: #50758

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

---

## #50764 — Lester Caine — 2010-12-01T10:13:46+00:00

URL: https://externals.io/message/50756#50764 · In reply to: #50759

See other post as well

Nathan Nobbe wrote:

> 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 ;)
YES but without any header updates to the files.
Once unzipped you have no idea what version a file is, and that IS causing 
problems in the field. If you can replace the whole package of code, then it may 
not be a problem, but well structured pakcaged systems really need a little help 
when people can THEN mix and match.

 > 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.

I tried to work with git for over a month ... but my live customer base is on 
windows and git is simply not compatible ... hg is working nicely for me even 
talking into github, but managing several packages ( both binary and script ) 
that integrate into a single is something neither git or hg currently handle 
fully. One ends up switching between tools to keep things in sync, which is easy 
on Linux, but a pain on Windows.

-- 
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

---

## #50768 — Dave Ingram — 2010-12-01T11:09:20+00:00

URL: https://externals.io/message/50756#50768 · In reply to: #50764

> See other post as well
>
> Nathan Nobbe wrote:
>
> > […]
> YES but without any header updates to the files.
> Once unzipped you have no idea what version a file is, and that IS
> causing problems in the field. If you can replace the whole package of
> code, then it may not be a problem, but well structured pakcaged
> systems really need a little help when people can THEN mix and match.
I can't speak for other DVCS systems, but you could use a git "smudge
filter" to add any sort of source-control headers if you really, really
want to:
http://chillibear.org/2010/04/git-and-cvs-like-keyword-expansion-idents.html


D

---

## #50771 — Lester Caine — 2010-12-01T12:21:46+00:00

URL: https://externals.io/message/50756#50771 · In reply to: #50768

Dave Ingram wrote:
> > […]
> I can't speak for other DVCS systems, but you could use a git "smudge
> filter" to add any sort of source-control headers if you really, really
> want to:
> http://chillibear.org/2010/04/git-and-cvs-like-keyword-expansion-idents.html

Now that is one I have not seen, but outlines the reasons for wanting it nicely. 
It does highlight another part of this jigsaw ... need ruby running as well as 
python and php ;)

I know that we are not going to get a nice clean PHP solution, but the spread of 
languages needed just seems to be growing just to add DVCS?

-- 
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

---

## #50780 — Dave Ingram — 2010-12-01T13:59:42+00:00

URL: https://externals.io/message/50756#50780 · In reply to: #50771

> Dave Ingram wrote:
> > […]
>
> Now that is one I have not seen, but outlines the reasons for wanting
> it nicely. It does highlight another part of this jigsaw ... need ruby
> running as well as python and php ;)
You don't have to write the filter in Ruby -- that was just his choice.
You could use shellscript, PHP, or even C if you really wanted.


D