Entries from March 2006 ↓

A personal foible perhaps but I do find Ruby’s regular expression syntax remains in my brain much more easily than the Python equivalent.

Maybe it’s the Ruby inheritance from Perl that makes the difference. For simple scripts I can just write standard regexps without any recourse to documentation and they just work! For example:

some_var = "prefix interesting_match some suffix"
if some_var =~ /prefix (\w+) some suffix/
  interesting_bit = $1
  print "Match found: ", interesting_bit, "\n"
end

In order to do the same in Python I find myself faffing around with the documentation (using ActiveState Python it’s great to have a proper help file, but I would really like more links between the class reference and real examples of usage to help me out) and trying to remember if I want re.search or re.match and how do I get a match group and use it, etc. I have sundry Python scripts floating around that I open up and copy relevant examples from, but it does rather take time.

import re
some_var = "prefix interesting_match some suffix"
pat = re.compile('prefix (\w+) some suffix')
m = pat.match(some_var)
if m:
    print 'Match found: ', m.groups(0)[0]

Now I have to admit that it’s not a huge deal in terms of the resulting code, but it took me 5-10 minutes just now to code and debug the Python version as opposed to the Ruby version which I typed in and which worked first time.

The net result is that I am noticeably  more productive in Ruby for those little scripts that make life easier, or when I am under strict time pressure. Now this is not to say that I don’t like Python, or indeed that when I have a little more time I don’t get use it and enjoy it. Having done some reasonably significant work in Python, e.g. rework P4DTI for PVCS (now Serena) Tracker I feel reasonably qualified to comment.

I also took the time to get sufficiently proficient in Python extensions to enhance and maintain P4Python. Mind you I now feel somewhat humbled by the most recent efforts at a Perforce integration (PyPerforce) – shows a depth of Python extensions knowledge before which I can only bow in admiration! (Minor aside – Ruby extensions are much easier to write than Python ones due mainly to the different garbage collection models).

Finishing up, I am definitely Perl-averse these days. There are a few Perl scripts that I maintain and can’t be bothered, or can’t find a convincing “business” case to rewrite, but anything new is Ruby or Python.

Tools Fair on 15th June – Cradle to Grave Support

As Chair of the BCS CMSG now (Shirley Lacy passed on the baton in November but fortunately for me remains in the background as vice chair), I have been feeling a little concerned about responsibility for the BCS CMSG Tools Fair – Cradle to Grave Support on 15th June. I am relieved that things are looking good now with good selection of sponsors supporting us:

Some newish names to me not being hugely up on the service management/ITIL side, but change, configuration and release management are a major focus in that field so look forward to meeting and hearing about them and the issues and solutions available.

A couple of big names missing on the software side which is a shame. A couple of organisations undergoing a re-org and thus no marketing budget to spend (well not now anyway). IBM/Rational aren’t there because I can’t find anyone to talk to that would appear to be able to make a decision. We used to have good relations with Rational but since they were acquired by IBM can’t get anything out of them (I wonder what their responsiveness is if I were looking for support or trying to buy a produce?!). If anyone knows who to contact in the UK on marketing/events I’d be grateful for a heads up. The other one I have failed to get to anyone appropriate is Microsoft – would be good to find out about Team System etc, but all enquiries get passed from pillar to post and a deafening silence is the result.

Show me the money – identifying the value of Configuration Management

The other event we have on the 27th April is an evening event which is a relatively new departure for us. This will be at London South Bank University in their conference centre (which we have used before), and is in the form of a workshop lead by David Cuthbertson. This is going to focus on selling the benefits of CM and we hope will be a useful way of bringing together both new and more experienced people in the field to share experiences. Details to go up on the web site very shortly! David has spoken several times in the past and always gotten excellent reviews. He is also skilled at running workshops and getting contributions from others present. Should be a great evening. Apologies to those not close enough to London who want to attend, but we are looking at running (in particular evening) events elsewhere in the country – get in touch if you have any ideas.

Updated: 2005-11-29 – see link to scripts.
Updated: 2006-03-16 – some clarifications and link to Miki Tebeka’s scripts

A common branching pattern is to have mainline and then task branches where work is done and then “published” by merging to the mainline as shown in Figure 3 of the article Building for Success.

In perforce the “publish” and the “catchup” are both performed by using the integrate command, typically with a branch spec. For example, you might have a branch spec

Branch:	task/fred
View:
	//depot/main/... //depot/task/fred/...

The key thing is that Fred should “catchup” before doing the “publish”. This is so that the more risky merging is done in his task branch and not in the mainline. When doing the merge Fred should be bringing all changes by other people in the project into his branch and with the publish he should just be able to copy his code into the mainline.

There are several ways to achieve this:

• Education – tell Fred what to do and rely on him doing it – so what happens if he doesn’t – can you “persuade” him not to?!
• Don’t give Fred write access to the mainline (e.g. via protections or a trigger), and instead have the integration team do it. The problem then being that the integration team may not know the code as well as Fred and are perhaps more likely to make a mistake.

The basic way of detecting in Perforce whether a catchup has been done is to do a preview integrate from main to task/fred and check that nothing needs to be done, so check for no results from:

p4 integrate -n -b task/fred

If the above produces no results then proceed to do the publish:

p4 integrate -r -b task/fred
p4 resolve -as

The key step is that the “resolve -as” (safe automatic merge), resolves as many files as it can. It looks to see if their are only “theirs” (source) diff chunks or “yours” (target) diff chunks and will select the theirs or yours file appropriately. (Note that “theirs” and “both” or “yours” and “both” are also processed in the same way). The key point is that if there are “theirs” and “yours” (or “conflict”) diff chunks, then safe automatic resolve will not process that file.

Of course having done the automatic resolve and with the changed files sitting in our client workspace it is usually a good idea to do things like a build and smoke test – there’s not a whole heap of trust otherwise…

Thus, in our script we can check for anything not safely resolved automatically (resolve -n shows what still needs to be resolved).

p4 integrate -r -b task/fred
p4 resolve -as
p4 resolve -n
if any results from above command then exit with error

build
if any problems then exit with error

run smoke tests
if any problems then exit with error

If no errors at this point we are ready to submit.

There are some extra wrinkles to this:

• the “resolve -as” may validly not work if you have done a merge with edit during the catchup (”edit from” in the terminology from p4 integrated). You need to detect such situations and do a “resolve -at” to copy them over.
• as soon as one person has done a publish then all other branches will require to do a catchup to pull it in – this means publishes are going to become serial
• there is a window during which the publish is being performed when someone else might sneak in and do a publish thus meaning you need to do a catchup – consider a simple “locking” strategy to prevent this.

Note that the build and smoke test steps need to take an appropriate amount of time. If it takes hours to do them then the process is unlikely to work. Thus a few minutes or tens of minutes is likely to be the limit – this may mean cutting down on the number of tests that are executed – but that is usually OK. Apply judgement!

Although at the last point you might think it would be a brave person to do the submit automatically in a script! It’s probably a good idea to do things like run diffs and give a visual once over before finally checking in, but it should be a pretty easy decision at this point.

In terms of automating the above, I can heartily recommend the various scripting languages with built-in calls to the Perforce API: Ruby, Python and Perl. Getting the results of a command is easy, and exceptions allow you to make error handling pretty easy as well.

Very brief examples of scripts designed to perform the above check in Python and Ruby are now available online. Note they are designed to be run from Custom Tools menu in p4v/p4win. Please note that Miki Tebeka has kindly published more production quality script implementations in python including a GUI front end. He also includes an example of an installer to automate installation of tools for p4win and p4v – check them out. Thanks Miki!

p.s. The above works for any codeline for which you have responsibility for accepting changes – it doesn’t have to be a mainline – it can be a subsidiary integration line with third parties contributing, or team members “proposing” changes. You could automate the script and put it on an intranet page – let people try it out, and if successful then have changelists auto-checked in.