[
https://issues.apache.org/jira/browse/ACE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans updated ACE-397:
---------------------------------
Fix Version/s: next
> 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
> Assignee: Marcel Offermans
> Fix For: next
>
>
> 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)
