Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Project Management [RSS Feed]

#1 Dec. 1, 2010 09:05:29

Ferenc K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine <les***@*sces.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

Offline

#2 Dec. 1, 2010 09:20:35

Nathan N.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


On Wed, Dec 1, 2010 at 1:12 AM, Lester Caine <les***@*sces.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 ...
>
> 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

Offline

#3 Dec. 1, 2010 10:16:33

Lester C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


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 causingproblems in the field. If you can replace the whole package of code, then it maynot be a problem, but well structured pakcaged systems really need a little helpwhen people can THEN mix and match.> also, the svn merge tracking is convoluted, there's a lot to have toknow 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 onwindows and git is simply not compatible ... hg is working nicely for me eventalking into github, but managing several packages ( both binary and script )that integrate into a single is something neither git or hg currently handlefully. One ends up switching between tools to keep things in sync, which is easyon Linux, but a pain on Windows.--
Lester Caine - G8HFL
-----------------------------
Contact -http://lsces.co.uk/wiki/?page=contactL.S.Caine Electronic Services -http://lsces.co.ukEnquirySolve -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

Offline

#4 Dec. 1, 2010 10:48:51

Lester C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


Ferenc Kovacs wrote:On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine <les***@*sces.co.uk
<mailto:les***@*sces.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 thatYep ... 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 ableto do our own thing locally on your prefered DVCS if that is your choice, butmirroring 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 aDVCS 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 themoment. Other projects I've been half playing with seem to be in the same stateof 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, adecision there should not be at the expense of being able to support thewebsite/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, butI've had great trouble with fixing Python code in hg and syncing those changeswith submissions from others. The CVS header is an ideal way to be able to checkthe version of a file in use. SVN can do the same thing, but the tool guys don'tseem 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_OFine ... 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 aliento 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 withmerging simply because my third party tools have always provided the facility,and CVS or SVN both simply work, while currently NONE of the DVCS systemsproperly integrate with Eclipse. Also a lot of the discussion on 'traits' and'hinting' also seem unnecessary when PHPEclipse provides all the cross linking Ineed. NOT being able to access DVCS from Eclipse is the main part of my ownproblems!--
Lester Caine - G8HFL
-----------------------------
Contact -http://lsces.co.uk/wiki/?page=contactL.S.Caine Electronic Services -http://lsces.co.ukEnquirySolve -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

Offline

#5 Dec. 1, 2010 11:10:11

Dave I.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


On 01/12/10 10:13, Lester Caine wrote:
> 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.
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.htmlD

Offline

#6 Dec. 1, 2010 12:25:35

Lester C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


Dave Ingram 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.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.htmlNow 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 aspython and php ;)I know that we are not going to get a nice clean PHP solution, but the spread oflanguages needed just seems to be growing just to add DVCS?--
Lester Caine - G8HFL
-----------------------------
Contact -http://lsces.co.uk/wiki/?page=contactL.S.Caine Electronic Services -http://lsces.co.ukEnquirySolve -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

Offline

#7 Dec. 1, 2010 14:01:51

Dave I.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Project Management


On 12/01/10 12:21, Lester Caine wrote:
> Dave Ingram 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.
>> 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 ;)
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Project Management [RSS Feed]

Board footer

Moderator control

Enjoy the 13th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support