Git and Backup for Daz Studio

Hey,

I come from a background of software development, and I'm looking for tools that are similar to Git and Backup, but for Daz Studio.

Functionalities I need:

1) A way to cloud backup all my project files so that I can recover it easily in case of HDD failure.

2) A way to collaborate as a team with another 3D artist (like git), where we can stage, commit and push changes to a central repository, and the other part can fetch and pull these changes. Dependencies should be handled automatically.

Comments

  • FSMCDesignsFSMCDesigns Posts: 12,774

    The problem with number 2 is you can't share any of the content you purchase. The license if for your use only. If you create a scene and share it with others they need to have the exact same content you have, purchased and installed in their version of DS as well to make it work.

  • Personally I use BackBlaze for backing up my PC to the cloud. All of the content that you use in Daz Studio is stored in files that can be backed up easily. Stuff that you create like scenes and such are stored in your documents folder which is backed up by BackBlaze by default.

    In regard to #2 you can do this as long as you're sharing content that you and the other artist(s) are developing. For example if you're creating clothing items and another artist is creating the textures for said clothing items. Otherwise, as Michael says every member of the team would need to have purchased the same content. You could, in fact, use GIT via a stand alone tool such as Atlassian SourceTree. 

    There are other options as well such as OneDrive where you can store content in the cloud and share the folders with the other artist(s). This might serve both as a cloud backup and a means of sharing content you're developing with the other artist.

  • kenshaw011267kenshaw011267 Posts: 3,805

    Hey,

    I come from a background of software development, and I'm looking for tools that are similar to Git and Backup, but for Daz Studio.

    Functionalities I need:

    1) A way to cloud backup all my project files so that I can recover it easily in case of HDD failure.

    2) A way to collaborate as a team with another 3D artist (like git), where we can stage, commit and push changes to a central repository, and the other part can fetch and pull these changes. Dependencies should be handled automatically.

    As explained collaboration is tricky but for version control I just use git. The .duf files are binary so you can't do the things you can with text files but you can save different versions and even fork projects pretty easily.

  • Sensual ArtSensual Art Posts: 645

    You can use Git LFS to store, share and version binaries but most free hosted Git repositories have conservative limits not only on the size of the repositories but also on the bandwidth. Even if you manage to stay within the space quota, you may find yourself running out of bandwidth depending upon how many times the files are accessed or uploaded by collaborators. Though some hosted repositories do support provisioning of additional space and bandwidth at additional costs, costs which may not justify the benefits in this case.

    One can of course, host their own Git LFS server but maintaining that would be a non-trivial task for non-developers. Going the Git LFS route would also limit most file and directory tools which are used for searching/archiving files in case if one needs to move old files away from the current volume/partition.

    You are better off using cloud based storage if you are working in teams. Google Drive in G Suite can be one of the better options for collaboration since it supports rudimentary file versioning without requiring the technical expertise of using a full blown version control system.

  • LeanaLeana Posts: 11,816

    The .duf files are binary so you can't do the things you can with text files but you can save different versions and even fork projects pretty easily.

    Actually duf files are text, but they're compressed by default. There's an option to save them uncompressed.

  • Sensual ArtSensual Art Posts: 645
    Leana said:

    The .duf files are binary so you can't do the things you can with text files but you can save different versions and even fork projects pretty easily.

    Actually duf files are text, but they're compressed by default. There's an option to save them uncompressed.

    Which is pointless wrt version management given their size and structure. Any benefit gained from storing differential file states across versions is lost due to the bloat of the uncompressed files. Their DSON format is meant for ease of processing by tools, not for human modification. Imagine doing a manual 3-way merge for a DSON file which often contains hundreds or even thousands of lines of vector coordinates. There is no point is sharing a baselined asset version where manual diff and merge are impractical.

    On a different note, there are more efficient ways like allocating asset ownerships for controlling modifications while working in teams. This should be sufficient for small teams. For medium to large size teams where multiple people need to modify the same asset, a simple lock-commit-release mechanism should suffice. Again Git being a distibuted VCS does not help because implementing any sort of global locking for files is next to impossible. Older centralized VCSs like CVS and SVN are more suitable since they support locking of files centrally.

  • kenshaw011267kenshaw011267 Posts: 3,805
    mrinal said:

    You can use Git LFS to store, share and version binaries but most free hosted Git repositories have conservative limits not only on the size of the repositories but also on the bandwidth. Even if you manage to stay within the space quota, you may find yourself running out of bandwidth depending upon how many times the files are accessed or uploaded by collaborators. Though some hosted repositories do support provisioning of additional space and bandwidth at additional costs, costs which may not justify the benefits in this case.

    One can of course, host their own Git LFS server but maintaining that would be a non-trivial task for non-developers. Going the Git LFS route would also limit most file and directory tools which are used for searching/archiving files in case if one needs to move old files away from the current volume/partition.

    You are better off using cloud based storage if you are working in teams. Google Drive in G Suite can be one of the better options for collaboration since it supports rudimentary file versioning without requiring the technical expertise of using a full blown version control system.

    No idea where you're getting this. github has a free tier that would be fine for this and the $4/month/user tier is available if you really need that much storage. 

  • Sensual ArtSensual Art Posts: 645
    mrinal said:

    You can use Git LFS to store, share and version binaries but most free hosted Git repositories have conservative limits not only on the size of the repositories but also on the bandwidth. Even if you manage to stay within the space quota, you may find yourself running out of bandwidth depending upon how many times the files are accessed or uploaded by collaborators. Though some hosted repositories do support provisioning of additional space and bandwidth at additional costs, costs which may not justify the benefits in this case.

    One can of course, host their own Git LFS server but maintaining that would be a non-trivial task for non-developers. Going the Git LFS route would also limit most file and directory tools which are used for searching/archiving files in case if one needs to move old files away from the current volume/partition.

    You are better off using cloud based storage if you are working in teams. Google Drive in G Suite can be one of the better options for collaboration since it supports rudimentary file versioning without requiring the technical expertise of using a full blown version control system.

    No idea where you're getting this. github has a free tier that would be fine for this and the $4/month/user tier is available if you really need that much storage. 

    They sell data packs for additional space bandwidth for LFS

    https://help.github.com/en/github/managing-large-files/about-storage-and-bandwidth-usage
    https://github.com/account/billing/data/upgrade?packs=1

    Each $5 data pack grants an additional 50 GB storage and 50 GB bandwidth to Git LFS

    Their free plan grants only offers 500MB of private space whereas the paid $4 monthly plan grants only 2GB of private storage which is pretty insufficient for graphics projects especially when you consider different versions across multiple projects. That and the 100MB max file size limit outside of Git LFS https://help.github.com/en/github/managing-large-files/what-is-my-disk-quota

  • Sensual ArtSensual Art Posts: 645

    Also, if you already have a budget of $4 /user/month. A self-managed Git LFS repository on a virtual private server for a team would give far better mileage in terms of space and bandwidth than Github. Again, for reasons stated earlier, I would not recommend going with Git for this use case.

Sign In or Register to comment.