NYCPHP Meetup

[Paul A Houle]

Tom Melendez wrote:
> I can strongly recommend UnFuddle:
>
> http://unfuddle.com/
>   
    We use this at work as a bug tracking/project management system and 
it's pretty good.  I'm a tough customer for this sort of thing and can 
find many complaints,  but it's better than any of the other systems 
I've seen that target it's market segment.  (I see Basecamp as an 
excellent product that's a bit downmarket.)

    I haven't used the VC service from unfuddle however since we use 
Visual Source Safe here. VSS has it's problems,  but the integration w/ 
Visual Studio is good and I've managed to point-and-click my way through 
hairy situations that I'd find intimidating w/ CVS or SVN.  (And that's 
talking as someone who's gotten in pretty deep with CVS.)

    Personally I think SVN is a scam.  It deals with some of the 
superficial problems with CVS (for instance,  being tied to Unix 
accounts and the difficulty of moving files.)  It addresses some of the 
issues of working in Java,  where renaming classes means you need to 
rename files,  but it doesn't address the deeper issues in CVS and it 
takes a big step back in the branching department by offering only smoke 
and mirrors for branching support.  (The branching model in CVS is quite 
appropriate for shops that have a main line of development and spin off 
branches to customers or to production servers.)

    These days I've fallen in love with git.  As somebody else said,  
git's particularly good for managing code that comes from an open source 
project or a vendor:  you can replace the files in a distribution and 
"git add ." does the right thing.

-------------

    As for the problem of configuring multiple instances,  +1 to the 
suggestion of having a single configuration file that sits outside 
version control.  This isn't the most advanced way to do it,  but it's a 
simple mechanism that's a good alternative to the 'status quo' of having 
no clean mechanism for separating what varies from what stays the same.

    I particularly get frustrated with hard-coded paths that many 
products keep inside of databases.  One of the reasons why wordpress 
operators are slow to upgrade to fix the security problems that seem to 
be discovered every week is that wordpress keeps hard-coded urls inside 
the database:  it's a major production to make a copy of

yourblog.com

that lives at

test.yourblog.com

the system will keep trying to redirect you to "yourblog.com;"  If I 
could do this,  I'd have a lot more faith that upgrading wordpress won't 
break my system.  I hate to admit it,  but I regularly upgrade wordpress 
directly on production systems because there isn't an officially 
supported way to do anything else.

It's a totally different story with the systems I build,  where I can 
make systems for test and development purposes very quickly.  I'm moving 
away from Wordpress for my non-blog sites that use it.