ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (ACE-397) Change the "approve changes" process.
Date Thu, 06 Mar 2014 12:58:43 GMT

     [ 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)

Mime
View raw message