[katello-devel] Approaches on Changeset Manipulation by multiple users

Dmitri Dolguikh dmitri at redhat.com
Wed Jun 1 12:31:50 UTC 2011


On 11-05-31 6:25 PM, Partha Aji wrote:
> Justin and I have been looking for a method for enabling multiple users manipulate/update the same changeset simultaneously before promoting it to the next environment. Main issue here is that the updates made to the changeset should be transparent to both users. Before promotion they should exactly know what is getting promoted. Problem here is that when 2 users are updating the changeset at the same time or the same user has the same page opened in 2 browser windows and clicks promote, the last change wins. So to remedy this 2 approaches were suggested
>
> 1) Polling based approach. Here, every 2 or 3 seconds a check will be made to the server asking if the changeset changed at the server (similar to how notifications behave) and the changset UI will auto refresh if it changed. I guess the User will be given some notice saying "the changeset has been changed, refreshing your promotion tree and changset contents..."
> 2) Locking based approach. Only one user can change the changeset at a time. So user kinda acquires a lock on changeset and modifies it and unlocks it or unlocks on time out so that some other user can work on it. Before deciding to promote.

What if we introduce a changeset per user? And perhaps show a hint on 
when a given product/package/errata was promoted the last time?
>
> Pros of approach 1
> Multiple users can update a changeset and be aware of changes happening actively.
>
> Cons
> It can be an annoying experience with contents you just changed automatically getting refreshed/overwritten with the updated stuff. The hard part from the coding perspective will be reconciling the changes you made with the changes in the updated changeset.
>
> Pros of approach 2
> No reconciling business as simultaneous updates on a changeset are forbidden.
>
> Cons
> When will the changeset lock get released. What happens if a user stays on the same changeset forever and wont allow others to update or promote. Locking/Unlocking has to be worked out from the coding perspective. We'd have to be cognizant of the fact that the same user may be updating the changeset from 2 different browsers (should we allow that or not ...).
#2 feels a bit like MS sourcesafe to me. Relatively simple to implement, 
but a hassle to use.
> I prefer 1 for the simple reason it makes best use of the model based changes justin has made so that changeset can be updated by multiple users and also that we have methods to do polling :)... It also allows for User with permission to product A and user with permissions product B simultaneously update the changeset..
>
>
> Thoughts ??
>
> Partha
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel




More information about the katello-devel mailing list