Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Only one file per changeset

Questions
Tags
Users
Badges
Ricardo Costa
(17●2●7) edited
Jun 01 '16, 10:15 a.m.
 Hi,

my company has this rule that we can only have one file per changeset. If my new feature has changes in 5 files I have to create 5 changesets.

What are the implications of this approach?

Thanks,
Ricardo

0 votes

2 answers
6,887 views
0 votes

Accepted answer

Permanent link
David Lafreniere
FORUM MODERATOR / JAZZ DEVELOPER (4.8k●7) edited
Jun 01 '16, 4:26 p.m.
Having a feature that only touches 5 files is lucky in my opinion :)
Often a feature may touch hundreds of files (which would be hundreds of change sets).

Always having one change set per file could have a negative impact on the overall performance of RTC (especially for users that have low bandwidth / high latency when connecting to the jazz.net server) and possibility even the usability (having to deal with this many change sets in the UI...)
-Views that show the change sets would have to 'fetch' a lot more items (IChangeSets) this way. Which puts more load on the server.
-Work items would now have tens/hundreds of change sets associated with them.
-The Locate Change Sets feature (which is 'work item-centric') will take longer to compute whether or not all those  work item (i.e hundreds of change sets) are contained in the history of other streams/workspaces/snapshots, etc
-Change Summary, Change Explorer, and the History view of a component will all take longer to fetch all the change sets (since there are more) (or at least this would create more 'pages' to go through for some of the views).
-The performance in the Pending Changes view would suffer, as it has to compare a workspace it's flow target, and this approach would in general mean there are a LOT more incoming / outgoing change sets.
-The benefit of adding a meaningful comment to a change set is lost. Ex: "refactored the Engine class and its callers"), "added JavaDoc to several new classes for the new feature", "added several JUnits for the new feature". I mean you still could, but there would be a lot of duplicated change set comments. This also would impact Code Reviews.
-There is no built-in way to have this enforced in RTC. Note: you cannot have more than one active change set at a time which contains a given file. Thus users will have to remember to complete or deliver the change set, or when checking-in, always find and pick the one active change set which contains the file (and from my understanding, at any given time there may be MANY active change sets (one  per file) so this would be tedious.
Ricardo Costa selected this answer as the correct answer

0 votes

Comments
Ricardo Costa
Jun 01 '16, 2:09 p.m.
Thanks David for your answer. When I said 5 files I was just giving an example. I also have features that touch many files.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 02 '16, 2:23 a.m.
I know customers wanted a similar policy to be able to do cherry picking. You can avoid having a lot of gaps/overlap this way. As David points out, there is no built in capability. You can write a custom advisor to prevent delivery. We have no extension point for check-in, so you can't prevent that. If users complete the change set before delivery, they would have to throw it a way and do the changes again. Dependent on the architecture of your application this could be tedious, but others have this policy as well.

Ricardo Costa
Jun 02 '16, 4:33 a.m.
Thanks. We dont' have a built-in way to prevent this. It's just a (bad) practice that people should follow. We are advised to do this because of the way that streams are configured. We have 4 streams: dev -> qua -> stg -> production. And we can only deliver to dev. We cannot deliver to the other streams diirectly. Not even when we need to apply an hotfix.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 02 '16, 4:43 a.m.
Ricardo, that you can't deliver there is not the driving factor, I think. The drivng factor is the ability to do "Cherry picking". The idea is that they want to pick one of the change sets and accept that in the hope that there is no previous change it depends on. By only having one file impacted by a change set the hope is to avoid overlaps and to pull in more changes. I am not sure how realistic it is to assume that you can just accept a change to one file...... In Java it is not. In other environments, may be. It might be viable in some cases. As I said, I have heard some customers try this promotion/delivery model. Note, in the past it was hard to find the dependent change sets. With the latest versions of RTC we have now improved gap handling support.

Ricardo Costa
Jun 02 '16, 12:00 p.m.
"Ricardo, that you can't deliver there is not the driving factor, I think. The drivng factor is the ability to do "Cherry picking". The idea is that they want to pick one of the change sets and accept that in the hope that there is no previous change it depends on. By only having one file impacted by a change set the hope is to avoid overlaps and to pull in more changes." I think that this is the reason why we are making changesets with only one file. Because later is easier to manage versions and overlaps. What I'm worried about is that when I'm making a new functionality (or hotfix) and touch more than one file, that functionality only makes sense with all of those files. It's not a single file. Later when someone needs to get my code, it has to know which changesets to accept. If someone misses one changeset it can break the code.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jun 03 '16, 1:53 a.m.
I agree and it heavily depends on the type of development and the language used if the assumption is really correct.

showing 5 of 6 show 1 more comments

One other answer

Permanent link
Arun K Sriramaiah
(3.2k●2●37●77) Jun 01 '16, 10:33 a.m.
Hi Ricardo,

Change set is collection of related modification to files for specific requirements.

Yes, you can use it but I don't think we have any build in feature to prevent it.

Note: you need to check-in and deliver each change set every time with common files changes.

eg:  can't  create two change sets for same file a.java file two times (cs1 and cs2) , without delivering it.


Regards,
Arun.

0 votes

Comments
Ricardo Costa
Jun 01 '16, 2:06 p.m.
 thanks for your answer Arun

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,144
× 1,210
× 152

Question asked: Jun 01 '16, 9:49 a.m.

Question was seen: 6,887 times

Last updated: Jun 03 '16, 1:53 a.m.

Confirmation Cancel Confirm