Settings and activity
133 results found
-
3 votes
Göran Wallgren
shared this idea
·
-
39 votesGöran Wallgren
supported this idea
·
-
3 votes
An error occurred while saving the comment An error occurred while saving the comment Göran Wallgren
commented
This uservoice is related to the following, and would be a good-enough solution to it as well:
https://plasticscm.uservoice.com/forums/15467-general/suggestions/12374433-in-2d-history-of-a-directory-show-merge-arrows-thAn error occurred while saving the comment Göran Wallgren
commented
Moved the icon suggestion into a new uservoice:
https://plasticscm.uservoice.com/forums/15467-general/suggestions/13068252-make-better-use-of-the-icons-in-history-and-changeAn error occurred while saving the comment Göran Wallgren
commented
Here is a forum discussion that led up to this suggestion:
http://www.plasticscm.net/index.php?/topic/1741-merge-not-displayed-neither-in-file-history-nor-in-file-2d-history/Göran Wallgren
shared this idea
·
-
3 votes
An error occurred while saving the comment Göran Wallgren
commented
If you don't find this feasible, then please implement this instead:
https://plasticscm.uservoice.com/forums/15467-general/suggestions/10439205-add-unrelated-merge-indicator-in-2d-history-andThat would be just fine, since most often we try to checkin clean merges anyway. If a subtree has changes in a changeset that is merged, most likely the merge is related!
An error occurred while saving the comment Göran Wallgren
commented
Are you sure? My thinking is more along these lines:
For each changeset that is displayed in 2D History for a directory
-- If there is any (incoming) merge associated with that changeset
-- -- If the relevant subtree of that changeset is involved in an incoming merge
-- -- -- Display merge arrow for that changeset* You ARE already able to (quickly) "Display all merges in history" (you have an option for this under "Version tree").
* You ARE also able to (quickly) display only the changesets where something "interesting" (i.e changed items) happens in the relevant subtree.
Therefore my request should not be a big performance hit, since you would only need to check subtrees of the "changesets with changes AND incoming merges" subset.
Also, if you make this an optional feature, the user can trade performance for verbosity.
(If this is not at all feasible, then as a second best variant I would wish for an option to always show merge arrows that are incoming on the "interesting" (C) changesets. This would cover also my other uservoice http://plasticscm.uservoice.com/forums/15467-general/suggestions/10439205-add-unrelated-merge-indicator-in-2d-history-and which we could then close.)
This discussion originated here:
http://www.plasticscm.net/index.php?/topic/1741-merge-not-displayed-neither-in-file-history-nor-in-file-2d-history/Göran Wallgren
shared this idea
·
-
41 votes
An error occurred while saving the comment Göran Wallgren
commented
We are no longer using the VS plugin (for other reasons). So that solution would not help us and we still get this case from time to time.
It is a general wish from our side to avoid seeing unchanged files in any Diff/Pending view. See this other uservoice: http://plasticscm.uservoice.com/forums/15467-general/suggestions/11533422-exclude-identical-files-from-diff-between-selecte
We would like one single option that lets us avoid seeing unchanged stuff in both the cases described in these two uservoices.
An error occurred while saving the comment Göran Wallgren
commented
In a recent blog post (http://codicesoftware.blogspot.com/2015/07/towards-semantic-version-control.html) the following is said:
"It would greatly help seeing, at first sight, that most of the files to review only contain trivial changes. You wouldn't be put off, you wouldn't lose focus and you’ll be more productive."
This is precisely what this uservoice is about, as well. We don't want to lose focus by diffing "identical" files.
Göran Wallgren
supported this idea
·
An error occurred while saving the comment Göran Wallgren
commented
Adding more options is a way to cater to the different needs of customers. I don't find this a must-have, it's just one of these small things that would smooth the workflow. It's not an old svn habit, it's a reasonable wish to avoid seeing unchanged files in the list off changes before Checkin.
For us an option to avoid the VS plugin doing a checkout would work, but that may not help Unity users who have reported similar wishes to avoid seeing unchanged files as pending.
An error occurred while saving the comment Göran Wallgren
commented
So, if it is skipped on Checkin, why shouldn't I have the option to skip it from the list altogether? It's clutter! The machine knows about this already so why bother the human with irrelevant details?
This option could be phrased differently as "Hide unchanged files in Pending Changes" or similar.
An error occurred while saving the comment Göran Wallgren
commented
Besides, I'm coming from (Tortoise)SVN where unchanged files never appear in the list of files to Commit. So this is the behavior I'm used to and was expecting... Thus, I would like to have the option to preserve this behavior.
Göran Wallgren
shared this idea
·
-
3 votes
An error occurred while saving the comment Göran Wallgren
commented
An alternative would be to display an implicit hierarchy of Labels, based on identical parts (starting from the beginning) of the Label names.
Some wiki engines (like the Trac engine) do this for grouping related pages in the page Index. They even combine this with a slash-based hierarchy. See for example the Trac - Dev entries in the main Index here: http://trac.edgewall.org/wiki/TitleIndex
Göran Wallgren
shared this idea
·
-
24 votes
An error occurred while saving the comment Göran Wallgren
commented
I see your point, but then there should be an option to hide/exclude the identical diffs.
Göran Wallgren
shared this idea
·
-
6 votes
An error occurred while saving the comment Göran Wallgren
commented
Yes, please reuse the action/view icons (Items, Pending, Branches etc) for the view-tabs. It would make the GUI look cooler and it would be much easier to quickly see which type each tab is!
This is a simple addition that would be super-great! ;)
Göran Wallgren
supported this idea
·
-
3 votes
An error occurred while saving the comment Göran Wallgren
commented
Hmm, actually it should be done for single-file history as well, since we may want to "Diff selected changesets" from the 2D History, and then the inline Diff does not equal the filtered Changeset Diff any more...
Göran Wallgren
shared this idea
·
-
40 votes
An error occurred while saving the comment Göran Wallgren
commented
Hmm, sorry, the previous comment was made for Plastic SCM. (I searched the Plastic SCM uservoices and accidentally ended up on one for Semantic Merge.) However, the described problem may exist there too?
An error occurred while saving the comment Göran Wallgren
commented
I think the reason that some keys don't (always) work is that they only work when keyboard focus is (or is not) in a specific panel. For example, in a 3-way merge the conflict navigation keys don't work when any of the text panels has the keyboard focus...
I too would like keys to be configurable, but even more important is to make them work regardless of focus.
Göran Wallgren
supported this idea
·
-
1 vote
An error occurred while saving the comment Göran Wallgren
commented
When editing a VCS Root that uses the Plastic plugin, you can specify "Workspace directory" . The description says: "Provide path to a directory on TeamCity server where the workspace should be created. Leave blank to use default path (will use one workspace per VCS configuration)".
With this, I think the options for customizing the workspace path is already in place. Thereby this uservoice could be closed?
An error occurred while saving the comment Göran Wallgren
commented
When using "server-side VCS checkout mode", I think you can specify where the workspace should be created.
Also, since 5.4.16.712 the Plastic plugin also supports "agent-side VCS checkout mode". In the latter mode, the workspace currently gets a default name of "plasticscm_15" and is located under the TeamCity "Build Checkout" directory (teamcity.build.checkoutDir). However, I've been told by Codice staff that this will soon be changed so that the checkout is done directly in the "Build Checkout" directory without the extra sub-directory.
The two modes are explained here:
https://confluence.jetbrains.com/display/TCD9/VCS+Checkout+Mode -
175 votes
An error occurred while saving the comment Göran Wallgren
commented
Continuing from my latest comment, this means that there is a possible workaround in some cases:
* After a cherry-pick involving added items, immediately do a normal merge back onto the original branch (the one you cherry-picked from).
Now, this is not always feasible and it will NOT help if the added files have already been modified on the original branch.
However, whatever it is that happens in that merge-back is very interesting - the resulting changeset does not seem to contain any changes but still it will make subsequent merge-backs work fine even when there are changes to the added items on both branches (no more "item loaded twice"). The hidden details that happen in this "magic" (and seemingly empty) merge-back are exactly what I'd like to happen in the original cherry-pick instead, so we don't get this problematic issue in the first place...
An error occurred while saving the comment Göran Wallgren
commented
Regarding "item loaded twice" caused by cherrypicking an Add operation, I have made the following suggestion that I discussed with Plastic staff in this (old) forum post:
http://www.plasticscm.net/index.php?/topic/2118-item-loaded-twice-conflict/Would it not be possible to handle _added_ files/folders in a better way in a Cherrypick? When cherrypicking a file Add operation, a sensible expectation is to be able to merge this back to the branch where the Add came from... Fixing that would solve an important part of this uservoice.
Here's a scenario:
* Switch to branch /main
* Add file a.txt. Checkin (1).
* Add file b.txt. Checkin (2).* Switch to branch /other
* Merge from (1). Checkin (3). "Copied (new) / Merge from 1".
* Cherrypick from (2). Checkin (4). "Copied (new) / Cherrypick from 2".
* Modify the contents of a.txt and b.txt. Checkin (5).* Switch back to branch /main
* Modify the contents of a.txt and b.txt. Checkin (6).
* Merge from (5).Now, you get "Item loaded twice conflict" on b.txt that was cherrypicked earlier. On a.txt that was merged earlier you get no such problem, only a normal conflict.
Could not the Cherrypick operation be modified to include the necessary info to be able to merge it back later?
If we had done a (no-change) Merge from (4) back to /main before the modify-checkin (6), the following merge from (5) would have worked just fine. That seems to indicate that not much extra info is needed to get it working as expected!
An error occurred while saving the comment Göran Wallgren
commented
The following thread is also related: http://www.plasticscm.net/index.php?/topic/3029-new-files-or-folders-committed-with-name-conflict-prefixed/
An error occurred while saving the comment Göran Wallgren
commented
Yet another situation where an identical item can become two totally different unique item-IDs is in Plastic GitSync. Git itself does not version-track folders, and if a merge done in Git involves an added folder then GitSync fails to correctly detect this as a folder-copy-add "Copied (new) / Merged from ..." and instead adds the folder as a new unique item-ID on the destination branch.
When later merged back in Plastic, this can lead to a full delete-add cycle of the added folder. It can also lead to "Changed/Deleted" conflicts and "(name_conflict)_*" renames in further merges.
An error occurred while saving the comment Göran Wallgren
commented
Actually, we could possibly add an even earlier fix step to the list from my previous comment:
0. Add the same "Keep both changes, renaming the destination to ..." option from "evil twin" to the "item loaded twice" as well. (Without this choice, you'll have to lose any changes made to one of the files since the cherrypick.)
An error occurred while saving the comment Göran Wallgren
commented
For a file in an "item loaded twice" conflict, I suppose the initial cherrypick (where the file was added on the second branch) could be chosen as the base/ancestor for that file in a 3-way merge. But that could be a follow-up improvement if it's simpler to implement 2-way merge first.
In the far future, it may even be possible to create a "virtual" ancestor for some of these cases, similar to a "merge recursive": http://codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html
Personally, I think that improvements to this issue could be slowly added over time (since it seems a rather complicated topic overall). I can imagine the following rough prio list:
1. Add 2-way merge resolution for files in "loaded twice" case.
2. Add 2-way merge resolution for files in "evil twin" case.
3. Add (simplistic?) merge resolution for directories in "loaded twice" case.
4. Add (simplistic?) merge resolution for directories in "evil twin" case.
5. Add 3-way merge resolution for files in "loaded twice" case.
6. (Add 2-way merge resolution for files in "divergent move" case, if at all applicable?)
7. (Add (simplistic) merge resolution for directories in "divergent move" case, if at all applicable?)
8. (Virtual ancestors, 3-way merge in remaining cases ???)An error occurred while saving the comment Göran Wallgren
commented
Follow-up: What (I think) I mean by 2-way folder merge is actually this:
* For a "loaded twice" folder, the folder is the same "unique item" on both branches. We should be able to choose keeping one of the parent changesets/revisions while also merging the contents. For each file (inside this folder) that is the same "unique object" in both branches the same option of choose-parent-and-2-way-merge-contents should be auto-applied, according to the same choice that we made for the folder. (This should be applied recursively, so a sub-folder that is "loaded twice" should have the same resolution auto-applied etc.) For a conflicting change in the folder (add/delete/move file etc), that conflict should be displayed in the pending conflicts and be resolved manually.
* For an "evil twin" folder, by choosing to merge contents we acknowledge that we actually intended these separate "unique items" to be the same folder on both branches. Then, we should be able to handle this case (recursively) very similarly to the "loaded twice" case.
That said, please also take the time to read all my previous rambling comments, to follow my train of thought... :P
An error occurred while saving the comment Göran Wallgren
commented
All that ever was asked for in this thread is a 2-way merge. We simply want the extra resolve-options for the cases where the file is meant to be the same (or at least related, which is probably most often the case since they have the same name). 2-way merge is so much better than no merge at all - we just don't want to be forced to discard one of the set-of-changes. This is not so much about the history line but rather about the contents of the file or directory that is being merged. No need to go all complicated and rebuild history!
BUT: While the first solution is fine, it should be implemented for directories too! I guess a "2-way merge"-style join of the contents from the two directories is needed in order to not risk losing added files etc.
Overall, I'm most of all concerned about the case of "Item loaded twice" (where the items really are the same) since it is very easy to get - simply add an item, cherrypick the add, merge back. I've already had this happen a couple of times before I was aware of this problem, during the month that has passed since we migrated from SVN.
I believe if you get "Item loaded twice" on an added directory, you risk losing files in the merge (if they were added between the cherrypick and the merge). Therefore we need the option to do some kind of merging for directories as well. If you want, I can provide more detailed steps for how to reproduce these scenarios.
An error occurred while saving the comment Göran Wallgren
commented
For the "Item loaded twice conflict" it really is the same unique item on both branches, so the natural default would be to keep the parent-linkage on the destination branch.
In most of these twin/twice cases it would make some sense to view an incoming merge an update to the contents of the duplicate item, not as a complete replacement, so again for history it probably is most natural to let the version on the destination branch "live on".
Maybe you could indicate with a text "(recommended)" or simply pre-selecting (or re-ordering) the conflict resolution option that is the "most natural" (preserve destination) and "least dangerous" (one where you don't loose any of the involved modifications). Alternatively you could indicate with a warning text the options where you potentially lose modifications.
Also, an alternative to adding more options could perhaps be a checkbox "Manually merge contents from both items" or similar.
An error occurred while saving the comment Göran Wallgren
commented
Hmm, actually I guess the "Divergent move conflict" could be handled very similar to the "evil twin" and "loaded twice", since it is próbably more important to preserve both modifications to the item contents than to preserve both move operations (the latter are easier to recreate if needed).
Thus, for the "divergent move" we could have the very same two additional options as proposed earlier for the "evil twin". It would merge the [item content] modifications done on source and destination and apply the result to the [item move] operation that you decide to keep.
An error occurred while saving the comment Göran Wallgren
commented
The same additional options "Merge contents and keep the add/move on src/dst" could also be used to better resolve the "Item loaded twice conflict". (The latter can be caused by first cherry-picking an added item and then later merging changes involving the same item.)
On a side note, I also think the "Divergent move conflict" resolve dialog should include options to keep both of the modifications by keeping one move and adding the other as a new item. Otherwise you will always be forced to discard one of the modifications to the item contents.
An error occurred while saving the comment Göran Wallgren
commented
For the evil twin case: I guess part of the problem is that an item can only have one parent revision, and that is why Plastic demands that you keep one of the twins and discard the other.
However, keeping only (the parent linkage of) one of the twin items should not prevent (two-way) merging of the contents from both versions.
Hence, I propose adding not one but two new options for resolving the evil twin conflict:
* Merge contents and keep the add/move done on source
* Merge contents and keep the add/move done on destinationAn error occurred while saving the comment Göran Wallgren
commented
BTW, suppose one has already happened to resolve this kind of conflict by discarding one of the changes. It would then be helpful if there was a way to diff/compare a file (from a workspace or a list of changed files) with another changeset, by ignoring ancestry and just picking the file with the same filepath from the other changeset...
An error occurred while saving the comment Göran Wallgren
commented
Yes! Besides the "Keep both changes, renaming the destination to ..." option, there should be another option "Merge the two items".
As there is no common ancestor, it will be a two-way merge. This is much better than renaming the destination and then manually combining the two (and deleting the renamed one) in a subsequent checkin!
Also, a better handling of the "item loaded twice" conflict occurring when merging a "cherry-picked added item" should be very high prio! (After all, we migrated to Plastic for its superior merging abilities... ;)
Göran Wallgren
supported this idea
·
-
10 votes
An error occurred while saving the comment Göran Wallgren
commented
I have a fast connection at both ends, so it works fine for me to work directly against the server without local clone. Same thing could occur with a slow local disk or a large enough amount of data. Since there is a client-server transfer, progress should be indicated regardless.
Göran Wallgren
shared this idea
·
-
6 votes
An error occurred while saving the comment Göran Wallgren
commented
That's a strange reply, as in the Branches view (List view mode) all the branch comments are downloaded at once and that does not seem to be a problem! Also, when issue tracker is activated, all the issue-tracked branches will have their branch comment displayed in the tree!
I'm thinking you may have misunderstood me? I'm talking about branch-comments, not changeset-comments! (There is only one such comment per branch and that can surely not be a performance hit compared to fetching all the changesets that are rendered? We seldom write novels for branch-comments anyway... ;)
Göran Wallgren
shared this idea
·
-
93 votes
An error occurred while saving the comment Göran Wallgren
commented
OK, here is text from my duplicate uservoice:
Add "Copy" to commands in Items view.
In the Items view, we can Cut and Paste but there is no Copy command. Cut+Paste will cause a Move operation.
Optimally, I'd like to be able to "fork" an item (at least a file) by creating a new Copy/Clone of the item that shares a common history with the original item from the cloning point and backward in time, but that has its own unique history from the cloning point and forward in time. (This was possible in SVN, where it was possible to trace the history of a copied file back into the original file where it was copied from.)
AFAIK, such a Copy operation seems to be missing from Plastic which can only do a move operation. I can see that there may be technical reasons for this, but it would be very nice to have that feature in Plastic. And possibly, implementing such a feature may provide a key to solving the problems described in the following popular uservoice:
http://plasticscm.uservoice.com/forums/15467-general/suggestions/3311147-possibility-to-merge-independently-added-files-dirThat said, even if you are not going to implement a true Clone/Copy operation you could still add a Copy command in the Items view. It would then simply Add a (history-less) copy of the item when doing Paste (just as in Windows File Explorer). It would make these operations more symmetric and consistent. After all, it's a bit strange that we can Move an item inside Plastic but we need to go to the Windows File Explorer to make a simple copy of the same item...
Göran Wallgren
supported this idea
·
-
102 votes
An error occurred while saving the comment Göran Wallgren
commented
The other "exclusive lock" and "Update/Checkin set read-only" mechanisms available in Plastic are only useful when using a checkout-edit-checkin workflow. When using the simpler change-checkin workflow these will not apply.
Therefore the branch-locking feature proposed here could be very useful when using the simple change-checkin workflow. However, there is a limitation to what can be done on other developers' clients, since using this workflow means there is no checkout to indicate the start of a change. Making all workspaces switched to the locked branch become read-only would not be feasible, but we could prevent Checkin to the locked branch and give a warning when someone else tries to initiate a Merge to the locked branch.
We would manually acquire a Lock on a specified branch. Additionally, there could be an option to always lock the destination branch when a Merge is initiated.
The lock could be automatically released when the lock-holder does a Checkin (or a complete Undo) on that branch.
This feature would primarily be useful when doing complicated merges. For normal changes we always have the option to shelve changes or move changes to a new child branch. For a merge, shelving is not a useful option and moving to a new child branch is not a good option either.
An error occurred while saving the comment Göran Wallgren
commented
Some observations:
A "finalized mark" can be easily applied using attributes, which can then be filtered upon and even used for coloring the branches in Branch Explorer (filters and conditional format). By filtering you can hide the finalized branches from view. I believe you could also apply permissions if you really must prevent users from making more changes to a branch.
I agree with the original suggestion here - concurrent reintegrate merges are unnecessarily frustrating, due to the need for explicit merging when having to rebase any additional changes from the destination branch before Checkin. The main problem is that even completely unrelated and trivial changes from the destination must be explicitly merged! (Even Subversion can usually perform a trivial Update even if there is an uncommitted merge pending...)
Some details of what happens in this kind of scenario:
* I am at changeset A when I start to Merge from a task-branch.
* Before I Checkin, someone else merges another task-branch into a new changeset B.
* Now, before I can Checkin I must merge from B also.
* Finally I can Checkin, creating new changeset C.
* Now, B is displayed as a "sub-branch" that is merged into C.I can see why it has to be like this to cover all the possible cases, but I wish the update/merge engine could detect and simplify the trivial cases (all changes are in totally unrelated items, or no conflicts). For these cases we should be able to simply Update the workspace (before Checkin) without causing any sub-branching or explicit merging...
Göran Wallgren
supported this idea
·
-
6 votes
An error occurred while saving the comment Göran Wallgren
commented
A minimal improvement would be to add a Refresh (icon) button in the Diff tab and inline Diff panel.
The Diff tab currently does not even listen to the F5 shortcut, so if the file is changed we have to close and reopen it. A Refresh button (with F5 shortcut) would be very useful here.
The inline Diff is refreshed on F5 but that is only since the whole tab is refreshed. To refresh only the current Diff we need to select another file/revision (in Pending Changes for example) and then select the first one again. A diff-specific Refresh/Recalc button would be useful here too, but F5 would still apply to the whole tab...
That said, I still think Plastic should notify the user whenever something has been changed on disk, similar to the notification about new changesets in the Pending Changes view. It can still be up to the user to perform the actual Refresh action, we just want to avoid missing the fact that we have to do it.
An error occurred while saving the comment Göran Wallgren
commented
You do this at the user's risk of losing changes... And you don't have to do the reload, immediately, just tell the user that there is a new version and ask the user if it should reload! This is how some other Diff tools handle this situation.
Göran Wallgren
shared this idea
·
-
3 votes
An error occurred while saving the comment Göran Wallgren
commented
If it makes things easier, this submenu would only need to be available on "C" and "C_Me" changesets in the 2D (File) History view.
Göran Wallgren
shared this idea
·
-
4 votes
An error occurred while saving the comment Göran Wallgren
commented
I now often use the "View history / as 2D revision tree" commands on a file/folder in the Items view. However, I find it hard to quickly grasp the output since all branches are shown at once. Sure, sometimes I want the big picture of the item's evolution on all branches. But most of the time I really only want to see what's happened on the current branch.
Scaling down my requirements to a bare minimum, I would be quite happy right now with an added command "View history on this branch" in the "Items" / "Repository browser" views. It would work the same as "View history", only filtered to the current branch (so I don't have to filter it manually every time). Following branch-parent links backwards in history would be an extra plus.
An error occurred while saving the comment Göran Wallgren
commented
I don't believe that this is "very specific to my needs". Why then, was this concept so central in how the TortoiseSVN log window was implemented?
Here is the use case scenario:
* I have a large repository with many levels of directories and many branches from several years of development.
* I want to see how one specific subtree or one specific file has evolved on the branch that I'm interested in.
* I don't want to do a lot of clicking, opening and closing of views just to trace the changes back and forth through time.
* I want to stay inside one view (possibly opening and closing one popup window with very quick key presses)
* Using only the keyboard I should be able to select a changeset, read the comment, then select one of the changed items from that changeset, see the diff from that item, walk the diff, then repeat...
* I also want to be able to see the changes made to my subtree/file in the context of the whole changeset where the changes were made.It's currently so close, yet just out of reach. Actually, the 2D revision tree would work fine for this with the following modifications:
* Allow pressing Enter/Escape instead of Ctrl+D/Alt+F4 to open/close the Diff Changeset window.
* When opening the Diff Changeset window from the 2D Revision Tree for a single file, pre-select that file in the changelist.
* Add dimming (and optional hiding) of the unrelated items (those outside the subtree/single-file filter) in the changelist inside the Diff Changeset window.Also, please change the strange error message (in the inline diff for a subtree) into something understandable... ;)
An error occurred while saving the comment Göran Wallgren
commented
Additionally:
While the History view can become hard to read due to parallel changes on multiple branches being intermingled chronologically, the 2D Revision Tree view is much clearer since the branching is visualized and you can easily follow one branch through time in that view.
For a single file, it makes sense that the 2D Revision Tree displays the diff for that file when I select a changeset.
However, for a subtree the selection of a changeset in the 2D Revision Tree only results in the very strange error message "Filesystem permissions changed from NOT_DEFINED to NOT_DEFINED" in the inline Diff panel. Here, it would be very nice to have instead an inlined changeset-diff viewer. What I mean is a normal inline Diff panel, except with a left sidebar where the changed items (from the selected changeset) can be chosen for the Diff.
An error occurred while saving the comment Göran Wallgren
commented
Follow-up: Oh wait, I see the difference. When viewing the "History" of a selected file or subtree (in a workspace switched to a task-branch), that history continues into the past (and the future) by following branch creation and merges etc. It also bounces back and forth between branches (in chronological changeset order) if parallel changes were made. The "Explore" window, on the other hand, only views the task branch at hand.
This worries me quite a bit, because it means that the History view is not at all what I want to have! What I really want can be formulated as follows:
* In a workspace switched to A SPECIFIC BRANCH, select a file or subtree root.
* Display a list (in decreasing chronological order) of all the changesets ON THAT BRANCH that are relevant to the selection.
* When the list comes down to the creation point of THAT BRANCH, it should follow history of the selection back to the originating branch. (Since it's a Directed Acyclic Graph, it should always be possible to trace history back onto main (eventually) and back to changeset 0, or at least back to the actual creation of the selected file or subtree.
* There should be no intermixing of changesets from other parallel branches in the list. I want to follow the PARENT LINK of every changeset and exclude the ones where no change was made to the file or subtree.
* When selecting a changeset from the list, there should be an inlined list of changed items from that changeset. Items besides the selected file or subtree should be displayed as dimmed and optionally hidden.
* When selecting one of the changed items, there should be an inlined diff view of the changes in that item.
As you can see, what I want is almost exactly the "Explore changesets" window/view, only:
* filtered to file/subtree
* in descending order
* continuing into the history of the parent branchAn error occurred while saving the comment Göran Wallgren
commented
Thanks, I understand why you created the Explore window and I appreciate if you would add inline diff to the History view. However, I don't see the big difference between these two.
What I requested here was a filtering of the Explore window just as you filter the History view. If you are on a task branch and filter the Explore window to the workspace root you would get the same exploration-view as by "Explore changesets on this branch" for that same task branch. Am I wrong? Wouldn't that also basically be the same view as "View History" for the workspace root?
All that said, it would be fully OK with me if I could view diffs in "View History" instead. I just think that the "View/Explore" would then become so similar that you could merge them...
An error occurred while saving the comment Göran Wallgren
commented
Also, to indicate (for one of the included changesets) any changed items that fall outside the filter, they could be displayed in a dimmed grey color.
TortoiseSVN does it this way in their log window, when launched on a selected folder or file.
They also have a checkbox "Show only affected paths" that allows you to hide these other changes and focus on the subtree or single file that you had selected initially.
Göran Wallgren
shared this idea
·
-
41 votesGöran Wallgren
supported this idea
·
Actually, if I bring up the 2D history tree for a directory to see what changes are done to items in its subtree 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.
Therefore I strongly wish for an option to display even (seemingly?) "unrelated" merge arrows, BUT only for the changesets that are already shown - NOT as in the option "Display all merges in history" which is frankly rather useless to me.