bozaro
commented
7 years ago What is VSO?
Open hcoona opened 7 years ago
bozaro
commented
7 years ago What is VSO?
hcoona
commented
7 years ago hcoona
commented
7 years ago I convert the repository via following command:
$ git clone --mirror https://shuaiz:$PAT@msasg.visualstudio.com/DefaultCollection/_git/Multi
%20Tenancy source.git
$ java -jar /mnt/d/GitProjects/git-lfs-migrate/build/deploy/git-lfs-migrate.jar -s source.gi
t -d target.git -l https://shuaiz:$PAT@msasg.visualstudio.com/DefaultCollection/_git/Multi%20Tenancy.git/info/lfs "*.exe
" "*.dll" "*.pdb" "*.zip" "*.gzip" "*.jar"The repository is private and sorry for that I cannot grant you to access it. But I tried other repositories also meet this issue.
dampcake
commented
7 years ago I am also running into the same exception :(
zivillian
commented
7 years ago I had the same error with TFS2017 and wrote a small and dirty workaround.
The first problem is, that TFS returns a Transfer-Encoding header, which will cause the above error Transfer-encoding header already present. My second problem was, that the PUT requests missed the Authorization Header.
I haven't tested this againts VSO only against OnPrem TFS2017.
The commit can be found at zivillian/git-lfs-migrate@a1a1d5e8bf67818461cb71f0a2de2d0740d1399c
deAtog
commented
7 years ago This issue is not limited to VSO, and is an issue with ru.bozaro.gitlfs.client.Client. At line 274 of the source file for ru.bozaro.gitlfs.client.Client, in the doRequest method, addHeaders is called to add the appropriate headers for the request created on line 273. The subsequent call to http.executeMethod on line 275 to process the request fails because the "Transfer-encoding" header is being sent multiple times.
~~A possible solution to this issue may be to replace line 325 of ru.bozaro.gitlfs.client.Client with:
req.setHeader(entry.getKey(), entry.getValue());
as this ensures that a header will be replaced if it exists, and added if it does not.~~
Upon further investigation this issue is caused by multiple threads obtaining and using the same HTTP connection during the upload process. I'm still attempting to determine the cause and resolution for this, but signs are pointing towards the BatchUploader and the shared HttpClient instance.
hcoona
commented
7 years ago Greate progress, thank you deAtog!
bozaro
commented
7 years ago I created test repository on VSO and would fix this issue soon:
deAtog
commented
7 years ago I'm still not sure what the correct fix is for this is. My understanding of how the HttpClient should work when using the PoolingHttpClientConnectionManager is that a pool of persistent HTTP connections are created. These connections are then shared whenever a request is executed by the HttpClient by taking an unused connection from the pool and returning it once the request has completed. By default, the size of the pool is limited to 2 connections per host. My understanding is that it the use of the PoolingHttpClientConnectionManager should prevent two requests from using the same connection at the same time. This however does not appear to be the case.
A simple work-around for this issue is to populate the destination repository with the LFS objects, by NOT specifying the git repository or lfs server with -g, --git, -l, or --lfs options to git-lfs-migrate. This will cause git-lfs-migrate to populate the destination repository with the lfs objects which can subsequently be pushed using git lfs push according to directions here: https://help.github.com/articles/duplicating-a-repository/#mirroring-a-repository-that-contains-git-large-file-storage-objects
Hi there,
It seems that this tool cannot work with VSO hosted Git repos.
The error message are shown below:
I tried to ignore this error. After that, I cannot checkout from the converted repo. Error message shown below:
The content of
/tmp/test-target/.git/lfs/objects/logs/20170323T163817.1322287.logis shown below: