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] [Created] (ACE-397) Change the "approve changes" process.
Date Tue, 23 Jul 2013 11:44:49 GMT
Marcel Offermans created ACE-397:
------------------------------------

             Summary: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message