CiviCRM Community Forums (archive)

Hi there,

I started development with 2.1.2.  We're now at 2.1.4 and 2.2 around the corner.  I've inevitably had to 'hack the core' a few times and kept all my customisations in a separate directory.  I encountered an issue in my 2.1.2 installation (http://issues.civicrm.org/jira/browse/CRM-3866) and it has made me think about the implications of customising the code on upgrading.

I once did a diff between 2.1.1 and 2.1.2 and it makes me think that going from 2.1.2 to 2.1.4 isn't going to be completely trivial.  I imagine that most of the files I modified in 2.2 will have changed a lot by the 2.4.  I'm not massively experienced with projects that have quick release cycles or with doing clever stuff with diff, patch and svn so wanted to ask if the following a sensible approach to upgrade from 2.1.2 to 2.1.4, and request a bit more detail / help.

1) Do a diff between my 2.1.2 customisations and the original 2.1.2.
2) Follow the upgrade to a new revision instructions at http://wiki.civicrm.org/confluence/display/CRMDOC/Upgrade+to+a+New+Revision+-+Drupal
3) Make a new custom code directory and then use patch with some cool options to create a load of files in the new custom code directory that are based on 2.1.4 but contain my changes?

Also, what about when I upgrade this site to 2.2?  Is it the same thing but a bit more involved?  Any insights and tips on best practice for development environments etc. from experienced types very appreciated.

Cheers,
Michael

Hi there,

Looks like proper use of SVN eases the pain a lot.  At the moment I use diff on Eclipse on Windows - it's ok but requires a fair amount of intervention.

I think I'll start a related post / wiki page on setting up a development environment for civicrm incorperating best practice, etc. and put some of this info in there.

The way we do things at DharmaTech has been working well.  Our Subversion repository has a directory per major release, and each major release directory has vendor, trunk and branches subdirectories.  When a new major release comes out we put it in rrr/vendor/ then copy that into rrr/branches/devl/ and hack on the devl branch only.  That way it is always easy to see exactly what has been hacked by diffing vendor/ with branches/devl/ .  When the hacks seem stable we copy branches/devl/ to trunk/ and we roll that out to our clients.  You can see how this is done at our repository.

When a new bugfix release comes out we merge it into rrr/vendor/ then merge from there into rrr/branches/devl/ and repeat the verification cycle.  Thus vendor/ always contains only code from the download, never local changes.

Some of our hacks merge automatically into new releases, while other hacks require some rework.  Rework is a lot easier if you can diff the original and hacked code and the changes made in the new release.

-- Walt

Looks like proper use of SVN eases the pain a lot.  At the moment I use diff on Eclipse on Windows - it's ok but requires a fair amount of intervention.

SVN is highly recommended. Tortoise SVN is a fine Windows GUI and works well. The easiest way to setup an SVN repository, IMO, is to hire one out. I use a service for $4 a month (can't ask for better than that) and the SVN works perfectly. They also provide Trac, which I use.

I don't want to advertise for them here, but if you are interested, contact me offline and I will send you a link to them--I have no affiliation whatsoever, just a satisfied customer.