5 ms·

Without locking this is largely useless. Usually large files are binary blobs(PSD, .ma, etc) and it becomes incredibly easy to blow away someone's work by not

Without locking this is largely useless. Usually large files are binary blobs(PSD, .ma, etc) and it becomes incredibly easy to blow away someone's work by not pulling before every file you edit(or two people edit at the same time). As much as some people hate Perforce that's exactly what they are setup to do. Plus their binary syncing algorithms are top-notch. We used to regularly pull ~300GB art repo(for gamedev) in ~20 minutes. Git is great for code but this seems like square peg, round hole to me.

alkonaut 11y ago
Won't a central storage for the large files alao make it straightforward to add locking functionality in a future version of git-lfs, or as an add-in? I agree it sure looks like an omission to have a vcs that is centralized and aimed at binary data, without having any locking functionality.
- vvanders 11y ago
  Yeah, but that's assuming a whole lot of infrastructure around marking files read-only. I also haven't seen what the pull performance is like, P4 is a pretty known quantity(with caching as well).
  - alkonaut 11y ago
    I don't even necessarily need my client to mark files as read only on my local machine. A system that just lets me query who has the lock on a certain file, and lets me get the lock on it if noone has, is miles ahead of shouting/email. A remote-only locking system should be pretty easy to implement, e.g by just throwing in "filename.userid.lock" into the filesystem next to the file in question.
    - sytse 11y ago
      We plan to add locking to the GitLab web ui at some point. At least this will prevent two people from locking the same file.
icebraining 11y ago
Git annex solves this without locking nor losing any of the versions - the actual files get different names (based on hashes of the contents), which are referenced by a symlink tracked by git. If two people edit the same file - pointing the symlink at different filenames - you get a regular git merge conflict.
- vvanders 11y ago
  That's the thing with binary assets, there is no merge path due to them being binary by nature.
  - LukeShu 11y ago
    No /automatic/ merge resolution. Obviously you have a tool that can open them (if you edited it in the first place), and you can use that to view the differences, and replay one set of changes. The fact that the SCM detected the conflict, and alerted you, allowing you to resolve it, is a solid improvement over not using an SCM. Further, automatic merge resolution isn't always possible with text-based assets either (and even when it is, it isn't always the correct option!).
    - vvanders 11y ago
      I don't think you follow. Programs like Photoshop, Maya and 3DSM don't merge. Period. Your only option in this case is to throw away someone's work and force them to redo the work on the file that you decided to keep.
      - deleted 11y ago
        [deleted]
      - LukeShu 11y ago
        Programs like gedit don't merge. Period. Yet I can still use it to resolve a merge conflict. In Photoshop you would do this by opening both images, and visually comparing them to see what's different, then copying the appropriate parts from one to another. Instead of just visually comparing them, you might combine them into one file as separate layers, and use a transform to see the difference. If the tool doesn't support that, use ImageMagick to generate a graphical diff (either the `compare` or `compose` commands), and then copy the relevant parts from one to another. We have fancy tools to help us, but fundamentally, merging is a /human/ operation, that requires human judgment to see how multiple sets of changes can be made to coexist. And that doesn't require a tool (though it can certainly help).
jayd16 11y ago
Except perforce has been moving towards streams to compete with git's more desirable workflow, and you can't lock across streams anyway.
bmurphy1976 11y ago
Translation: because it is not useful for you it's not useful for anybody else. That's nonsense of course. There are a lot of use cases where this would be very helpful without locking (i.e. jar/dlls). This is useful now, locking can come later. We don't have to solve every conceivable problem all at once. More progress is made in small incremental steps than big bang leaps.
luckydude 11y ago
I've read the replies to vvanders and he's correct. With binaries you really want some sort of global locking (easy with a centralized system, hard with a distributed system). I believe his (her?) point is that for a very large class of binaries there is just no upside in parallel development, one guy is going squash the other guy's work. You want to serialize those efforts. We don't have global locks yet but we know how to do them, just waiting for the right sales prospect to "force" us to do them. I'm 90% sure we could add them to BK in about a week.
sytse 11y ago
After we add support for git lfs we plan to add web ui locking for files, this will allow you to lock files when browsing them and prevent others from uploading them

alkonaut 11y ago

Won't a central storage for the large files alao make it straightforward to add locking functionality in a future version of git-lfs, or as an add-in? I agree it sure looks like an omission to have a vcs that is centralized and aimed at binary data, without having any locking functionality.

vvanders 11y ago
Yeah, but that's assuming a whole lot of infrastructure around marking files read-only. I also haven't seen what the pull performance is like, P4 is a pretty known quantity(with caching as well).
- alkonaut 11y ago
  I don't even necessarily need my client to mark files as read only on my local machine. A system that just lets me query who has the lock on a certain file, and lets me get the lock on it if noone has, is miles ahead of shouting/email. A remote-only locking system should be pretty easy to implement, e.g by just throwing in "filename.userid.lock" into the filesystem next to the file in question.
  - sytse 11y ago
    We plan to add locking to the GitLab web ui at some point. At least this will prevent two people from locking the same file.

icebraining 11y ago

Git annex solves this without locking nor losing any of the versions - the actual files get different names (based on hashes of the contents), which are referenced by a symlink tracked by git. If two people edit the same file - pointing the symlink at different filenames - you get a regular git merge conflict.

vvanders 11y ago
That's the thing with binary assets, there is no merge path due to them being binary by nature.
- LukeShu 11y ago
  No /automatic/ merge resolution. Obviously you have a tool that can open them (if you edited it in the first place), and you can use that to view the differences, and replay one set of changes. The fact that the SCM detected the conflict, and alerted you, allowing you to resolve it, is a solid improvement over not using an SCM. Further, automatic merge resolution isn't always possible with text-based assets either (and even when it is, it isn't always the correct option!).
  - vvanders 11y ago
    I don't think you follow. Programs like Photoshop, Maya and 3DSM don't merge. Period. Your only option in this case is to throw away someone's work and force them to redo the work on the file that you decided to keep.
    - deleted 11y ago
      [deleted]
    - LukeShu 11y ago
      Programs like gedit don't merge. Period. Yet I can still use it to resolve a merge conflict. In Photoshop you would do this by opening both images, and visually comparing them to see what's different, then copying the appropriate parts from one to another. Instead of just visually comparing them, you might combine them into one file as separate layers, and use a transform to see the difference. If the tool doesn't support that, use ImageMagick to generate a graphical diff (either the `compare` or `compose` commands), and then copy the relevant parts from one to another. We have fancy tools to help us, but fundamentally, merging is a /human/ operation, that requires human judgment to see how multiple sets of changes can be made to coexist. And that doesn't require a tool (though it can certainly help).

jayd16 11y ago

Except perforce has been moving towards streams to compete with git's more desirable workflow, and you can't lock across streams anyway.

bmurphy1976 11y ago

Translation: because it is not useful for you it's not useful for anybody else. That's nonsense of course. There are a lot of use cases where this would be very helpful without locking (i.e. jar/dlls). This is useful now, locking can come later. We don't have to solve every conceivable problem all at once. More progress is made in small incremental steps than big bang leaps.

luckydude 11y ago

I've read the replies to vvanders and he's correct. With binaries you really want some sort of global locking (easy with a centralized system, hard with a distributed system). I believe his (her?) point is that for a very large class of binaries there is just no upside in parallel development, one guy is going squash the other guy's work. You want to serialize those efforts. We don't have global locks yet but we know how to do them, just waiting for the right sales prospect to "force" us to do them. I'm 90% sure we could add them to BK in about a week.

sytse 11y ago

After we add support for git lfs we plan to add web ui locking for files, this will allow you to lock files when browsing them and prevent others from uploading them