git lfs file locking support?

[TomaszSzt]

Hi,

First, this is a great product. I was able to set up two instance of server within 1 hour is. It is a great experience compared to a failed attempt to set-up two instances of GitLab. The GitBlit is also so simple to admin!

But...

Can we have git-lfs lock support? Currently it is not supported, I think (v1.8.0). I am getting something like:

D:\x\lfs\lfs>git lfs lock kanji.uni
Lock failed: Repository or object not found: http://---------------:8090/r/lfs.git/info/lfs/locks
Check that it exists and that you have proper access to it

Can we have it done?

I know that locking is not a well viewed for source code edition and I agree with that. But I do currently try to extend the intended use of GIT to store the mechanical drawings and etc and those are non-mergable. So ideally I would be glad to be able to lock files for editing and ensure, that anyone who:

• checks them out is getting the "read-only-files";
• attempts to push them is stopped;
• can inspect the lock status through web interface.

Without this I will be, sadly, forced to start admining the GitLab what would be a pain.

Best regards, Tomasz Sztejka.

[flaix]

You are running version 1.8.0, not 1.9.1?

This is a good request. I'm afraid I won't get around to implement it soon.

[chirontt]

@TomaszSzt,
You want to control a remote repo down to individual files, via some locking mechanism. Wouldn't it be better to use a document-management application which would give you these fine-grained controls, instead of git or gitblit? These document software would allow you to "reserve" a document so that nobody else can work on it until you "release" the document and clear the lock.

Another point: you want a centralized repo to control individual files? Just throw out git (or gitblit) and use a centralized revision control software instead like CVS, Subversion, Rational ClearCase, etc. I'll be interested to know if GitLab can do this kind of central control of individual files.

In short, I think a distributed version-control software like git is the wrong tool for your purpose, because you want a centralized control of the files via some locking mechanism, even at the local repo that people have cloned which is impossible. This is quite against the distributed nature of git!

[flaix]

While it is debatable in how far locking for LFS makes sense or not, I guess Tomasz simply refers to LFS locking as it is part of Git LFS 2.0.

[TomaszSzt]

Thanks for quick response.

Yes, I am talking about LFS locking.

@chirontt I am aware of all what You said. The company I work for is now using Autodesk Vault (something live CVS) for such a purpose and I can tell You it is a complete mess. The critical thing about version control system is not only versioning of "files" or "repositories" but also capturing the "dependencies" between files, so that if You take out file A in version 1.0 from project P then You can say (and track, monitor, inspect) that this file needs file B in version 3.4 from project X. You know, something like: "a user guide version 5 should be provided with printed circuit board version 7".

And I'm talking about cyclic-criss-crossed dependencies here, so even GIT is shedding tears here - I needed to write own tools to track it because sub-git dies in such case.

What is good about GIT it is that in simplest case it captures the "snapshot" of a project, so at least You don't have to worry about dependencies inside a project. This is a great plus for users.

The place I work for is understaffed and I was hoping to get a solution which is extremely simple to admin. Believe me, GitBlit is best - no database, no external dependencies, single folder to backup, single excellently documented configuration file to read and modify. No SSH is necessary so I could remove one of potential breaking entry. Nothing except JRE8 is needed. I was able to move server between Linux and Windows without any problems.

Gitblit has a decent web GUI, so no external application is needed to inspect repositories and download them if "read-only" work needs to be done. That way I can use it as a kind of poor man "document distribution center".

And it can run in two copies on the same server serving different content at different ports. This is also important so my team members can train on "testing server" without risking breaking of "production server".

Quality is also good, there a logs and etc. The only bug I have found up to now is when file contains ()[]{} in a name, but it might be GIT problem and can be ruled out by simply not using such names.

So I was thinking: Since it works well for source code, shouldn't it work at least equally good for binary, non-mergable files?

Git works well. As long as I work with a tiny team it is not a problem without file locks. So I came to think: since git-lfs has locks, why not try to use it? It looks good for me and should suit my needs and it will be a single server, single tool chain, single resource and what is important: single training for my non-programmers team members. I am strongly against using two tools - one to server non-mergable documents, and another to serve mergable. Especially often because the ODT or DOC/PDF specs are part of software specs.

@flaix I'm against "update,update,update!" policy. If something is working, why try to break it? I did inspected 1.9 release notes tough and did not found anything what would make the risk of upgrading reasonable.

I do understand that You are not having a free time to spare. Its fine, I also do refrain from coding in my free time, we all have lifes to live.

I did try to inspect source code for GitBlit, but I'm totally green when it comes to jetty, json and that level of techniques. There are also far to less comments (esp. generic ones, like overview.html, package.html and etc) for me to quickly guess where should I look for it. I am also not very fluent in Git administration and still learning.

I think about two possibilities:

1. Adding this functionality to GitBlit by my self. I think it is doable, providing You will be so kind, and point me to some starting points in Your code.
2. Setting up git-lfs as a "side channel" using separate server. This is however a total mystery for me and I have no blind idea if it is even possible?

Best regards
Tomasz Sztejka.

P.S. The GitBlit is "mature" now, right? Maybe it is a good time when someone who knows the code should write a kind of "guide", "overview" or something like that and put it in sources? Like, this package does that, this is read by Jetty to do that, this is..... It would really, really x100, help people like me to add fixes. It would let us figure out a proper source file within few hours instead of few days.

[flaix]

I would be happy if I had a "guide", or well documented code and architecture. But there is no such thing. I would also be happy, if the code were well covered with unit tests, so that refactoring it would be less risky. But again, no one really wants to tackle that task. So I'm left with doing little improvements, step by step.