It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×12,010

question asked: Sep 10 '13, 4:41 a.m.
question was seen: 3,996 times
last updated: Sep 16 '13, 8:24 a.m.

Related questions

Check-in change sets to respository work space

0
Ratheesh Madathil (137●18●29) | asked Sep 10 '13, 4:41 a.m.

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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Simon Eickel (1.1k●7●54●57) | answered Sep 10 '13, 6:36 a.m.
edited Sep 11 '13, 12:56 a.m.
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
Comments
Ratheesh Madathil commented Sep 10 '13, 6:43 a.m.

Ok...I see..

One additional point to my question: the 85 change set I meant was to 85 different components...

What I have not yet tried is this discard change-set. We have to see this.

The problem we see is, it is completely ok that everybody is able to check-in to his own RWS, but it then visible to all in the search window, this creates some confusion...

Simon Eickel commented Sep 10 '13, 6:45 a.m.

Yes, I understand this confusion - it will get more if you have a hugh company with many ppl checkin in changes :)

Ratheesh Madathil commented Sep 10 '13, 11:44 a.m.

One more point to your comment earlier.

I tried discarding the change set before deliver. But still it was appearing in the search (it is definitely not deleted!). So the end result is similar whether you "discard" it or not.

No idea, whether is because am an admin in the system. I will check it again with a normal user permission.

Tim Mok commented Sep 16 '13, 8:24 a.m.
JAZZ DEVELOPER

Users should provide some kind of context when searching for change sets (ie. provide a workspace or stream). With context, change sets that were discarded and never delivered anywhere will not show up. Searching without this kind of context will definitely bring up work that is irrelevant. You would get suspended change sets, discarded ones, and ones delivered to a different stream than what you may care about. I think that refining your change set search will help you find the change sets that you want and eliminate the confusion.

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Sep 11 '13, 12:12 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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)?
Comments
Ratheesh Madathil commented Sep 11 '13, 6:56 a.m.

Actually, the whole thing was not to prevent it for users, but giving some conditions like force to add a comment. This possibility we have it while deliver operation...

As I mentioned while testing, un-intentionally the button "Check-in" all was used, which created 85 new change sets without any additional conformation or asking to enter a comment.

For new users, it is difficult to understand the conepts behind pending changes view initially...

This brought me to bring-in this topic in the forum...

Geoffrey Clemm commented Sep 11 '13, 10:49 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

There is an interesting tension here.  One of the criticisms of high-end SCM systems is that they are "unfriendly to developers".   In practice, most of that unfriendliness is not built in to the SCM system, but rather is added by the customer in the form of custom hooks and triggers.   The low end SCM systems do not allow you to create hooks and triggers, so the developer experiences those systems as being "easy and fast to use".   So in RTC, we have tried to strike a balance ... checkin is the "developer friendly" operation, which is guaranteed to always just work, quickly and silently (just like your own personal GIT repository).   But when time comes to deliver to a stream, that's when the project lead for a stream gets to have his say, and places as many requirements on delivery to the stream as he wants.   It might help to think of RTC's checkin as "private checkin" and RTC's deliver as "public checkin".   The developers have complete freedom for their private checkins.

Heike Sprang commented Sep 16 '13, 4:26 a.m.

Hello Geoff,

our developer who used this "Check-in all pending local changes" simply was surprised that there was no question like "Are you sure you want to check.in those 84 files?".
With that question he would have had the possibility to discard his operation.
I guess that was all the developer wanted ;-)

Regards
Heike

Geoffrey Clemm commented Sep 16 '13, 8:01 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

That's certainly a reasonable request.   I've submitted work item Warn user if checkin-all will checkin a large number of changes or changes in multiple components (280596)
for it.   Please take a look at the Description, to make sure I captured the desired behavior.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.