It's all about the answers!

Ask a question

Only one file per changeset


Ricardo Costa (176) | asked Jun 01 '16, 9:49 a.m.
edited Jun 01 '16, 10:15 a.m. by David Lafreniere (4.4k7)
 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

Accepted answer


permanent link
David Lafreniere (4.4k7) | answered Jun 01 '16, 10:49 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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

Comments
Ricardo Costa commented 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 commented Jun 02 '16, 2:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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 commented 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 commented Jun 02 '16, 4:43 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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 commented 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 commented Jun 03 '16, 1:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.2k1941) | answered 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.

Comments
Ricardo Costa commented Jun 01 '16, 2:06 p.m.

 thanks for your answer Arun

Your answer


Register or to post your answer.