4 ms·

Store all those things as text and you can stick them in git

by tomc1985 6y ago

strombofulous 6y ago
You won't really get a meaningful diff from, for example, an image or video
marcosdumay 6y ago
People do not want to represent most of them as text. Some of them need high amounts of compression to be viable. Others don't have any concept of locality that one can map into a single dimension. For some, locality of changes is even an anti-feature.
- npsimons 6y ago
  > People do not want to represent most of them as text. "People" don't care what things are stored as. You could make GUI tools save to GraphViz's text based format (or heck PlantUML[0]) for graphs at least and it would work just fine. For assets which have to be truly binary, Perforce offers versioning of those. I know it's not open source and costs money, but if it's really a need, it's worth it. [0] - https://plantuml.com/ https://plantuml.com/
Lichtso 6y ago
You can do that, but you will only get some of the features (a distributed backup system with an undo function). The most important one IMO is merging and that does not work on arbitrary formats serialized to text. E.g. let two 3D artists fork a blender 3D file in GIT, both do changes and commit them. Until here everything seems fine, now they want to merge their changes ... and suddenly everything falls apart. Edit: To clarify, if you don't need merging than you also don't need distributed VCS and centralized VCS will be sufficient. That is why I explicitly talked about distributed VCS.
- npsimons 6y ago
  This sounds like an intractable problem, and putting it politely, the fault lies in the file format, not the VCS.
  - Lichtso 6y ago
    You are right, in that it is very hard. That is why I said that I think distributed VCS is far from being solved. However, I think the "fault" lies neither in the VCS nor file format. It simply shows that merging requires domain knowledge and that future VCS will need to cooperate with file formats to achieve that.

Store all those things as text and you can stick them in git

You won't really get a meaningful diff from, for example, an image or video

People do not want to represent most of them as text. Some of them need high amounts of compression to be viable. Others don't have any concept of locality that one can map into a single dimension. For some, locality of changes is even an anti-feature.

npsimons 6y ago
> People do not want to represent most of them as text. "People" don't care what things are stored as. You could make GUI tools save to GraphViz's text based format (or heck PlantUML[0]) for graphs at least and it would work just fine. For assets which have to be truly binary, Perforce offers versioning of those. I know it's not open source and costs money, but if it's really a need, it's worth it. [0] - https://plantuml.com/ https://plantuml.com/

Lichtso 6y ago

You can do that, but you will only get some of the features (a distributed backup system with an undo function). The most important one IMO is merging and that does not work on arbitrary formats serialized to text. E.g. let two 3D artists fork a blender 3D file in GIT, both do changes and commit them. Until here everything seems fine, now they want to merge their changes ... and suddenly everything falls apart. Edit: To clarify, if you don't need merging than you also don't need distributed VCS and centralized VCS will be sufficient. That is why I explicitly talked about distributed VCS.

npsimons 6y ago
This sounds like an intractable problem, and putting it politely, the fault lies in the file format, not the VCS.
- Lichtso 6y ago
  You are right, in that it is very hard. That is why I said that I think distributed VCS is far from being solved. However, I think the "fault" lies neither in the VCS nor file format. It simply shows that merging requires domain knowledge and that future VCS will need to cooperate with file formats to achieve that.