If checkin policies are enabled via enable_checkin_policies_support.bat
the git-tfs binary is modified via CorFlags to run as a 32bit process,
as the checkin policies are only available in 32bit (not sure if this
is still the case for VS2022, but at least for VS2019 and VS2017 this is
the case).
The code uses internally a different code path if it runs as 32bit process,
as the corresponding libraries to enable loading the private registry
only works in 32bit. Commit a515071e ("Add support
for checkin policies for VS2017 and VS2019", 2020-11-02) introduced
the support for loading the private registry where e.g. installed
extensions and/or code review policies are stored, but it accidentally
had some debugging leftovers trying to access a specific registry key.
This key does not exist if no VS extensions and/or checkin policies are
installed and therefore made the git-tfs application terminate with an
exception.
Remove this dead code and fix this error, which was noticed when testing
the VS2022 support whitout any extensions installed.
The Visual Studio 2019 image includes git 2.33.1, which is needed
to test git-tfs' new --initial-branch option. The Visual Studio 2017
image used previously includes git 2.26.2, which does not support
the --initial-branch option.
In certain cases of legacy TFS projects using Changeset::WorkItems could cause
a WorkItemTypeDeniedOrNotExistException (error TF201077) and cloning process
stopped. This change uses AssociatedWorkItems instead which works fine even
in this case.
The URLs to the WorkItems were not working. The old form generated uses
the following format
https://some.server.com/tfs/tpc/WorkItemTracking/WorkItem.aspx?artifactMoniker=<ID>
Accessing it in a browser actually leads to the following error on a
a TFS 2020 (Dev18.M170.8) server:
"TF200016: The following project does not exist: WorkItemTracking. Verify
that the name of the project is correct and that the project exists on the
specified Azure DevOps Server."
Fix it by using the `TswaClientHyperLinkService.GetWorkItemEditorUrl`
which generates the correct URLs of the form
https://apollo.healthcare.siemens.com/tfs/web/wi.aspx?pcguid=<PROJECTCOLLECTION_GUID>&id=<ID>
Another benefit of this change is that we no longer need the URI from the
WorkItem, as the URL is build completely from the ID, which enables a later
refactoring (not done in this changeset) to use the `AssociatedWorkItems`
(see comment in `HasWorkItems`) instead.
This makes it clearer that checkin policies are supported now, as before
we mentioned them explicitely as "not supported yet" in the entries where
VS 2017 and VS 2019 where introduced.
I reflowed the paragraphs, so this is best reviewed with
`git diff --word-diff`
This implements the support for Visual Studio 2019 by adding a VS2019
paket group. It is heavily based on the plugin for VS2017, as the
GitTfs.VS2017 plugin was initially copied to server as a base for this
new GitTfs.VS2019 plugin. The actual logic business logic is contained
in src\GitTfs.VsCommon\TfsHelper.Vs2017Base.cs and is shared between
both plugins.
HINT: To see what actually was changed after the GitTFS.VS2017 was copied,
use e.g. `git show -C50 -C HEAD` to spot the differences in the review.
This implements the support for VS2017 by implementing the necessary
logic to enumerate the installed VS intances. As of VS2017, multiple
Visual Studio versions can be installed in parallel, e.g. a Enterprise
and a Professional edition. Furthermore, it also supports installing
the same edition in multiple different versions.
The logic implemented in this commit will always use the first version found
with a matching major. As it isn't clear that the used underlying mechanism
to iterate over the installed versions is deterministic, this means that
if multiple versions of VS2017 are installed in parallel, we may find
different instances between seperate calls.
A typical user doesn't have multiple versions of the same VS major
installed, but instead it is much more common to have different major
vesions like e.g. VS2017 and VS2019 installed.
Therefore, finding the first VS2017 version is acceptable for now. Selecting
different editions or different versions of the same major can be done
later if it is needed at all, especially as testing this requires
a lot of work due to the need of installing multiple versions or editions
of Visual Studio.
Otherwise, the build is not completely reproducable and depending if there
is a new paket version available, due to its autoupgrade it will mess with
the checked in file src/.paket/Paket.Restore.targets and cause strange
conflicts.
This commit has proven usefull when dealing a long running branch of patches
to the paket.dependencies and/or paket.lock file.
In a4c76e2f ("Performance improvement - cache the branch objects instead
of looking them up over and over", 2019-06-25) introduced via PR #1286
the filename conflict on case insensitive filesystems:
doc/release-notes/Next.md
vs
doc/release-notes/NEXT.md
The later name is the one already existing and what is used throughout
the history, where as the former one wasn't used at all before.
Merge the two files and remove the wrong doc/release-notes/Next.md one.
While I am alrady modifying the file, add the reference to the pull requests
to the changelog entries.
git rebase --rebase-merges commandline switch was introduced in Git
version v2.18.0 (released on 2018-06-21) to replace the --preserve-merges
commandline switch to git rebase. Since v2.22.0 the old --preserve-merges
is offically deprecated.
Replace the deprecated usage of --preserve-merges with the newer --rebase-merges
option on all occurences.
The decision was made that the git version v2.18.0 as the minimum required version
is reasonably old enough to assume that the user has it (or a newer version)
installed on his machine. Therefore no version dependend logic on which
switch to select was implemented here.
Building the MSI is not working since 6732259 ("Moving source in
the 'src' folder", 2017-10-13) and when actually looking at the
GitHub releases, the MSI is not attached to any of them.
The MSI file was never distributed on any GitHub release and using
copy deployment zip file is much more conveniant, because it allows
having multiple versions available.
Therefore, remove the GitTfs.Setup code and the upload function
in the cake build file.
The global property `InitialChangeset` is used to store the first changeset the user want to clone from.
But this was also in some situations used to store the first changeset of a branch. This cause a problem as this property is global and will be applied to all branches. If `InitialChangeset` is set for a branch, the next cloned branch can not get the changesets before the changeset given this `InitialChangeset` if it is not updated for that branch to.
It is problematic to use a property for different information.
Fixes issue where the wrong parent is selected for a merge if the
correct parent consists entirely of files that were modified in earlier
changesets in the merge (it was selecting the highest "version FROM"
instead of "version TO").
* Update Application manifest
* Update App.config
* Upgrade to .net 4.6.2
Support in win10 for long path should be enabled:
In the Local Group Policy Editor ("gpedit.msc") navigate to `Local Computer Policy` -> `Computer Configuration` -> `Administrative Templates` -> `All Settings` ->`Enable Win32 long paths`.
Set it to `Enabled`.
https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/
fineol