[jira] [Closed] (ACE-397) Change the "approve changes" process.

["Marcel Offermans (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ACE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Offermans closed ACE-397.
--------------------------------

    Resolution: Fixed

Already implemented.

> Change the "approve changes" process.
> -------------------------------------
>
>                 Key: ACE-397
>                 URL: https://issues.apache.org/jira/browse/ACE-397
>             Project: ACE
>          Issue Type: Improvement
>          Components: Client Repository
>    Affects Versions: 1.0.0
>            Reporter: Marcel Offermans
>
> Before any change becomes visible for a target, it has to be approved. This can either be done manually or automatically (by setting auto approve for that target). Conceptually this is fine, but the current implementation has a problem.
> As soon as you "approve" a change for a target, it will generate a new deployment version for that target. This happens before you commit your workspace, and it can happen multiple times. The problems this creates, potentially, are:
> 1) When you approve more than once, you get more than one new version of the software for that target. This is probably not what you want, and can even lead to unnecessary deployment traffic.
> 2) When you rollback (or just don't commit) your changes, a side effect of the creation of new deployment versions is that template processors generate and upload new artifacts. These are not cleaned up. To make matters worse, if you lateron do try to commit new changes, you will probably end up with a name clash as the same names will be used again (but with different content).
> These problems can be resolved by redesigning the way the approve process works:
> When you approve changes, you still state to the system that any changes for this target should lead to a new deployment version, but instead of generating that deployment version immediately, we should defer that action to a "pre-commit" phase that happens just before the final commit of the repositories. That solves problem 1) because you can now never generate more than one new version and problem 2) because nothing is generated until you commit.



--
This message was sent by Atlassian JIRA
(v6.2#6252)