The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Friday, August 15, 2014

Workflow is (almost) expressable as a Perforce branch mapping

Recently I have been working on a painful manual merge of some diverged, forked, documents.  Painful because no automatic merge tools in Framemaker - I use compare documents, and then manually investigate diffs.  (I remember doing this to the BSD 4.x kernel at Gould Real Time UNIX in the 1980s... gah!!!)

Key is developing a workflow: I assembled the files to work on in XXX.merge-needed.

I do my stuff, and then move the files to XXX.merge-pending.

In XXX.merge-pending, I wait to get approval, and then distribute stuff from there to unfortunately still replicated and forked source/destinatiions, call them XXX.fork1 and XXX.fork2.  I also move my work item files to XXX.merge-done, once the distribution is done.

Editing of stuff in XXX.merge-needed is manual, as is moving to XXX.merge-opending.

But thereafter, it can be automated:  when I have a batch of stuff in XXX.merge pending I can do

     p4 cp XXX.merge-pending XXX.fork1

     p4 cp XXX.merge-pending XXX.fork2

     p4 mv XXX.merge-pending XXX.merge-done

Yes: I could be tracking the workflow in Perforce - even though IT discourages that.

The copy-copy-move script is *almost* a Perforce branch-mapping:

     XXX.merge-pending/... --cp--> XXX.fork1/...

     XXX.merge-pending/... --cp--> XXX.fork2/...

     XXX.merge-pending/... --mv--> XXX.merge-done/...

Which would be nice - I could save it as a branch mapping, and reuse.

Almost but not quite - as far as I can tell, Perforce branch mappings really amount to "p4 cp", copies, buit do not have the ability to do moves.

Q: what is the difference between a script, copy-copy-move, and a branch mapping (extended to also do moves)?

The branch mapping is conceptually used to create a script of commands - but it also does various integrity checks.  Plus it is transactional (at least I think that Perforce is transactional, ACID) - all succeed or none does.

Integrity checks, like ensuring files overwritten are not locked.  It might be nice if it could be better - in this case ensuring that the destination files have not been changed since their common ancestor in the workflow loop.  Which is basically a very simple merge or integration algorithm.

It is nice to have that sort of integrity wrapper around a script.  It is a pain to code a script with all the necessary error handling.

I have long suggested that the folks who want transactional memory start by creating a transactional filesystem based scripting environment - for Perl, Python, whatever.

A DVCS is, in some ways, a mechanism that allows the user to create quite complicated transactions while disconnected, operating in a clone - and then later pushing, committing, rebasing or grafting.   Interactive, because when a merge/integration fails, the user has to get involved.