Re: [autopatch-cvs] Question about autopatch

[Mike H. <mi...@ta...>]

Hi John -

I'm cc'ing the autopatch-cvs list so this discussion stays public

Autopatch does not handle branches cleanly, no, and contention for  
patch numbers among developers also turns up semi-frequently if you  
really build database refactoring into your development (which you  
should, so it's a problem worth solving)

Here's the design we came up with to handle branches and patch number  
convention at the same time:

---------

Timestamps on migrations are a means for a developer to choose unique  
patch numbers without contention.  Time is just the "central  
authority" handing out unique patch numbers.

The central innovation here is that rather than storing the current  
patch number in the database, the patch table stores the patch numbers  
of all applied patches.  When starting up, the timestamps associated  
with the patches are converted to integers are ordered as they usually  
are.  Any unapplied patches are applied in order.

Given this setup, patch number can actually have any integral value.   
Autopatch could be converted to use this format but instead of  
applying any unapplied intermediate patches, it could bail and require  
you to rollback to a state prior to the intermediate patches.  This  
would force developers to apply patches created on a release branch  
prior to any patches on trunk (and may force rebasing of trunk patches  
against the release database).
--------

Concretely, I believe that means:

- adding a column in the patch table to store patch number, and  
another column to store applied date (forensics)
- altering the primary key in the patch table to be system name +  
patch number
- altering patch application to always insert a row for system name +  
patch number when it applies a patch, instead of updating
- altering rollback process to remove the row for the patch it is  
rolling back
- altering patch status / needed-patch-culling process to start with  
first patch not applied, and retain any other patches not applied
- using timestamps for patch numbers would then allow any patch number  
to work, as committing them out of order wouldn't stop them from running

It's not the biggest feature in the world, but it obviously has to be  
correct. It also means that autopatch may apply patches in an  
incompatible order if a branch patch was developed in a way that is  
incompatible with future trunk patches. Care must be taken so patch  
authoring doesn't create this situation.

If you want to implement this, I'd be excited, and very willing to  
review patches / offer guidance etc. There are good unit and  
integration tests that will help keep things in line while you're  
hacking.

For people that really care, provably reproducible behavior all the  
time may be restored by adding a switch to autopatch that forces only  
monotonically-increasing patch application, with perhaps an extra  
switch that automatically does rollbacks from out-of-order patch  
applications in order to bring the database down to a level where the  
first missing patch is, then applies them all again starting from that  
one.

Building should be easy with the possible exception of the two  
adapters - one for spring and one for atg. I usually use ant and just  
say "ant", personally. Maven should "just work" too. If those attempt  
to build the adapters and you don't have spring libs or atg libs, you  
could just nuke those from the build recipes and it should just work  
as well...


-Mike

On May 26, 2010, at 9:53 AM, John Ham wrote:

> Hi Mike,
>
> We're using autopatch and run into issues when patches are named  
> using the same number. No biggie. We try to work with simple - synch  
> up to the repository prior to checking in the patch file.
> Where we run into problems is when we're developing for multiple  
> branches at the same time. Having to maintain a list of "reservation  
> numbers" for each branch is a bit clumsy right now.
>
> I don't have a solution to this other than to maintain autopatch  
> files in separate project folders perhaps within branches.
> One change I'd like to make is regarding the tk_patches table and  
> how autopatch determines which patches have been run.
>
> The idea is to persist each patch file name into a table - something  
> like tk_patch_names...
> When autopatch runs, it will order files in alphabetical order for  
> execution.
> Check for patch file against the tk_patch_names to determine if it  
> was applied. If filename doesn't exist, then it hasn't been applied.
> After patch file is applied, then it is inserted into tk_patch_names.
>
> Are there any directions on how to build the autopatch project? I  
> was reading on the site but could not find any list of dependancies  
> and such. I'll be signing up for a sourceforge acct and will see if  
> there is some info in forums about this project.
>
> Thanks,
> =========================
> - John Ham
> - Support Engineer, macys.com
> - Email: joh...@ma...
> - Phone: 415-422-1553

--
Mike Hardy
415-720-9408