Check-in change sets to respository work space
Hello,
Upto know I have found that we can do many restrictions at the level of delivering a change set to a stream (like mandate a work item or mandate a comment etc..).
What currently I could not find is, how do we restict at the level of "check-in" operation to local repository work space.
Reason behind: while testing the check-in all was used. It created 85 change sets which was not really intended.
Of course the change-set are not delivered. But still if we do any search for change sets, these change sets will appear for all users.
What are the possibilities to avoid this in future? Can I set some hook before the change-set is created by any user?
2 answers
Hi Ratheesh,
Check Ins cannot be restricted by default.
Change Sets can be discarded before delivering them to the Stream so I think you won't find them by searching.
But this is only possible when they are not delivered.
The normal way is that when a user does a checkin without delivering this CS to the stream he uses this CS for his next checkins, too. In this case he would use only one CS would not create 85 ones without delivering one.
The normal way of RTC is that everybody can do a checkin to his own RWS in case of saving his work.
What you can restrict is the delivering to the stream.
If you need the restriction on checking in you have to create an Enhancement Request.
Hope this helps,
Simon
Check Ins cannot be restricted by default.
Change Sets can be discarded before delivering them to the Stream so I think you won't find them by searching.
But this is only possible when they are not delivered.
The normal way is that when a user does a checkin without delivering this CS to the stream he uses this CS for his next checkins, too. In this case he would use only one CS would not create 85 ones without delivering one.
The normal way of RTC is that everybody can do a checkin to his own RWS in case of saving his work.
What you can restrict is the delivering to the stream.
If you need the restriction on checking in you have to create an Enhancement Request.
Hope this helps,
Simon
Comments
RTC does not allow you to prevent a user from checking in their changes. This was a very deliberate design choice, since it was felt that a user should always be able to use the server as a reliable store for their work in progress. You are correct that there is no way to delete a change set ... "discard" just removes a change set from your workspace. You can delete the content of a particular version, but you cannot delete the change set metadata (the change set metadata takes up very little space, so no need to worry about that cluttering the server). It is true that those change sets can be found via queries, but in practice, we have not found that to be a problem. If you find otherwise, it would be very reasonable to submit an enhancement request to "archive" a change set so it by default does not appear in query results.
Just for interest's sake, what checkin-prevention rule would you have put in place to prevent the checkin you describe (that wouldn't block useful work)?
Just for interest's sake, what checkin-prevention rule would you have put in place to prevent the checkin you describe (that wouldn't block useful work)?
Comments
