Tag Archives: Pending Edit

Change is always inevitable and Changeset makes sense.

Let me start with a question for which I created a small poll. Please select an option to vote and then read further.

If you have not voted for option “You edit single file to resolve the issue/bug.” then you might be facing the pinch for a logical grouping of changes done to fix a bug. Team Foundation Server takes it to the level of logical grouping of changes.

Any piece of functionality we build for a software requires multiple files, until and unless you throw away all the design principles and write code in a single source file. Each and every activity in software development is a change, whether you add some files, delete some or edit some. Everything said above in TFS system needs to be checked-in, so when you see the check-in window it is visible as a pending change, ready to be committed to the source server (Pending Add, Pending Delete, Pending Edit).

Changeset is a logical grouping of the changes you do in source control, it is essentially a collection, what needs to be in the collection is ultimately controlled by the developer. So it is the responsibility of the developer to select the pending changes which would be eventually committed to the source control server.

image

Notice the Change types “edit”,and “add” in the screenshot above. These changes can now be checked-in as a set which we typically refer to as a “Changeset”. When I said that what contains inside a change set is controlled by developer earlier in this post, I meant that you can select which objects you want to check-in controlled by the checkbox besides every element in the above dialog.

Changeset is a linkable entity, meaning you can associate them as links with work items in TFS. Why is this important? The answer is simple, you never do any change in a software without a purpose when you consider the complete ALM picture. Each work item type, defines a purpose in the software development methodology. This helps us in understanding the purpose of source code changes, as to why we did a particular change, what was the intent behind and some more artefacts (like effort spent, developer comments, to which product functional area it corresponds to, to which release etc., will we dive into these details later in some future posts when we do a deep dive with work items).