sebastian_io

Fair point, imho landing pages rarely sell the full experience. In short the focus is UX, turnkey setup, visual feedback and data aggregation/graphs. Found gisia, cool project as well, starred!

Thanks! The project consists basically out of two components, the runtime and the editor.

The runtime is mostly self-written, focusing most of my efforts. The editor on the other hand is built on `rete.js` (https://retejs.org/) and Angular. ReteJS is a really amazing node editor framework. While I customized almost everything that was possible, a lot of credit goes to them.

In hindsight, Angular might have been a little bit of overkill, but it's the framework I'm comfortable with, given my very limited web development experience.

The editor is available here on GitHub and should work out of the box with the default VS Debug Configuration https://github.com/actionforge/graph-editor

Hey there,

I have always been a fan of GitHub Actions workflows but for some reason never liked YAML files as being the assigned file format for non-linear workflows. While YAMLs are great as configuration files, they can be quite tedious when it comes to creating, reviewing, and maintaining workflows.

To solve this, I created a visual node system that makes the workflow creation and maintenance process more efficient and intuitive. It's a straightforward node engine with an UI editor.

Examples for such a node graph are here: https://www.actionforge.dev/github/actionforge/graph-runner/...

and here: https://www.actionforge.dev/github/actionforge/graph-editor/....

For clarification, they are directly executed on GitHub runners. These graphs took me minutes to build in order to focus on my actual project.

The next time you create a new repo, give it a try. Love to hear your thoughts!

Thanks!

I checked this on Windows and macOS with the latest version of Firefox and I have no issues opening the page

I’m from the future. ;-) But I will fix it, thanks for the info

There is a lot going on in the space right now and there will be certainly a big shift in the next years. But as long as Blender, Cinema 4D, Photoshop, Pixelmator, Affinity are not running in the cloud I rather feel like DCC software packages and tablets will introduce a change first

Thanks for the feedback! I will look into this

You have a point there :-D

I should clarify this. The 100 MB window in SnowFS is currently unrelated to compression as it is only used to compare if a block changed. Each block gets a hash. This is a fallback used for some file formats where the mtime timestamp cannot be trusted. Some files have a change in the first block e.g. 100 MB and that is faster to compare than an entire 8GB file. But this window size is dynamic and can be changed and used for compression in the future

You're right. Git is widely used but I wouldn't call it an industry standard (yet), especially not not for repositories that exclusively contain binary data. And the GPL works well with commercial products. On top there is libgit2 which is a fantastic alternative as well. But Git doesn't fulfill the technical requirements for Snowtrack

This is incredibly helpful as I was looking for something like this for weeks. Thanks a lot for sharing! This looks super useful

I am currently working on the compression, as it is not complete yet. The 100 MB is indeed excessive but the window is dynamic and can differ from file to file since it is written to a `*.hblock` file which is stored next to the object in the object database https://github.com/Snowtrack/SnowFS/blob/03e5f839326e666c891...

Let me explain where the 100 MB window comes from as its not only related to the upcoming compression implementation. Some graphic applications touch the timestamps of their files for no reason, making it harder to detect if a file changed. But some file formats always change their 'header' or 'footer'. Means, comparing the hash of the first or last 100 MB of a file that is 8GB in size gives a great performance boost to detect if a file got modified.

Unfortunately, Snowtrack has no collaboration workflow yet. The underlying file storage system is prepared to support collaboration in the future, but it's too early for this

Thanks for your input! Snowtrack has no collaboration features built in yet. The public beta of Snowtrack is available since today. The project has a lot of fields to discover and will evolve over time. There are certainly countless of areas untouched yet

Thanks for your feedback! Better D&D handling was already requested a few times and will certainly be added in the next versions

Snowtrack focuses on local file versioning with tools that are locally installed (e.g. Photoshop, Blender, Cinema 4D, Pixelmator, ...)

I received a lot of feedback by people with music background. I recently talked to someone from the music production industry and it was interesting to hear that they have the same workflow and problems as the graphics industry. Snowtrack could be used with any DAW but the missing thumbnails are a downer at the moment

I absolutely agree. When I started evaluating the project I was positively surprised about the performance of Node for this field. It was a perfect fit so I continued with it

Great idea! I've to admit my knowledge about Mercurial is very rusty. Could you help out on that? May I invite you to share some insights in the discussion board of the project? https://github.com/Snowtrack/SnowFS/discussions

Thank you for your feedback. You brought up very good points. Snowtrack is available as a public beta since today and will evolve from here through user-requests and feedback. Snowtrack supports a simple before/after compare but this feature will be heavily extended with the next versions.

About merge operations: The majority of solo artists and designers don't work in many branches. Most projects just go forward and branches are only useful if a rollback is needed. That being said, Snowtrack does offer a simplified "cherry-pick". But merge operations as you might know them from Git/Perforce are not implemented yet as it takes time to see how users adapt the software.

Keep in mind, most artists and designers are new to VCS or have never heard of it before and therefore it is crucial to find the right balance between too little and too many features. Any second that keeps the artist away from creating their artwork is wasted and therefore and the goal is to not interfere with their workflow or to add additional "management tasks"

Thank you! The project consists out of two projects. SnowFS is the underlying core and is available as an open-source project (MIT). Snowtrack is the UI and the commercial product build around it and will be available as a Freemium product

Thank you! I've already prepared the foundation for a Linux build, and it's planned in the near future but I don't have a build available yet

Just for clarification, there are two projects involved here. SnowFS is the underlying open-source VCS, and Snowtrack is the commercial UI build around it.

But for your statement about licenses, there is actually not much I can say to counter your arguments. I've followed the fight between Amazon and Elastic so you have very valid points. For the moment I don't think SnowFS will face the same issues given its current scope and target audience/market

Correct

In this case it's a comparison between MIT and GPL. GPL software is more restrictive than licenses like MIT/Apache/.. and therefore not as much as present in the VFX or CG industry and that's key here. But you are absolutely right! The wording is potentially misleading and should be improved. I'll fix it

Very excited for a PR. Any help and support is very welcome. :-)

I just cloned one of the repos, seems I really should look more into annex. Feel free to join the Discord channel, that would be the easiest to go from there

I really appreciate your critical view on the project, because it makes me reflect my own stand and arguments and to see if they are correct or wrong. E.g. I just removed the "without LFS" argument because you are right, this is not a sustainable argument and I will address a few more soon to clear things up.

I learned a lot during the development of SnowFS and the open-source-community is the best place to share my experiences, that's why I put it on GitHub. At the end, I would be super happy if these insights can make it over to Git and Git-LFS.

We have a Discord channel, you are very welcome to swing by anytime for a virtual beer :-)

> Other than the 2nd-to-last point (slow binary mod detect), performance wasn't otherwise listed in the README, so I don't know why you're calling me out for omitting it.

The ones I was referring to for performance are:

- Support for instant snapshots

- Support for instant rollback

About alternatives, Perforce and PlasticSCM are currently commonly used. But I understand your objections, and will check if I can handle certain things differently in the README. Thanks again for your input!

Impressive numbers! Unfortunately I know git-annex only on paper. I gave it a try a while ago, but it was a bumpy start, admittedly most likely user-error. Would you mind sharing some details about it (e.g. file numbers, etc)? Can I invite you for a chat? Doesn't need to be long, but might be more suitable for a chat

Interesting project, thanks for sharing the link! I will check that out. And for the tip, agree 100%! :-)