Project Management View as Markdown

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

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