Giter VIP home page Giter VIP logo

snowtrack / snowfs Goto Github PK

View Code? Open in Web Editor NEW
1.3K 34.0 42.0 824 KB

SnowFS - a fast, scalable version control file storage for graphic files :art:

Home Page: https://www.snowtrack.io

License: GNU General Public License v3.0

TypeScript 95.52% JavaScript 0.05% Shell 0.19% Batchfile 0.20% PowerShell 3.72% Python 0.32%
version-control version-tracker version-control-system version-manager binary-manager graphic-files apfs storage

snowfs's Introduction

snowfs

SnowFS - a fast, scalable version control file storage for graphic files

release Coverage Status Build and Test License: GPL v3 DeepSource Codacy Badge

Overview

SnowFS is a high-performance command-line application and node library for Windows, macOS and Linux with a focus on binary file versioning. It is made for the graphics industry and was initially developed for Snowtrack.

Disclaimer: This project is in beta and actively developed.

terminal

Feature highlights

  • Supports Branches

  • Asynchronous File Hashing

  • Project open to file-content awareness (e.g: *.psd, *.blend, *.c4d, ..)

  • Super-fast-detection of modifications in large binaries

  • Support for instant snapshots**

  • Support for instant rollback**

  • Support for files bigger >4TB

  • Block-cloning and Copy-on-Write support for APFS, ReFS and Btrfs

  • Support for removing single versions and/or binaries

  • Primarily I/O bound through libuv

  • Feature XYZ made by you!

** If the underlying filesystem supports it (e.g. APFS, ReFS and Btrfs)

Made with SnowFS

Why not Git/Git-LFS, libgit2, or SVN?

First and foremost, the implementations of Git - namely Git/Git-LFS and libgit2 are excellent implementations of version control systems. But due to their focus on the software development lifecycle they are not suitable to version binaries or graphic files. SnowFS addresses the technical challenges for graphic files by its core design.

Git/Git-LFS:

Advantages:

  • Support on all major platforms
  • Supported by hosting platforms like GitHub, GitLab, and BitBucket.
  • Fast diff-operation for text-files

Disadvantages:

  • If not properly tracked, binaries become accidentally part of "base" history
  • Removing older commits is cumbersome due to Gits commit hashing integrity
  • Complicated rewriting history procedure
  • Issues with binaries >4GB on Windows as reported here, here, and here
  • Slow in binary modification detection

libgit2

Advantages:

  • Faster zipping, packing, and delta-compression than the reference implementation Git
  • Supports custom backends

Disadvantages:

  • No native support for Git-LFS without custom backends
  • Custom backends break compatibility with Git

TypeScript / C++ backport

SnowFS is currently written in TypeScript. It is a great language to write powerful and performant I/O bound prototypes. We are aware of the demand for a C++ implementation, and due to our roots as C++ developers, we are very interested in a backport as well. It would make SnowFS easier to integrate into other projects. If you have comments, ideas or recommendations, please let us know.

Running benchmarks

We have also implemented a comparison benchmark between SnowFS vs. git-lfs. After executing the build instructions for a development build, the benchmarks can be executed with the following command:

$ npm run benchmark

Example run on a Macbook Pro (2020) with an APFS formatted SSD to check-in, delete and restore a 4GB Photoshop File.

...
git lfs track *.psd
git add texture.psd: 20164ms
snow add texture.psd: 4596ms
git rm texture.psd: 575ms
snow rm texture.psd: 111ms
git checkout HEAD~1: 9739ms
snow checkout HEAD~1: 77ms <-- Yeah!

Examples

Code

You can find the best and up-to-date code examples in the test/ directory. Given below these are simply "Hello World!" examples to get you started.

import * as fse from "fs-extra";

import { join } from "path";
import { Index } from "./src";
import { Repository } from "./src/repository";

export async function main() {
  const repoPath = "/path/to/a/non/existing/directory";

  // Create a new repository.
  let repo: Repository = Repository.initExt(repoPath);

  // Copy a file called 'texture.psd' to the working directory.
  await fse.copyFile("/path/to/texture.psd", join(repoPath, "texture.psd"));

  // Retrieve the main index.
  const index: Index = repo.ensureMainIndex();

  // Mark 'texture.psd' as a new file in the index.
  index.addFiles(["texture.psd"]);

  // Write all files of the index to the object database.
  await index.writeFiles();

  // Create a commit for the index.
  await repo.createCommit(index, "This is my first commit");
}

main();

Command line interface

The CLI of SnowFS offers some basic functionality and is subject to enhancements. See Report #90

release

$ snow init foo
$ cp /path/to/texture.psd foo/texture.psd
$ cd foo
$ snow add .
$ snow commit -m "My first texture"
$ snow log
$ snow checkout -b MyNewBranch
$ snow log

Build Instructions

  1. To build SnowFS install node.js for your specific platform.

    1.1. On Windows, Visual Studio is required. We recommend the Visual Studio 2019 Community Edition. During the installation, please enable Desktop development with C++.

    1.2. On MacOS, XCode is required.

  2. To build a development build execute:

$ git clone https://github.com/Snowtrack/snowfs.git
$ cd snowfs
$ npm install
$ npm run test
  1. To build a production build including the CLI, execute the commands above, and continue with the commands below:
$ npm run tsc
$ npm run build
$ cd dist

How To Debug

For the development of SnowFS we recommend VSCode. The repository contains a launch.json file with pre-defined runner configurations. For more information, please visit this pull-request.

Versioning

Starting with version 1.0.0 SnowFS follows the semantic versioning scheme. The API change and backward compatibility rules are those indicated by SemVer.

Licensing

SnowFS is licensed under the GPL v3 license, please review the LICENSE file. Excluded from the license are images, artworks, and logos. Please file a request by mail, if you have any questions.

Community

Other resources

The tests and benchmarks also serve as API specification and usage examples.

Supported Platforms

Currently, Windows, macOS, and Linux are supported. SnowFS works on plain filesystems like FAT, NTFS, HFS+ and has extended support for APFS, ReFS and Btrfs.

How can I contribute?

See the guidelines for contributing.

snowfs's People

Contributors

codacy-badger avatar daniellanner avatar deepsource-autofix[bot] avatar deepsourcebot avatar dependabot[bot] avatar dskvr avatar kareniel avatar mmckester avatar nicdard avatar sebastianrath avatar shiena avatar unqueued avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

snowfs's Issues

(JS-0328) Promise-like values should be handled appropriately

Description

Usage of Promise-like values in statements without handling their errors appropriately is dangerous. Unhandled promises can cause several issues, such as improperly sequenced operations, ignored Promise rejections and more. Valid ways of handling a Promise-valued statement include awaiting, returning, and either calling .then() with two arguments or .catch() with one …

Occurrences

There is 1 occurrence of this issue in the repository.

See all occurrences on DeepSource → deepsource.io/gh/Snowtrack/SnowFS/issue/JS-0328/occurrences/

Can't switch branches

$ snow switch Main
D .DS_Store
fatal: You have local changes to 'Main'; not switching branches.

Snow commands only work at root level directory

When the working directory of the commandline is not at project root level, but deeper within the repository, snow commands fail with following error message:

fatal: ENOENT: no such file or directory, stat '$PROJECTDIR\subdir.snow'

Example fails:
$PROJECTDIR\subdir>snow status

Example works:
$PROJECTDIR>snow status

Expected behaviour is for snow commands to recognize the repository of the current working directory.

Adding support for Snow hooks

Similar to git, SnowFS offers a default directory for adding custom hooks to be executed upon calling repository commands. This directory is located at $PROJECTDIR/.snow/hooks.

Typical git hooks are scripts, named and titularly executed as:

  • applypatch-msg
  • commit-msg
  • fsmotir-watchman
  • post-commit
  • post-update
  • pre-applypatch
  • pre-commit
  • pre-merge
  • pre-merge-commit
  • prepare-commit-msg
  • pre-push
  • pre-rebase
  • pre-receive
  • update

Currently these files are not executed when performing the matched action.

At least a subset of the above directives could be implemented to be called when the appropriate action is executed. Example implementations can be existing git hooks.

recycle-bin.exe / trash not found

Embedding SnowFS into another project raises an exception when a file gets deleted.

File not found - 'recycle-bin.exe'
npm ERR! code ELIFECYCLE
npm ERR! errno 2

ts-node warm-up time takes too long

ts-node in the unit-tests takes too long to startup.

image

Full log here

9.cli.ts snow add bar.txt (10s) 
9.cli.ts snow rm foo.txt (25.2s) 
9.cli.ts snow rm subdir (24.9s) 
...

I opened a discussion with the maintainers of ts-node here

CLI does not terminate

On a private test-machine the CLI did not terminate the process after execution. After a deep investigation, this seems to be an issue with ts-node/register

Reproducible steps:

./bin/snow any-command

any-command must not result in an exception, because an exception already executes process.exit(-1).

Static Analyses for test.only

Add a Github job to analyse the test suite and fail upon an occurence of test.only.

When running tests on the local machine it is productive to only run the tests for the feature you are working to minimize wait time. Unfortunately, these changes have been committed made it passed Pull Requests a couple times.

The solution is to add a job to the CI pipeline that checks for test.only occurence before running the unit tests.

CLI doesn't accept spaces

It seems that in some terminals snow commit -m "a b c d" only redirects a. It requires some investigations where this comes from

commit: ...  (HEAD, experiment)
Date: Sat Feb 13 2021 00:17:41 GMT-0500 (Eastern Standard Time)

  a   <--- missing 'b c d'

Add command to print driveinfo

It would be great to add ./snow driveinfo to the commands to display the available drives. It would be helpful to investigate issues easier and make it part of the ISSUE template if a potential bug requires more system-related info.

Discard changes moves untracked files to the trashcan

Summary

The command snow checkout <hash> with option --discard changes is a quick way for the user to change to a specific commit without having to manually unstage the files.

Faulty Behaviour

--discard changes currently enforces the destination snapshot, deleting all untracked files in the process.

Expected Behaviour

--discard changes should automate the snow restore <file> command for all staged files before processing the checkout command.

Multiline commit message introduces json parse error

Summary

After passing a multiline commit message future snow status invocations fail with the following error message:

cwd>snow status
fatal: Unexpected token
 in JSON at position 192

Proposed Solution

The received commit message needs to be escaped to be json compliant.

snow add . ignores deleted files

snow init foo
cd foo
touch file
snow add .
snow commit -m "add file"
rm file
snow add .
snow commit -m "rm file"
# fatal: nothing to commit (create/copy files and use "git add" to track)

Fails

Support HEAD~N

The reference of HEAD~n needs to be supported. It is also referenced in the readme and actually doesn't work yet.

Add support for user data in refs

Summary
Add the option to write, store and read additional data for refs. This will allow flexible customization for end users and share the data between .snow repository consumers.

Limitation
Currently all available information of a ref is limited to its file name and the stored hash.

Expectation
User facing plugins may want to store additional information per ref. This may range from generic display options (e.g. color) to project specific settings. Writing and reading these values via the CLI ensures consistency and potential presentation for other SnowFS products.

Proposed Changes
Currently a ref file contains purely the hash in form of {"hash":""}. I propose to add an additional field "user_data" to store a collection of arbitrary key value pairs.

Update --stdin for inputs

Certain objects in SnowFS support user-data, which are currently written to the stdin, e.g. snow commit ... --user-data
To support additional stdin features in the future, the stdin should be separated, preferably by \r\n\r\n.

Example:

snow commit -m "Some description" --stdin

And stdin:

user-data: ...
\r\n\r\n
new-input: ...
...

snow.exe does not start

The artifact package of the Windows build does not execute:

C:\Users\sebastian\Downloads\snow-cli-win-x64.zip>snow.exe
pkg/prelude/bootstrap.js:1244
      throw error;
      ^

Error: Module did not self-register: '\\?\C:\Users\sebastian\Downloads\snow-cli-win-x64.zip\node_modules\drivelist\build\Release\drivelist.node'.
�[90m    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1248:18)�[39m
�[90m    at Module.load (internal/modules/cjs/loader.js:1047:32)�[39m
�[90m    at Function.Module._load (internal/modules/cjs/loader.js:935:14)�[39m
�[90m    at Module.require (internal/modules/cjs/loader.js:1087:19)�[39m
    at Module.require (pkg/prelude/bootstrap.js:1225:31)
�[90m    at require (internal/modules/cjs/helpers.js:73:18)�[39m
    at bindings (D:\snapshot\SnowFS\node_modules\�[4mbindings�[24m\bindings.js:112:48)
    at Object.<anonymous> (D:\snapshot\SnowFS\node_modules\�[4mdrivelist�[24m\js\index.js:25:27)
    at Module._compile (pkg/prelude/bootstrap.js:1320:22)
�[90m    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1218:10)�[39m

Use unix file-pattern matchings

Currently, Regex is used for the snowignore file. That is error-prone and user-unfriendly. A better option are UNIX file-pattern matchings, implemented by glob as explained here.

As noted in micromatch here are the different features of the libraries

Feature minimatch micromatch picomatch nanomatch extglob braces expand-brackets
Wildcard matching (*?+) - - -
Advancing globbing - - - -
Brace matching - - -
Brace expansion - - - -
Extglobs partial - - -
Posix brackets - - - -
Regular expression syntax - -
File system operations - - - - - - -

Long warmup phase for bin scripts

Describe the bug
The scripts in the bin folder take a long time to start.

$ npm i
$ ./bin/snow
$ ./bin/snow  # call twice

ts-node is currently used to execute main.ts. Afaics ts-node is supposed to cache the transpiled files in the background, which doesn't happen at the moment.

Two solutions are possible:

  1. find out why ts-node takes so long despite the cache
  2. switch to a precompiled tsc build, which might be a long-term goal anyway

Error messages in console when debugging

Running any command through the VScode debugger prints the following non-critical issues to the VS console

C:\Program Files\nodejs\node.exe -r C:\Users\sebastian\Documents\git\snowfs/node_modules/ts-node/register C:\Users\sebastian\Documents\git\snowfs/main.ts -- status
Could not read source map for internal/deps/acorn/acorn/dist/acorn.js: Invalid URL: internal/deps/acorn/acorn/dist/acorn.js
Could not read source map for file:///c:/Users/sebastian/Documents/git/snowfs/node_modules/typescript/lib/typescript.js: 
    ENOENT: no such file or directory, open 'c:\Users\sebastian\Documents\git\snowfs\node_modules\typescript\lib\typescript.js.map'

Version control of external assets

It would be great to explore the options of tracking external files/assets, besides the ones that are inside the repository. A project often consists out of a scene-file, assets in the project directory, but also assets outside of it.

Currently the Index converts all absolute paths into relative paths.

Proposal 1:
Extend index.addFiles(..., {external: true})

Proposal 2:
Extend index.addExternalFiles(...)

Adding support for ReFS

Although ReFS is not widely used, it seems like a great playground for SnowFS and a great candidate to be supported. I once demonstrated the performance in a tweet https://twitter.com/snowtrack_io/status/1351186255816646657

https://github.com/Snowtrack/SnowFS/blob/09d959189d713ce7e414ab81bd67f3b899a25ac0/src/io_context.ts#L190-L192

I will try to reach out to the maintainer of https://github.com/Sorrowfulgod/ReFSBlockClone to ask if he could clarify the license for this project.

Snow ignore file feature lacks tests

Summary

SnowFS provides the ability to ignore files within the repository when executing snow commands. This can be achieved by entering a pattern in the ignore file at the root of the repository. Pattern matching is performed via Regular Expressions.

Currently this feature is not covered by unit tests.

Task

Ensure desired behaviour of the ignore feature and improve doumentation for edge cases by writing tests.

Standardize the CLI commands of SnowFS

This issue is a proposal for modifications of the CLI API. The focus is a balance between easy-to-use and already established commands in Git.

snow-branch

Create, or delete branches.

Description

Create and delete a branch.

$ snow branch branch-foo
A branch 'branch-foo' got created.

Create an existing branch

$ snow branch branch-foo
fatal: A branch named 'branch-foo' already exists.

Create an existing branch with a commit hash as a starting point

$ snow branch branch-bar 768FF3AA8273DFEB81E7A111572C823EA0850499
A branch 'branch-foo' got created.

Create a branch that already exists

$ snow branch -f branch-foo
A branch named 'branch-foo' got created.

Delete a branch

$ snow branch --delete branch-foo
A branch named 'branch-foo' got deleted.

Delete a non-existing branch.

$ snow branch --delete branch-foo
error: branch 'branch-foo' not found.

For more information see: git-branch

snow-switch

Switch branches. Any modifications in the stage area, or in the worktree are brought over to the switched branch.

Description

Switch to an existing branch.

$ snow switch branch-foo
# Silently switch to branch

Switch to a non-existing branch.

$ snow switch branch-123
fatal: A branch named 'branch-123' does not exist.

Switch incorrectly to a commit. To checkout a commit see snow-checkout.

$ snow switch 6cfb01e83d18fa63761e964c329273d292d23bb4
fatal: a branch is expected, got commit '6cfb01e83d18fa63761e964c329273d292d23bb4'

Create and switch to a branch. Short command for snow-branch and snow-switch

$ snow switch -c branch-bar
A branch 'branch-bar' got created.
# Afterwards silently switch to branch

Create and switch to a branch with a start-point.

$ snow switch -c branch-bas 768FF3AA8273DFEB81E7A111572C823EA0850499
A branch 'branch-bas' got created.

For more information see: git-switch

snow-checkout

Switch to branches, commit or reference. Modifications of any kind of known files to SnowFS will make the command fail.

Description

Checkout an existing branch.

$ snow checkout branch-foo
# Silently switch to branch-foo

Switch to a branch, commit or reference.

$ snow checkout 768FF3AA8273DFEB81E7A111572C823EA0850499
# Silently switch to commit 768FF3AA8273DFEB81E7A111572C823EA0850499

Modify a file and checkout an existing branch

$ echo "Hello" > existing-foo.txt
$ snow checkout branch-foo
fatal: Your local changes to the following files would be overwritten by checkout:
        existing-foo.txt
Please commit your changes before you checking out.
Aborting

For more information see: git-checkout

snow-restore

Restore files or directories. Restoring a file that is unknown to SnowFS will make the command fail. For such case, use snow-clean.

Description

Restore a known file in the worktree (default), aka unstages foo.txt.

$ snow restore foo.txt
# Silently discard changes of foo.txt or restore the file if deleted (in stage)

Restore a known file in the staged area, aka unstages foo.txt. Basically reverts snow add foo.txt

$ snow restore --staged foo.txt
# Silently discard changes of foo.txt or restore the file if deleted (in stage)

Restore a known file in the staged area and the worktree

$ snow restore --staged --worktree foo.txt
# Silently discard changes of foo.txt or restore the file if deleted (stage and worktree)

For more information see: git-restore

snow-clean

Restore files or directories. Restoring a file that is unknown to SnowFS will make the command fail. For such case, use snow-clean.

Description

Remove all untracked files from the working tree in cwd and all subdirectories of it.

$ snow clean .
# Silently delete all untracked files in the current directory

Remove all untracked files from the working tree from the current and all subdirectories.

$ snow clean *
# Silently delete all untracked files in the entire worktree.

Remove a specific untracked file from the working tree.

$ snow clean foo.txt
# Silently delete untracked foo.txt

For more information see: git-clean

Branch names are stored in filename

Currently branch names are stored as files in ./snow/refs. Since the snow directory is a "system folder" for SnowFS, this doesn't need to be human-readable. Therefore moving the name to the content of the file might be a good candidate to be less restricted by the OSes filename convention.

Git for instance needs git-check-ref-format to ensure the branch name is valid. This shouldn't be a restriction anymore

Linux support required

(JS-0352) Detected member access on any typed variables

Description

Despite your best intentions, the any type can sometimes leak into your codebase. Member access on any typed variables is not checked at all by TypeScript, so it creates a potential safety hole, and source of bugs in your codebase. Example - The not-preferred way : ```ts declare const anyVar: …

Occurrences

There are 511 occurrences of this issue in the repository.

See all occurrences on DeepSource → deepsource.io/gh/Snowtrack/SnowFS/issue/JS-0352/occurrences/

snow rm moves files to trashcan

Summary

The snow rm command is currently used to unstage files. Unfortunately it also moves files to the trashcan.

Expectued Behaviour

The snow rm command should unstage files only.

Side Note

This command is being reworked with Issue #90. This report is likely to be closed in conjunction with it.

Checkout to an older commit does not restore directories

Given is a commit A with a directory and a file inside. If a subsequent commit B deletes the directory and file and a checkout to A is performed, the directory structure is not restored and the command fails.

snow init foo
cd foo
mkdir sub-dir
touch sub-dir/file
snow add .
snow commit -m "add directory + file"
rm sub-dir/file
rm sub-dir
snow add .
snow commit -m "remove directory + file"
snow checkout HEAD~1

Snow add fails when providing an invalid regex in the ignore file

Summary

SnowFS provides the ability to ignore files within the repository when executing snow commands. These files are determined by entering regular expressions (RegEx) in the ignore file. If these (RegEx) are invalid the command currently exits with a fatal exception.

Expected

The current situation is not ideal. I propose either one of two options (examples refers to snow add * command):

A) Complete command and print warning
Clearly state that all files have been staged and print which line RegEx is invalid.

B) Terminate command with error message
Exit staging process and return an error indicating which RegEx is invalid.

Although both options have merit, I personally tend towards option B) to keep the state of the database intact. Please feel free to disagree with me, @seb-mtl.

Add support for tags in commits

Summary
Add the option to write, store and read additional tags for commits. This will allow flexible categorization for end users and share the data between .snow repository consumers.

Limitation
Currently all available information of a commit is limited to its hash, message, date and parent.

Expectation
User facing plugins and users may want to store additional organization per commit. Writing and reading these values via the CLI ensures consistency and potential presentation for other SnowFS products.

Proposed Changes
Currently a commit file contains purely the hash, message and date as key value pairs. I propose to add an additional field "tags" to store an array of strings.

Additional Notes
Although similar in nature as Issue#36 about storing user data. I believe a seperate distinction to be valid as these tags are used strictly for organising commits. A natively supported approach for this will enable future products to very easily filter for commits or indeed create and apply labels to filter by.

GitHub Actions needed

This repo needs a setup and configuration for GitHub actions (including unit-tests)

no such file or directory when restoring a file in a subdirectory

Instructions:

snow init foo
cd foo
mkdir subdir
echo "Test" > subdir/test.txt
snow add .
snow commit -m "add test.txt"
snow rm subdir
snow commit -m "delete test.txt"
snow log
snow checkout 7e7071eb612a9e39f5ff229c230eda0d3d1bef10f7aca108be6dddd19bfa931a  # choose the hash-id"add test.txt"

Error:

fatal: ENOENT: no such file or directory, copyfile 'C:\Users\sebastian\Desktop\foo\.snow\objects\d0\38\d0388...' ->
 'C:\Users\sebastian\Desktop\foo\subdir\test.txt'

Add snow add * for subdirectories

  • If in a subdirectory snow add . should only add the files of the current directory.
  • If in a subdirectory snow add * should add all files of the project, including in the parent directory and its subdirectories

Add support for user data in commits

Summary
Add the option to write, store and read additional data for commits. This will allow flexible customization for end users and share the data between .snow repository consumers.

Limitation
Currently all available information of a commit is limited to its hash, message, date and parent.

Expectation
User facing plugins may want to store additional information per commit. This may range from generic display options (e.g. color) to project specific settings. Writing and reading these values via the CLI ensures consistency and potential presentation for other SnowFS products.

Proposed Changes
Currently a commit file contains purely the hash, message and date as key value pairs. I propose to add an additional field "user_data" to store a collection of arbitrary key value pairs.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.