Add the Multi Workspace workaround to the PathTooLong issue

[patricecalvehoc]

[x] run and verify that existing tests pass. Add some new units tests, if needed.
[x] update the documentation, if needed.
[ ] update the release notes file NOT done...

There are situations where the workaround of using a very short path for a custom workspace is not enough.

The solution implemented leverages a TFVC workspace's ability to have multiple Working Folders. A new git tfs clone argument was created --MultipleWorkingFoldersConfigFilePath that allows the user to specify a json file containing an array of folder mappings that are passed along to the creation of the Workspace. These mappings are "SourceControlFolder" and "LocalFolder".

• SourceControlFolder: TFVC path ($/...) triggering the Path too long
• LocalFolder: a local folder (shorter the better) where the items will be mapped to.

I've updated the doc/Set-custom-workspace.md with the instructions and an example/scenario

[pmiossec]

FYI, no need to open a new PR when you do changes. You just have to push the new commits (with a force push if needed when exceptionally you rewrote the git history)

[pmiossec]

I have noticed also some other little refactoring to do quicker to do than explained. Unfortunately, I can't push them 😭

The "Maintainers are allowed to edit this pull request" option is checked, which is good.
But you have created the PR from the master branch which is, FYI, a bad practice (for multiple reasons).
When you want to contribute to a project, always create a feature branch, with a good naming and create the PR from there.

So, could you please fetch the commits I pushed to my fork ( https://github.com/pmiossec/git-tfs/tree/patricecalvehoc/master ), review it and if that's OK for you, squash everything (again 😉 ) in one commit and force push to your branch?

I think that technically the code is OK.
@siprbaum do you want to review it also?

The only question that I have in my mind that could prevent to merge this PR (i.e. reject it) is:

Why the "short workspace" and/or long path solution is not enough? and so is this proposition really improving the situation?

I don't have a case to test it and confirm if it really works but in another end, if you have migrated a code base using it, I think we could be pretty confident that it is working 🤣 .

I'm ready to accept it as another way to work around the long path issue (if "short workspace is not enough) as the code seems easy to maintain and also this provide a full "git-tfs" solution to the problem (user don't have to change a system setting that could have other side effects otherwise Microsoft would have enabled it by default since a long time -- right!?! Because that's really a pain this limitation when you encounter the problem--)

@siprbaum point of view?

[patricecalvehoc]

I need a good course on "github" :( Sorry for the back and forth. I will make the changes you ask.

In our TFVC, we have an item that is 264 characters long.

If I want to retire the old TFS server, but keep/protect each project's source code history, git-tfs is a great tool. The other solution would be to fast-forward the upgrades from TFS to a recent ADOServer version, then use cloud migration utility, but it's a path I didn't want to try if avoidable.

[siprbaum]

AFAIK there is no DOS in the supported list of languages.
https://github.com/github-linguist/linguist/blob/master/lib/linguist/languages.yml

Maybe change this to sh ?

[patricecalvehoc]

Agreed..

How about Shell

https://github.com/github-linguist/linguist/blob/master/lib/linguist/languages.yml#L6472

?

[siprbaum]

I haven't thought much about this, so take my comments with a grain of salt.

With the above change, we now we have different behavior if a file exists or not at a specific path,
which makes me nervous. Should we not always return this._workspace.GetLocalItemForServerItem($"{Remote.TfsRepositoryPath}/{path}")

[patricecalvehoc]

Very good point... Good catch

Example:
$/SomeTeamProject/Foo/FileXYZ.txt
$/SomeTeamProject/FolderSuperLong/Foo/FileXYZ.txt

if git clone $/SomeTeamProject --workspace w:\ --MultipleWorkingFoldersConfigFilePath c:\mapping.json

and mapping.json:

[
  {"$/SomeTeamProject/FolderSuperLong" : "x:\1"}
]

Then, there will be

W:\Foo\FileXYZ.txt ($/SomeTeamProject/Foo/FileXYZ.txt)
X:\1\Foo\FileXYX.txt ($/SomeTeamProject/FolderSuperLong/Foo/FileXYZ.txt)

They are two different files.

With the code I proposed, when looking for $/SomeTeamProject/FolderSuperLong/Foo/FileXYZ.txt, the first check will be using var localPath = Path.Combine(_localDirectory, path);, and will find one under W:\Foo\FileXYZ.txt but will be the wrong one.

[siprbaum]

@pmiossec I am currently lacking time to do any OSS work at all since quite a while now, that is why I am lacking behind :-(

I did a very quick glance over the PR, it seems isolated so I don't see a reason (besides complete lack of tests)
why not to integrate.