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/... --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.
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.
No comments:
Post a Comment