Postby ConvertFromOldNGs » Fri Aug 07, 2009 1:06 pm
by Brendan >> Wed, 7 Feb 2007 0:01:59 GMT
Hi John,
You probably want to alter 1 and 2 slightly to
1) any entity (method/class/form etc.) that is modified and is not in a *currently open* patch gets added to the developer's current patch. Otherwise you're in for a one time change for each entity.
2) no entity that is in a *currently open* patch can be modified by a developer whose current patch is different
1 and 2 can and have been done using patch control and patch control hooks. 3 could be done (though I haven't done it - the extract was always explicitly requested and done in batch mode). 4 can't be done. Entity changes are committed as each entity is changed so the patch doesn't define any kind of transaction. The only way to undo the effects of a change under a patch (assuming rolling back the database is not an option and it hardly ever will be) is to change the entities back to the way they were.
If your C++ isn't up to it (and mine certainly isn't) a workable approach which I have used successfully is to write a small amount of C++ code which converts the hook parameters to a string and sends it as a TCP/IP message to a Jade process in a different environment (maybe even the same environment? - not sure, haven't tried it). It then waits on a TCP/IP response to exit the hook call with a zero or non-zero return code. That way you can write most of the code in Jade.
With a small number of developers, 2) above is the simplest approach to controlling collisions in the dev environment though it will create some management issues from time to time. Since I did the implementation for a large number of concurrent developers (over 25), I actually allow collisions under certain circumstances but it can be tricky and you would need to think through the ramifications. I would recommend keeping it simple with just a small team of developers.
Cheers, Brendan