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.
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“
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):
After some information from jim mcnamara I developed a script to compare two directory trees. I needed something that worked on Solaris 8 so it uses basic UNIX tools (and dircmp was not very useful). If you are using a more modern system then try this
#!/bin/ksh
# Compare 2 directories for differences (e.g. current release and new release)
CURRENT=$1 ; shift
NEW=$1; shift
CURRENTDIFFFILE=/tmp/$(echo $CURRENT | sed -e 's/[/.][/.]*/_/g')
NEWDIFFFILE=/tmp/$(echo $NEW | sed -e 's/[/.][/.]*/_/g')
# File pattens not to be included in compare
cat << 'EOF' > /tmp/patternFile
^.git/
^.*\.log
^logs/.*
^.*\.tmp
^.*\.err
EOF
for i in $CURRENT $NEW ; do
cd $i
# cut removed ./ that find puts at start of path name
find . -type f -print |cut -b3- |egrep -v -f /tmp/patternFile | sort > /tmp/$(echo $i | sed -e 's/[/.][/.]*/_/g')
cd -
done
echo New files
comm -13 $CURRENTDIFFFILE $NEWDIFFFILE
echo
echo Deleted files
comm -23 $CURRENTDIFFFILE $NEWDIFFFILE
echo
echo files that are different
# xargs has limitations so must pipe into a second shell
comm -12 $CURRENTDIFFFILE $NEWDIFFFILE | xargs -i echo cmp -s \"$CURRENT/{}\" \"$NEW/{}\" \|\| echo {} changed | sh
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):
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
Removed all my possibly public data to another directory structure
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
Identify a complete project and make sure it had no proprietary data. This is potentially time consuming
Tidy up some of the names
Create a new git repo; add the project files; and commit
Once thing that often confuses Dimensions CM administrators and users is how to set up and use an effective Design Part Structure (DPS). There is no ‘once size fits all’ answer but I hope the following comments will help guide people to a more comfortable structure. Read the rest of this entry »
The analysts and tools vendors have been talking about Application Lifecycle Management (ALM) for many years now and I think they have (of course) been somewhat self serving in their definitions. ALM seems to include whatever product category they have in the current price list and then promising their integrations’ would be managements answer to cost and governance issues. I hope to say more about integrations in the future, but I’d like to look at the scope of ALM for now.
If you ask vendors and consultants (including me) about ALM scope you’ll get answers such:
Requirements engineering
Software Configuration management
Dependency Tracking
Change control and work tracking
Test management
Software development tools and process
Software building and processes
Deployment
Process Governance
Depending on the vendor you might even get more traditional: Project and Program Management; Project and Application Portfolio Management/Analysis; and Service Management activities thrown in as well.
The usual sales pitch is that everything is managed via a common tooling and provides a common repository. The major, and often single, selling point of this approach is improved governance and business oversight of the SDLC.
However I think it’s useful and important to look at the definition of ALM from a customers perspective rather than as analysts or vendors.
It seems that a more pragmatic approach is to describe ALM as the methods, processes and tools that support the management of change for software systems — with particular, but not exclusive, emphasise on the SDLC. In this context it does not matter if we are using Agile or Waterfall approaches, we chose the best tools and processes for our particular situation. This of course implies that in eighteen months time we may need to re-tool.
Furthermore the methods tools and processes of project management (PM) are much more mature and there is no real need to include them in this evolving segment — they have their own. Obviously PM will have an influence and impact on ALM and we need to design our ALM approach to dovetail with it. I realise that most vendors will not agree with this.
I have come to the conclusion in order to ’sell’ ALM into the teams that will use it we need to ensure, front and centre, that ALM provides a ‘better/faster/more’ improvement in daily productivity. That should be the primary focus of what is delivered.
Governance, audit etc should be secondary attributes and natural site affects of using ALM (important though they are of course and usually the primary sales message).
So at a practical level we need to be able to provide teams and their specialists with the best tools they need to do their job. Additionally we need to provide a supporting layer of data flows, events and data repositories to
Assist teams with traceability
Provide the tracking and management visibility to effectively steer the ship
So the point of this post is to plead with vendors to stop selling a one size fits all tool suite with deep integrations and start enabling shallow API and effective integrations to allow a truly best of breed approach for customers software purchases. It’s a shame that ALF project is shuting down.
This is a presentation I gave a few years ago to the Linux Users of Victoria (Australia) on SCM. It’s brief and simplistic, but hopefully will server as a jumping off point if SCM is confusing you. As always feedback is welcome.
If you are a Serena Dimensions administrator you might find this of some use, otherwise I’m afraid it’s ‘move along, nothing to see here…’ Read the rest of this entry »
This is not exactly rocket science, but does show up an important principle of Version Control (see below).
Let’s take a practical example that happened to me today:
I have a document under source code control (git in this case) and I am editing it using OpenOffice. Naturally it is an ISO standard Open Document format file and so it’s file name is something like GreatDocument.odt. However I now need to distribute this document to a wider audience for comment and feedback; and of course everyone else uses MS Word 2003. The practical solution is to change the document format to .doc. However I still want to keep the full history of the item — the fact that it changed from ODT to .DOC format is actually not significant in the grand scheme of things. For git the following commands need to be performed:
Using OpenOffice save the file GreatDocument.odt in MS Word format using the Save As function. This should create a second file called GreatDocument.doc
Rename GreatDocument.doc to something else, e.g. GreatDocument.word
issue a git-mv command to show that the file is changing. e.g. git-mv GreatDocument.odt GreatDocument.doc
Overwrite the .doc (which is actually in ODT format of course) with the true Word file. E.g. mv GreatDocument.word GreatDocument.doc
Now commit your changes to the repo. git-commit -a
Of course you will need to modify this to suite your platform and version control tool. But the principle should hold in the majarity of cases.
And what is the important Version Control principle involved?
The physical format of a controlled Item is less important that its history and logical purpose
SD is a peer to peer bug tracker which can sync to itself, RT or Hiveminder. You can extend SD to sync to other bug tracking tools by writing simple adaptors. If you’d like to help make SD work better with your bug tracker, drop us a line.
With all the cool kids (and me) moving to distributed version control tools it’s been obvious that that there is a gap because our bug databases are centralised. Why is that a problem? Because code changes should always be booked against either a user story or a bug report. The link needs to be hard! i.e. I should be at least warned when I commit code without a ticket and when I look at a completed ticket I should be able to find the corresponding code. When you are committing code changes at 11,000 meters above sea level that can be a bit hard.
The only thing I know about SD is what I’ve read above, but already I want it!
[update 25/July -- the SD website now works so go for it!]
Many Dimensions consultants, trainers and administrators have their own personal recipe on setting up a standalone Dimensions CM environment. Here is my latest: Read the rest of this entry »
Document the process in some fashion. A process that is not documented can be very hard to talk about, agree and improve.
Following on from a brief twitter conversation with Kate this morning here is a simplistic example of how I currently document processes. The motivation for this approach is:
Simple to edit and and maintain
I hope simple to read and understand (even if you are not technical)
Can be used as the basis for detailed work instructions
Currently I am feeling very cut off as the latop is at the menders having it’s drive electronics diagnosed. However as soon as it gets back I shall be off to the land of Git after re-reading Sam’s updated (and excellent) git-svn tutorial. Git is designed for distributed use, is fast and I’m assured very flexible…
Of course I may not wait that long as I’m being tempted to purchase an HP 2133, despite it having a Broadcomm wireless adaptor and all the bloody aggro that entails.
In a similar fashion to a previous post about gvim you can use TextWrangler as your SVN or SVN log message editor by setting $SVN_EDITOR to the value of "/usr/bin/edit -w" and install the TextWrangler command line tools. I’m guessing that something similar would also work for BBEdit as well.
Mac OS/X 10.5 (a.k.a Leopard) sports a new backup program called TimeMachine. However I am fast coming to the conclusion that it’s pretty useless and you are better off with a backup script.
The problem seems to be the user interface, visiually attractive but it has no way to easily identify files and changes as the presentation is time base. i.e. it is possible to go back to a certain time, but no look at when a file (or group of files) has changed.
Usually when I want to restore something I want to locate an object and then perhaps look at it’s history. No the other way around.
The article explains it well and I have to say that it would make a very effective first test for team and process maturity. Try and see how well your team does…
I would be interested to know if he uses a ticket tracking system as part of the process to replace ClearQuest– but I can’t leave comments to ask him .
.