This instance will be upgraded to the latest Heptapod 0.20rc on 2021-02-26 at 11:00 UTC+1

  1. 19 Jan, 2021 1 commit
  2. 03 Jan, 2021 4 commits
  3. 01 Jan, 2021 2 commits
  4. 31 Dec, 2020 5 commits
  5. 11 Nov, 2020 1 commit
  6. 25 Oct, 2020 1 commit
    • Colin Hurley's avatar
      Show Uncommitted changeset group above Secret changeset group · a755930f7c21
      Colin Hurley authored
      When a single repository is being synchronized, all repository groups appear at the top level in the view. Since the Uncommitted group and Secret group both use the LOCAL direction, the two groups would normally be ordered by name, which would place the "Uncommitted" group below the "Secret" group. This commit adds some instanceof checks to tweak this ordering so an UncommittedChangesetGroup (i.e. the "Uncommitted" group) appears above all other ChangesetGroup instances (including the "Secret" group).
      
      The Secret group is still shown above the Incoming and Outgoing groups. This shows work-in-progress commits (Uncommitted and Secret) together near the top of the view. Thanks to changesets appearing in descending order of revision number, this also has the advantage of helping minimize vertical movement of changesets in the view when changing between draft and secret phase. For example, shifting changesets from secret phase to draft phase will tend to remove them from the bottom of the Secret group and add them to the top of the Outgoing group below (depending on the exact history graph, of course). This should help the user more easily track changeset movement between groups, especially if the groups contain a large number of changesets.
      
      Refs #624
      
      --HG--
      branch : issue624-sync-secret-changesets
      a755930f7c21
  7. 19 Oct, 2020 1 commit
    • Colin Hurley's avatar
      Add Secret changesets to the Synchronize view · 7eff5ddbac14
      Colin Hurley authored
      A "Secret" changeset group now appears in the Synchronize view alongside the existing "Incoming" and "Outgoing" groups. Many of the context menu commands for outgoing changesets are also enabled for secret changesets, including the Undo menu and patch export commands. In addition, a "Change to Draft Phase" command has been added. Along with the existing "Change to secret phase" command, this enables easy shifting of changesets between the Secret and Outgoing changeset groups from within the Synchronize view.
      
      Notably, the ability to directly push secret changesets has not been implemented here. This is partially because the hg push command itself ignores secret changesets, even when specified directly with the -r option. In addition, when the user selects a project/repo and executes a "Push" operation, it is ambiguous whether the intent is to push secret changesets or only the outgoing changesets. With this in mind, the MercurialEclipse behavior follows the vanilla Mercurial behavior - namely, the user must explicitly shift a changeset from secret to draft phase before it can be pushed.
      
      Each repository's set of secret changesets is cached in the LocalChangesetCache. Like other cached local changeset information, clearing the cache data for a repository root also discards the cached set of secret changesets, allowing the set to be re-fetched after an update. This happens, for example, when the RefreshRootJob is executed with the LOCAL flag. Phase-shifting UI actions do this when they execute a PhaseJob.
      
      Secret changesets are loaded from the cache by HgChangesetsCollector. This class then passes the changesets along to HgChangeSetContentProvider, which updates the model and the display. This makes heavy use of the existing infrastructure that already displays incoming and outgoing changesets in the view.
      
      Refs #624
      
      --HG--
      branch : issue624-sync-secret-changesets
      7eff5ddbac14
  8. 16 Oct, 2020 1 commit
    • Colin Hurley's avatar
      API cleanup: Use JHgChangeSet exclusively in LocalChangesetCache · ad12a72b9b5f
      Colin Hurley authored
      LocalChangesetCache had a few cases of using the ChangeSet class, which is a parent class that JHgChangeSet and WorkingChangeSet extend. Since LocalChangesetCache only works with changesets actually committed to the Mercurial repository, there is no reason to not use JHgChangeSet throughout the class (i.e. this is the only type of changeset that this cache works with).  Therefore, the few uses of ChangeSet use have been adjusted to use JHgChangeSet instead.
      
      Also fixed a javadoc deprecation reference
      
      --HG--
      branch : issue624-sync-secret-changesets
      ad12a72b9b5f
  9. 01 Oct, 2020 3 commits
  10. 22 Sep, 2020 1 commit
    • Colin Hurley's avatar
      Fix typo · dca555d5d4f6
      Colin Hurley authored
      --HG--
      branch : issue624-sync-secret-changesets
      dca555d5d4f6
  11. 26 Aug, 2020 4 commits
  12. 25 Aug, 2020 1 commit
  13. 16 Aug, 2020 1 commit
  14. 08 Aug, 2020 4 commits
  15. 06 Aug, 2020 1 commit
  16. 04 Aug, 2020 1 commit
  17. 03 Aug, 2020 1 commit
  18. 11 Jun, 2020 2 commits
    • Colin Hurley's avatar
      Cleanup - Refactor isInitialCommand field to awaitHgInit in CommandJob · fc7194e2e129
      Colin Hurley authored
      The isInitialCommand logic was confusing.  As I tried to make sense of it, I found that it also had a logic error.  I believe the intent was for the job to wait for hg init to complete unless the isInitialCommand constructor arg is true (i.e. the command is doing the hg init itself) or the hg init has already occurred.  I assume this was done to avoid unnecessary invocation of the await method on the countdown latch in MercurialEclipsePlugin.  However, due to an inverted logic check, the await would occur in all cases except if the isInitialCommand constructor arg is true and the hg init has NOT been done.  Functionally, this still controls startup execution ordering correctly, but the negated logic causes the latch's await method to ALWAYS be called after init is done, rather than NEVER.
      
      I have refactored the isInitialCommand field into a new awaitHgInit field.  This refactoring should make it clearer how the field is used and under what conditions any "waiting for init" will occur.  That said, a countdown latch returns immediately from its await method if the latch has been counted down already, so the MercurialEclipsePlugin.isHgInitDone() arguably doesn't need to be there in the first place, assuming it was done for performance reasons or to avoid accidental post-init blocking.
      
      --HG--
      branch : issue624-sync-secret-changesets
      fc7194e2e129
    • Colin Hurley's avatar
      Cleanup - Hide countdown latch implementation detail · 6d6f8d6747a1
      Colin Hurley authored
      In MercurialEclipsePlugin, the START_SIGNAL field is now private.  This field is used to control execution order when the plugin is first starting.  The fact that a countdown latch is used is an implementation detail and should not be exposed to other classes.  The isHgInitDone method replaces direct access to the field and improves code readability.
      
      --HG--
      branch : issue624-sync-secret-changesets
      6d6f8d6747a1
  19. 05 Apr, 2020 3 commits
  20. 01 Apr, 2020 2 commits