Only one file per changeset
Ricardo Costa (17●2●7)
| asked Jun 01 '16, 9:49 a.m.
edited Jun 01 '16, 10:15 a.m. by David Lafreniere (4.8k●7)
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
David Lafreniere (4.8k●7)
| 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 Thanks David for your answer. When I said 5 files I was just giving an example. I also have features that touch many files. 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.
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.
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.
"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.
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
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. |
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.