Locking files with LFS

[Cédric OLIVIER]

Hi Gang,

I'm trying to setup an LFS Filestore on a test server, using GitBlit. So far, no problem, I managed to transfer an existing git repository from another test server, setup our ldap credentials, etc... and GitBlit has been very cooperative and straight forward.

I mostly followed the instructions from this page on how to add git-lfs to an existing repo and it all worked as expected. I can now see all the files I wanted tracked by LFS, in the GitBlit's filestore.

https://github.com/git-lfs/git-lfs/wiki/Tutorial

I could also modify, stage, commit and push existing files, but when I try to lock one, this is the error I get:

$ git lfs lock TestProject/Content/Weapons/M_Rifle_01.uasset

 Lock failed: Repository or object not found: http://coli...@192.168.1.36:8080/gitblit-1.8.0/r/test_project.git/info/lfs/locks

 Check that it exists and that you have proper access to it

I tried to change the access permissions on the repository and/or GitBlit, but the same issue remain.

I'm using git-lfs/2.0.2 (GitHub; windows amd64; go 1.8; git 85e2aec4) on the client side, and the server is running on a Ubuntu 16.04, with Tomcat8 (8.0.32-1ubuntu1.3) and openjdk (1.8.0_121).

Let me know if you need more details.

Does anyone set locking file up with GitBlit? Could have I missed something in the setup?

Thanks in advance for your help.

Cheers,

Cedo

[Paul Martin]

Hi Cedo, it's almost 2 years ago that I developed the LFS support and it seems the team working on the LFS protocol have made some updates, locking being one of them https://github.com/git-lfs/git-lfs/wiki/File-Locking hence this feature is not supported.

TBH I don't understand why they would add a lock feature, it may seem useful on the surface but the whole locking concept makes no sense on a distributed repository.  Locking will prevent pushes but not commits so unless I've missed something it will not prevent merge conflicts. 

Gitblit stores each version of an LFS file so there is no worry about loosing changes. If I recognise the file type correctly you're using Unreal - It does have a diff capability for assets and blueprints (https://www.unrealengine.com/blog/diffing-unreal-assets). 

On that note I have noticed Unreal is keen to update timestamps in uasset files when simply opening a blueprint or shifting the display a little even when there have been no logical changes, this may be the cause of some merge conflicts but as described above locking will most likely not solve it unless you have a strict 1 commit per push workflow.  Also if you're using the inbuilt Unreal git functionality do be cautious about what it decides to commit, a while back I noticed that I was missing a bunch of critical project files.

Hope that helps,

Paul

[Cédric OLIVIER]

Hi Paul,

Thank you for the detailed and honest answer.

I will take all those points in consideration. Basically, I'm trying to run some tests with locked files to ease people coming from an Helix Perforce environment.

Thanks for the input, it will help for sure.

Cheers,

Cedo

[Ingmar Clarysse]

Hi Paul, 

That's the thing with binary assets you do not want merging in the first place. Not ever really. Although there is functionality for blueprint and materials in unreal to diff and merge, its not practical and never used. I worked in the game industry for the past 20years in teams in excess of size 20 to 150. We never had a situation where we needed or used a diffing and merging of binary assets. Usually any existing diffing of binary assets is a curious novelty that actually isn't really practical nor used in development. What is direly needed at all times is exclusive check out. When 1 developer works on a binary asset, only that person should be able to edit, commit changes and when done push his changes. All else in the team should clearly see the file is locked, not be able to check it out, change it nor commit changes to their local repos. Untill the person that has it checked out checks it in and pushes to the server/remote repo. Which releases the file. We obviously used perforce for most of our career. I started to use GIT and I love its distributed repository, but that doesn't mean we don't need a file locking system badly to preven any merging ever.

Kind Regards,

Ing