Plastic SCM release 5.0.44.505 including improved item merge tracking is now out
A new 5.0 release is out today: 5.0.44.505 including major improvements in the way information about merges is handled.
Please note that the third number (5.0.44.505), the one marking the compatibility, has been changed so you will need to upgrade clients and servers.
Changes in the stored item merge tracking data
This release introduces a major change in the data stored to track items that have been merged. While the change doesn’t have any impact in the merge mechanism itself because the new data is not used for merging, it does make a big change in the way Plastic displays information of the merges already completed.
There are 4 areas affected:
- Changeset/label/branch diff: now when diffing a changeset or branch or label that is involved in a merge, the GUI will clearly display which items come from which merge and whether they were modified by the two contributors or not.
- 2d version tree: it is greatly improved with much better information about when a single file was merged and what actually happened to it on each changeset.
- Annotate: the annotate/blame feature uses now the precise item merge tracking information to precisely track line history across merges.
- Semantic Method History: this new feature is also improved because now it displays exactly when the methods were merged and doesn’t only compare the method with its parent revision but also across the merge paths. At the end of the day it means that while before a method could show up as ‘added’ on a branch and then ‘added’ again when merged, now it will show when it was really added and will explain that it was only merged at the merge changeset.
Improved diff interface
Look at the following image to see the improvements:
We’re diffing changeset 1181 and as you can see in the new interface it clearly shows how 510 elements were added on this changeset but there are many other ones that come from the merge from changeset 1180.
Inside the merge group it includes different categories: files that were changed, added or deleted and a new group “merged”, meaning files that were modified both in the source branch and in the destination of the merge and hence they required a 3-way merge. Normally these are the files worth reviewing when diffing a merged changeset.Improved 2d tree
The new merge tracking information fixes the issues present in the current 2d tree (when launched without all the show merges options) as you can see below:
Improved annotate/blame
The annotate action is now able to walk the merge history back so every line will be really identified where it was created. Before it was sometime showing a line as being created during a merge when it was really created on an older branch.
Improved semantic method history
Now when you check the history of a method you’ll also see when a given revision of a method is coming from a merge, as the image below shows:
Now it will be much easier to understand how the method evolved through history across merges and so on.
Calculating the new item merge tracking data in existing repositories
All the merges done with the new release will automatically calculate the new item merge tracking information. But the existing ones in the repositories will need to be processed in order to generate the new data.
There is a new program in the server directory named builditemmergeinfo and the way to invoke it is really simple:
builditemmergeinfo repositoryname
Once it finishes the repository will have all the new merge tracking data ready to be used by the Plastic SCM GUI.
Notes:
- If you are using a SQLite backend (or other embedded backend like Firebird) you will need to stop the server.
- If you are used a backend that requires direct access to the data file (like SQLite or SQL Server CE) you’ll need to run the builditemmergeinfo program with enough privileges to write on the directory where the data files are.
0 comentarios: