immitev Posted May 9, 2013 Report Share Posted May 9, 2013 In the screenshot below, you can see that neither the file history, nor the file 2D history, although the last changes were merged into the parent branch. Tested both with 4.1.10.414 and the latest 4.1.10.434 version. Btw, just to mention that it could be really confusing not to show the merges in the file history (I think that adding a checkbox to show/hide merges would be a very good feature). This request is similar to what has been mentioned in http://www.plasticscm.net/index.php?/topic/1388-feature-request-view-history-as-single-report Link to comment Share on other sites More sharing options...
manu Posted May 10, 2013 Report Share Posted May 10, 2013 Well, let me explain why the merge links, in your case, are not shown (and it most of the cases) The "history" and "history 2D" views only shows you the changesets that are having revisions of the file you are querying the history. When you perform a merge and the only contributor is "source" there isn't a new revision created, the destination revision is "replaced" by the "source" revision. On the other hand, during the merge, a new revision is created when you have a both contributors conflict since we need to create a new revision to save both changes. Maybe you can find useful the following idea: https://plasticscm.uservoice.com/forums/15467-general/suggestions/2938098-interactive-file-history-annotation- Link to comment Share on other sites More sharing options...
immitev Posted May 10, 2013 Author Report Share Posted May 10, 2013 Well, this annotation idea is interesting and probably useful, but something simpler like being able to visualize both the revisions and the merges within the same windows would do also a good job. Now IMO it is just confusing ... To understand how a revision of a file got in a particular branch, one needs not only the file history, but also to analyze the merge links in Branch Explorer, which can be pretty time consuming for a repository with a lot of branches and changesets. Link to comment Share on other sites More sharing options...
manu Posted May 10, 2013 Report Share Posted May 10, 2013 Hi immitev, we just show the changesets that are having revisions just to make a cleaner graph but I understand that in some scenarios your suggestion can be useful, please feel free to add the idea into the uservoice system. https://plasticscm.uservoice.com/forums/15467-general Best regards. Link to comment Share on other sites More sharing options...
immitev Posted May 13, 2013 Author Report Share Posted May 13, 2013 OK, here is the idea - http://plasticscm.uservoice.com/forums/15467-general/suggestions/3950398-show-merges-in-file-history-and-2d-history Link to comment Share on other sites More sharing options...
manu Posted May 14, 2013 Report Share Posted May 14, 2013 Thanks! Link to comment Share on other sites More sharing options...
manu Posted September 14, 2015 Report Share Posted September 14, 2015 This was done http://plasticscm.uservoice.com/forums/15467-general/suggestions/3950398-show-merges-in-file-history-and-2d-history Link to comment Share on other sites More sharing options...
manu Posted September 14, 2015 Report Share Posted September 14, 2015 http://codicesoftware.blogspot.com/2013/11/plastic-scm-release-5044505-including.html Link to comment Share on other sites More sharing options...
gweronimo Posted September 29, 2015 Report Share Posted September 29, 2015 Hi! There are still cases where the 2D RevTree for a file/folder shows a changeset without incoming merge arrows even though that changeset is the destination of a merge. This is a bit confusing. As soon as a changeset is displayed, I'd want to see any _incoming_ merge arrows even if the file or folder in question was not _actually_ modified as part of that merge but rather just changed in the same checkin. The "Version tree - View version tree - Display all merges in history" is rather useless IMHO, since enabling that option means I suddenly get to see loads of branches and merges that are totally unrelated AND despite that I may _still_ not see the incoming merge I was asking for above! Link to comment Share on other sites More sharing options...
manu Posted September 29, 2015 Report Share Posted September 29, 2015 Hi Goran, can you provide a way to reproduce the issue? We'll be happy to review it. Thanks. Link to comment Share on other sites More sharing options...
gweronimo Posted September 29, 2015 Report Share Posted September 29, 2015 Yes, I'll try to create a minimal case and report it here. Where I have already seen it is in the imported merge described in my support ticket 8301 and mentioned here: http://www.plasticscm.net/index.php?/topic/3029-new-files-or-folders-committed-with-name-conflict-prefixed/. The added folder became add-new instead of add-copy in the merge. In full branch-explorer the destination changeset has an incoming merge arrow, but not in 2D revtree for this folder (where the merge destination changeset is marked as A = Added but without the incoming merge arrow). Additionally, IMHO think the "Home" changeset should always (when at all possible) be shown in all the branch-explorer/2D-revtree views. This would make it easier to relate the view to the current workspace contents. In 2D revtree I simply want an extra U = Unchanged changeset (on the relevant branch) with the Home icon above in the cases where the home changeset/branch would not otherwise be included. In all those views, I'd like the Home changeset to be displayed regardless of date filter (possibly with a dotted parent-changeset arrow to connect it with the nearest date-filter-included changeset. However, exclusion filters and visibility mode etc should still be applied to the Home branch... Link to comment Share on other sites More sharing options...
gweronimo Posted September 29, 2015 Report Share Posted September 29, 2015 OK, here is the minimal case: * From /main, create a branch called /child. * On /child, add a file childfile.txt and Checkin (1). * On /main, add a file mainfile.txt and Checkin (2). * On /child, merge from /main. Also modify childfile.txt. Then Checkin (3). * Open Branch Explorer. Here, (3) has an incoming merge arrow from (2). * On /child, goto Items and show 2D History for childfile.txt. Here (3) is shown as C = Changed, but without the incoming merge arrow. I find it confusing to see (3) without the merge arrow, since I know that changeset is the destination of a merge. It makes me lose valuable context, since I tend to think about changesets in terms like "that is the checkin where I merged from /main". (On a side note, it also makes it even harder to track down tricky "item loaded twice" situations etc.) Link to comment Share on other sites More sharing options...
manu Posted September 29, 2015 Report Share Posted September 29, 2015 Hi Goran, thank you for the feedback, I'm afraid that scenario is slightly different than the one we tried to improve some releases ago. In your case the "childfile.txt" file was not really changed during the merge, it's committed in the same chanegset but it's not related with the merge process, for the VCS point of view. On the other hand if you take a look into the 2D history view of the mainfile.txt you'll see that merge is indeed shown because it's interesting to know it was added to the branch at that certain point. Of course you are kindly invited to add your suggestion in the user voice page, I'm just trying to explain why it's currently behaving in that way. Link to comment Share on other sites More sharing options...
gweronimo Posted October 26, 2015 Report Share Posted October 26, 2015 Hi Manu! I see your point and normally it is not necessary to show a merge arrow for every unrelated merge, but maybe you could add an optional visual cue to indicate that a displayed changeset has a merge that is unrelated? Also, I added my suggestion regarding the Home icon as a new uservoice: http://plasticscm.uservoice.com/forums/15467-general/suggestions/10374423-show-home-changeset-whenever-possible Link to comment Share on other sites More sharing options...
manu Posted October 27, 2015 Report Share Posted October 27, 2015 mmmm yes, that would be possible, let me share it with the team. Thanks for the UserVoice entry. Link to comment Share on other sites More sharing options...
gweronimo Posted October 28, 2015 Report Share Posted October 28, 2015 Thanks, I elaborated my other suggestion into a uservoice as well: http://plasticscm.uservoice.com/forums/15467-general/suggestions/10439205-add-unrelated-merge-indicator-in-2d-history-and Link to comment Share on other sites More sharing options...
manu Posted October 28, 2015 Report Share Posted October 28, 2015 Thanks! Link to comment Share on other sites More sharing options...
gweronimo Posted February 17, 2016 Report Share Posted February 17, 2016 Awaking this thread once again, since I found another interesting scenario. I often bring up the 2D history tree for a directory to see what changes are done to its contents. This works quite fine, but I've discovered that it does not show merge arrows for merges that involve items inside the relevant subtree. This makes it harder to follow what happened. For example, I can see "C" changesets on a child branch and then later a "C" changeset on the main branch where the comment on the latter says it was merged back from the child branch, but there is no merge arrow displayed. For a more informative view, I would suggest that for 2D history of a directory, merge arrows should be shown whenever a merge involves any of the items from that subtree. Link to comment Share on other sites More sharing options...
gweronimo Posted February 18, 2016 Report Share Posted February 18, 2016 I added a new uservoice to reflect this request: http://plasticscm.uservoice.com/forums/15467-general/suggestions/12374433-in-2d-history-of-a-directory-show-merge-arrows-th Link to comment Share on other sites More sharing options...
manu Posted February 19, 2016 Report Share Posted February 19, 2016 Thanks Göran! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.