Git and Openoffice.org

N.B. These are very rough notes. See also

Sometime ago I shouted my mouth off at a local Perl Mongers meeting that using custom merge drivers it would be possible to auto merge OpenOffice document from Git, which seemed to interest some people greatly at the time.

However I then backtracked because I failed to take a few things into  account. After some more investigation it turns out it should be possible (with some wrapper scripts and OpenOffice programming) and I  *believe* the following approach stands a chance of working (I’m  hedging my bets here)

1) Create a wrapper script that opens a document, switches on change recording and saves the document, called say changeRecordingOn

2) Create another wrapper script that takes two documents (a and b), runs the OpenOffice Edit->Changes->Merge Document function and saves the result as c, called say ooAutomerge(a,b,c) (NB Base revision is  useless)

3) Create and associate a git custom merge tool for .odt and .ods files that runs ooAutomerge(). Might also need a custom merge driver?

4) Create a pre-commit hook that runs changeRecordingOn for all .odt and .ods files

When running a git-merge and then git-mergetool the OpenOffice GUI should be presented with a list of changes to accept/reject, which is much easier

NB It seems that running the OO merge and saving file c removes the previous change history. This means that if the file is merged again then the user only sees the new history since the last merge (which is what we want)

I doubt I will need this feature for some time so I don’t intend to  take it further at the moment — however if you have a need, these  notes might be useful..

I hope this makes sense? Apologies if I just swallowed two minutes of your day that could have been spend doing something better.

Easy Introduction to Git

I’ve just had an article published by Sitepoint that aims to introduce Git to people who may not have programming experience and are more comfortable using a GUI rather the command Line. “Git: Your New Best Friend“

Top Tip: Upgrade Git on Cygwin

The current version of git installed with Cygwin (1.5.x) has at least one annoying bug so it’s worth building  the latest version (NB I have almost all of Cygwin installed – you may need to install additional development tools and libs):

1. Download and unpack the source code. Pointer here
2. Run ‘./configure –prefix=/usr/local’
3. Run ‘make test’
4. Ignore errors relating to not detecting unwritable repos
5. run ‘make install’
6. run ‘hash -r’
7. Make sure it’s installed with ‘type git’ and ‘git –version’

Update March/09 — I found more detailed instructions

Application deployment and change auditing with git

Updated 6/Feb/09

I’m currently working on on a project to deploy some complex banking systems and we have some somewhere in the region of 40 environments (various testing, production and development instances)

I’ve written some Perl to automatically configure environments using Text::Template. Now I’d like to automate deployment and have some form of change auditing (c.f.AIDE or Tripwire).

So a new project (which I hope will also  have some useful ideas for others):

• Project Outline and User stories
• General Approach using git (other tools could probably be used)
  • Define a staging repo
  • Create a remote branch of each deployment environment
  • Create a repo on each environment
  • Define a custom merge driver that overwrites (old files with new releases)
  • For each release
    • Create a new branch (overkill?)
    • Add new release to new branch
    • tag
  • To deploy
    • Merge (using new driver) onto environment branch
    • tag
    • Push to remote
    • On remote perform git reset --hard HEAD
    • configure
    • add and commit configuration changes
    • on staging pull config changes from remote repo
  • Now use git status etc. on environments to track any changes
  • Staging should have historical record of changes

Thanks to git I’m releasing IP into the wild!

This week I at last did something I’d wanted to do for a long time and  release some of Voga’s intellectual property to the wider world.

I have already made material available either through this blog or via Slideshare. However for a geek it’s obviously better to publish complete projects in an Open Source manner so  they can be freely copied, modified and shared.

For historical reasons this had been inconvenient to do as I used to hold everything in a single Subversion repository. Not only did this contain my potentially open material, but also my customers private data and my business records (yes, I keep my accounts database in a version control repository!). A few months I migrated my Subversion  repo to git, but I still had a single large repo and no time or skill to fix it.

However today I bit the bullet

1. Removed all my possibly public data to another directory structure
2. Tidy up my current repo by removing all the old ‘trunk’ directories — as a solo consultant I was lucky and had never had to branch my projects. Commit my new streamlined repo

Now to work on the the public projects

1. Identify a complete project and make sure it had no proprietary data. This is potentially time consuming
2. Tidy up some of the names
3. Create a new git repo; add the project files; and commit
4. Create a new repo on Github for my project
5. Follow the simple instructions to upload my project to github

To Do

• Update existing references to my projects I can find and update to point to the repo
• Add the correct license files
• Start again for as many projects as possible, please be patient

I’ll still keep presentation copies on Slideshare because that is much more convient for most people.

A big thank you to the git developers and github for making this so easy