Migration of libraries to Git LFS #108978

New Issue

Sergey Sharybin · 2023-06-14T15:28:47+02:00

Sergey Sharybin commented

2023-06-14 15:28:47 +02:00

This is a quick design task to communicate and coordinate transition of libraries from Subversion to Git LFS.

The are currently the following folders in the lib folder of Subversion:

asset_bundles
assets
benchmarks
darwin
darwin_arm64
linux_centos7_x86_64
linux_x86_64_glibc_228
packages
resources
tests
win64_vc15

Floating repositories

The following repositories are converted from Subversion to Git LFS, but not attached as submodules:

asset_bundles
packages
resources

Submodules

The remaining repositories are converted to Git LFS but also are attached to the blender.git as a submodule.

The main difference from out previous usage of submodules is that within this proposal the submodules are actually tracking a specific commit.

This leads to an extra steps when it comes to committing updates: the submodule has in the blender.git has to be updated after commit to a submodule, but on another hand, it allows to ensure libraries are tests are at their proper state when bisecting.

Directory layout

The following directory layout is proposed:

blender/
  * release/datafiles/
    * assets/        -> assets.git
      * publish/
      * ...
      * README.txt
  * lib/
    * darwin_x64/    -> lib_darwin_x64.git
    * darwin_arm64/  -> lib_darwin_arm64.git
    * linux_x64/     -> lib_linux_x64.git
    * windows_x64/   -> lib_windows_x64.git
  * tests/data/
    * benchmarks/    -> benchmarks.git
    * files/         -> test_files.git (renamed from svn/tests Subversion directory)

Saving disk space

It is undesirable that all checkouts of blender.git will checkout libraries for all platforms.

it seems to be possible to utilize the update submodule configuration.

From the local prototype the .gitmodules could look similar to this (note the update = none for the libraries):

[submodule "lib/linux"]
	update = none
	path = lib/linux
	url = ../lib_linux.git
[submodule "lib/windows"]
	update = none
	path = lib/windows
	url = ../lib_windows.git
[submodule "release/datafiles/assets"]
	path = release/datafiles/assets
	url = ../assets.git

With such configuration doing git submodule update will skip the libraries:

$ blender (main) % git submodule update
Skipping submodule 'lib/linux'
Skipping submodule 'lib/windows'
Cloning into '<DIR>/blender/release/datafiles/assets'...
done.
Submodule path 'release/datafiles/assets': checked out '<HASH>'

In order to make the libraries updated the following command (or similar to other platform) can be used: git config --local submodule."lib/linux".update checkout:

$ blender (main) % git config --local submodule."lib/linux".update checkout
$ blender (main) % git submodule update
Cloning into '<DIR>/blender/lib/linux'...
done.
Skipping submodule 'lib/windows'
Submodule path 'lib/linux': checked out '<HASH>'

Updating after commit to the submodule

When a commit is done to a submodule a parent repository (blender.git) needs to be updated as well.

The easiest workflow seems to be:

People who work on the content of the submodule commit to its repository from within the submodule directory.
For example, if a new reference image is to be committed it is to be done from tests/data/files folders.
From the blender.git checkout:
- git add <path/to/module>.
  For example, git add tests/data/files.
- git commit and git push as usual

Update automation

For the make update will take care of the following things:

Ensure that the submodules are at the state at which the parent repository points to
Enables the libraries for the current platform (set the update to checkout)

Caveats

It is not possible to share libraries in a work-tree configuration.
Which can actually be good in some cases, because it allows to have main and blender-v3.6.release branches to use their own libraries.
Commit to a submodule might need an extra care as the make update might put it to a detached head. A manual step to put it to a desired branch before commit might be needed.

Plan

Create for-now empty Git LFS repositories
Create configuration in the blender.git
Update the make update
Revoke commit access to Subversion from almost everyone (platform maintainers needs access to commit security fixes for LTS)
Remove Subversion configuration from buildbot
Commit content of Subversion to Git LFS
Switch CMake configuration to use submodule directories instead of Subversion
...
Profit

This is a quick design task to communicate and coordinate transition of libraries from Subversion to Git LFS. The are currently the following folders in the `lib` folder of Subversion: * asset_bundles * assets * benchmarks * darwin * darwin_arm64 * linux_centos7_x86_64 * linux_x86_64_glibc_228 * packages * resources * tests * win64_vc15 # Floating repositories The following repositories are converted from Subversion to Git LFS, but not attached as submodules: * asset_bundles * packages * resources # Submodules The remaining repositories are converted to Git LFS but also are attached to the blender.git as a submodule. The main difference from out previous usage of submodules is that within this proposal the submodules are actually tracking a specific commit. This leads to an extra steps when it comes to committing updates: the submodule has in the `blender.git` has to be updated after commit to a submodule, but on another hand, it allows to ensure libraries are tests are at their proper state when bisecting. ## Directory layout The following directory layout is proposed: ``` blender/ * release/datafiles/ * assets/ -> assets.git * publish/ * ... * README.txt * lib/ * darwin_x64/ -> lib_darwin_x64.git * darwin_arm64/ -> lib_darwin_arm64.git * linux_x64/ -> lib_linux_x64.git * windows_x64/ -> lib_windows_x64.git * tests/data/ * benchmarks/ -> benchmarks.git * files/ -> test_files.git (renamed from svn/tests Subversion directory) ``` ## Saving disk space It is undesirable that all checkouts of `blender.git` will checkout libraries for all platforms. it seems to be possible to utilize the `update` submodule [configuration](https://git-scm.com/docs/gitmodules#Documentation/gitmodules.txt-submoduleltnamegtupdate). From the local prototype the `.gitmodules` could look similar to this (note the `update = none` for the libraries): ``` [submodule "lib/linux"] update = none path = lib/linux url = ../lib_linux.git [submodule "lib/windows"] update = none path = lib/windows url = ../lib_windows.git [submodule "release/datafiles/assets"] path = release/datafiles/assets url = ../assets.git ``` With such configuration doing `git submodule update` will skip the libraries: ``` $ blender (main) % git submodule update Skipping submodule 'lib/linux' Skipping submodule 'lib/windows' Cloning into '<DIR>/blender/release/datafiles/assets'... done. Submodule path 'release/datafiles/assets': checked out '<HASH>' ``` In order to make the libraries updated the following command (or similar to other platform) can be used: `git config --local submodule."lib/linux".update checkout`: ``` $ blender (main) % git config --local submodule."lib/linux".update checkout $ blender (main) % git submodule update Cloning into '<DIR>/blender/lib/linux'... done. Skipping submodule 'lib/windows' Submodule path 'lib/linux': checked out '<HASH>' ``` ## Updating after commit to the submodule When a commit is done to a submodule a parent repository (`blender.git`) needs to be updated as well. The easiest workflow seems to be: - People who work on the content of the submodule commit to its repository from within the submodule directory. For example, if a new reference image is to be committed it is to be done from `tests/data/files` folders. - From the `blender.git` checkout: - `git add <path/to/module>`. For example, `git add tests/data/files`. - `git commit` and `git push` as usual ## Update automation For the `make update` will take care of the following things: - Ensure that the submodules are at the state at which the parent repository points to - Enables the libraries for the current platform (set the `update` to `checkout`) ## Caveats - It is not possible to share libraries in a work-tree configuration. Which can actually be good in some cases, because it allows to have `main` and `blender-v3.6.release` branches to use their own libraries. - Commit to a submodule might need an extra care as the `make update` might put it to a detached head. A manual step to put it to a desired branch before commit might be needed. ## Plan - Create for-now empty Git LFS repositories - Create configuration in the `blender.git` - Update the `make update` - Revoke commit access to Subversion from almost everyone (platform maintainers needs access to commit security fixes for LTS) - Remove Subversion configuration from buildbot - Commit content of Subversion to Git LFS - Switch CMake configuration to use submodule directories instead of Subversion - ... - Profit

Sergey Sharybin added the

Type

Design

label 2023-06-14 15:28:47 +02:00

Brecht Van Lommel commented

2023-06-14 18:46:10 +02:00

One issue this does not solve is that pull requests can't include new or updated test files, which means they can't be tested on the buildbot. A solution would be to store those files in the main Blender repository with LFS.

However using LFS for the main repository does imply that you can't easily switch git commits while offline. Through there must be ways to do it, by either downloading the entire history or skipping LFS updates somehow. Actually I guess the same problem exist when using libraries as submodules, that would also require internet access when switching to a commit with libraries changes. But those are updated less frequently.

It would be interesting to hear other's opinions on this. Personally I'd happily make this trade-off to be able to include tests in pull requests, but it's not a change to make lightly.

One issue this does not solve is that pull requests can't include new or updated test files, which means they can't be tested on the buildbot. A solution would be to store those files in the main Blender repository with LFS. However using LFS for the main repository does imply that you can't easily switch git commits while offline. Through there must be ways to do it, by either downloading the entire history or skipping LFS updates somehow. Actually I guess the same problem exist when using libraries as submodules, that would also require internet access when switching to a commit with libraries changes. But those are updated less frequently. It would be interesting to hear other's opinions on this. Personally I'd happily make this trade-off to be able to include tests in pull requests, but it's not a change to make lightly.

Brecht Van Lommel commented

2023-06-14 18:48:59 +02:00

Also to summarize some of the advantages of this migration:

Get exact right library versions when switching between commits, for easy bisecting.
Ability to have repositories on Gitea, including history, references between commits and issues, auto closing issues, etc
Contribution to repositories like assets could go through pull requests.
Include tests changes in pull requests (if agreed).
Fewer tools to install and learn, only Git needed.

Also to summarize some of the advantages of this migration: * Get exact right library versions when switching between commits, for easy bisecting. * Ability to have repositories on Gitea, including history, references between commits and issues, auto closing issues, etc * Contribution to repositories like assets could go through pull requests. * Include tests changes in pull requests (if agreed). * Fewer tools to install and learn, only Git needed.

Ray molenkamp commented

2023-06-14 19:06:45 +02:00

I'm not experienced enough with git-lfs to make any worth while contribution to this discussion

I do have a concern this setup will break my current workflow, which is like this:

BlenderGit/
├─ Lib - symlink to any of the folders below/
├─ lib_main/  ( https://svn.blender.org/svnroot/bf-blender/trunk/lib ) 
│  ├─ win64_vc15
│  ├─ tests
├─ lib_293/  ( https://svn.blender.org/svnroot/bf-blender/tags/blender-2.93-release/lib/win64_vc15 ) 
│  ├─ win64_vc15
│  ├─ tests
├─ lib_330/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.3-release/lib/win64_vc15 )
│  ├─ win64_vc15
│  ├─ tests
├─ lib_340/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.4-release/lib/win64_vc15 )
│  ├─ win64_vc15
│  ├─ tests
├─ lib_350/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.5-release/lib/win64_vc15 )
│  ├─ win64_vc15
│  ├─ tests

I keep several releases checked out simultaneously in their own folders and symlink lib to what i need depending on the branch I am in, as I literally can't afford to wait an hour for the libs to download/update every time I switch a branch. I would get nothing done if i switch between the release branch and main a few times a day.

Additional todo: if we're going to have a significant amount of binaries in the source tree, the make source_archive/source_archive_complete likely needs some work to exclude these folders.

I'm not experienced enough with git-lfs to make any worth while contribution to this discussion I do have a concern this setup will break my current workflow, which is like this: ``` BlenderGit/ ├─ Lib - symlink to any of the folders below/ ├─ lib_main/ ( https://svn.blender.org/svnroot/bf-blender/trunk/lib ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_293/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-2.93-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_330/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.3-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_340/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.4-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_350/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.5-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ``` I keep several releases checked out simultaneously in their own folders and symlink `lib` to what i need depending on the branch I am in, as I literally can't afford to wait an hour for the libs to download/update every time I switch a branch. I would get nothing done if i switch between the release branch and main a few times a day. Additional todo: if we're going to have a significant amount of binaries in the source tree, the `make source_archive/source_archive_complete` likely needs some work to exclude these folders.

Brecht Van Lommel commented

2023-06-14 19:17:19 +02:00

Two potential solutions to that problem:

Have multiple worktrees of the Blender repository. That way they can share the .git folder and any local branches and stashes, but still have different versions checked out.
Set the LIBDIR CMake variable to a different value for every build folder, and don't use the submodules.

We could of course not use submodules too, and instead do what we do for make update of addons but with a specified commit hash so somewhere. I'm not sure that's fundamentally different, but maybe there is some benefit to keeping this under more manual control rather than having git switch things for us.

Two potential solutions to that problem: * Have multiple worktrees of the Blender repository. That way they can share the .git folder and any local branches and stashes, but still have different versions checked out. * Set the `LIBDIR` CMake variable to a different value for every build folder, and don't use the submodules. We could of course not use submodules too, and instead do what we do for `make update` of addons but with a specified commit hash so somewhere. I'm not sure that's fundamentally different, but maybe there is some benefit to keeping this under more manual control rather than having git switch things for us.

Sergey Sharybin commented

2023-06-14 19:28:04 +02:00

@LazyDodo I guess you already not relying on the make update, otherwise it will "ruin" the SVN checkout which symlink is pointing to. If that's true, I think there is a third option:

Keep the windows's libraries submodule at update = none (which is the default), and make it lib/windows_x64 be a symlink to one of git-lfs checkouts done somewhere else. Not sure what git status performed in the parent repository will tell you in this case though :)

@LazyDodo I guess you already not relying on the `make update`, otherwise it will "ruin" the SVN checkout which symlink is pointing to. If that's true, I think there is a third option: * Keep the windows's libraries submodule at `update = none` (which is the default), and make it `lib/windows_x64` be a symlink to one of git-lfs checkouts done somewhere else. Not sure what `git status` performed in the parent repository will tell you in this case though :)

Ray molenkamp commented

2023-06-14 22:15:43 +02:00

I have to admit, i'm not married to my workflow, as long as I can quickly (< 5 mins) switch libs I'm fine, HDD space and bandwidth are essentially infinite these days my time however is not. That being said, users on metered connections will likely not share that sentiment.

Sergey Sharybin referenced this issue

2024-02-07 16:21:58 +01:00

Switch SVN to Git submodules using Git-LFS #117946

Sergey Sharybin commented

2024-02-07 16:28:43 +01:00

Started the Blender-side changes needed to implement the proposal: #117946

There are a couple of things which can not easily be submitted as PR:

Conversion of libraries from SVN to Git-LFS
Initialization of submodules

Attached scripts which I used locally to perform those steps.

The SVN to Git-LFS conversion is done taking the following things in mind:

Only 3.3, 3.6 and trunk are converted. Those are the only tracks which are still active
The repository name is more closely aligned with platform/architecture naming used by release names
Linux libraries are merged from two directories to a single repository with several branches
Branch names are aligned to the ones used in Git (blender-v*-release)

For the next steps:

Port 4.1 libraries to corresponding branches in the SVN->Git conversion
Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons?
Do we want assets to be a real Git submodule, or we handle it as add-ons as well?
We'll need to have some down-time from libraries update, finalize SVN->Git migration, and then finalize the code-side changes, including ensuring CI/CD works fine

Started the Blender-side changes needed to implement the proposal: #117946 There are a couple of things which can not easily be submitted as PR: - Conversion of libraries from SVN to Git-LFS - Initialization of submodules Attached scripts which I used locally to perform those steps. The SVN to Git-LFS conversion is done taking the following things in mind: - Only 3.3, 3.6 and trunk are converted. Those are the only tracks which are still active - The repository name is more closely aligned with platform/architecture naming used by release names - Linux libraries are merged from two directories to a single repository with several branches - Branch names are aligned to the ones used in Git (blender-v*-release) For the next steps: - Port 4.1 libraries to corresponding branches in the SVN->Git conversion - Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons? - Do we want assets to be a real Git submodule, or we handle it as add-ons as well? - We'll need to have some down-time from libraries update, finalize SVN->Git migration, and then finalize the code-side changes, including ensuring CI/CD works fine

add_submodules.sh

919 B

convert_lib_to_git.sh

6.1 KiB

Brecht Van Lommel commented

2024-02-07 17:07:21 +01:00

The repository names use underscores, but we use dashes for existing repositories. I think we should be consistent.

We also use the blender- prefix usually, but I can see the motivation for leaving it our here as it's a bit redundant with the organization and the libs are used by Cycles standalone. Maybe some would still benefit from the prefix, like blender-test-data.git and blender-assets.git?

Maybe the tests directory structure could be a bit flatter for convenience?

tests/data -> blender-test-data.git
tests/benchmarks -> benchmarks.git

For these others we could consider:

asset_bundles -> asset-bundles.git
packages -> lib-source.git
resources: put the single icon_geom in assets.git?

The repository names use underscores, but we use dashes for existing repositories. I think we should be consistent. We also use the `blender-` prefix usually, but I can see the motivation for leaving it our here as it's a bit redundant with the organization and the libs are used by Cycles standalone. Maybe some would still benefit from the prefix, like `blender-test-data.git` and `blender-assets.git`? Maybe the tests directory structure could be a bit flatter for convenience? * `tests/data` -> `blender-test-data.git` * `tests/benchmarks` -> `benchmarks.git` For these others we could consider: * asset_bundles -> `asset-bundles.git` * packages -> `lib-source.git` * resources: put the single `icon_geom` in `assets.git`?

Sergey Sharybin commented

2024-02-07 17:17:48 +01:00

Replacing underscore with dash shouldn't be a bit of a deal.
Could be a bit weird though: lib-windows-x64 ?

The tests directory can indeed become flatter.

I've put the scripts to the PR now.
We can also sit together, and do the adjustments. Will be faster than bouncing comments.

Replacing underscore with dash shouldn't be a bit of a deal. Could be a bit weird though: `lib-windows-x64` ? The tests directory can indeed become flatter. I've put the scripts to the PR now. We can also sit together, and do the adjustments. Will be faster than bouncing comments.

Ray molenkamp commented

2024-02-07 17:28:57 +01:00

While windows libs have been ABI stable ever since vs2015, there is no guarantee it will stay this way, lib-windows-x64 may be too generic? on the other hand, it hasn't broken in 9 years, we could just cross that bridge when we get there...

While windows libs have been ABI stable ever since vs2015, there is no guarantee it will stay this way, `lib-windows-x64` may be too generic? on the other hand, it hasn't broken in 9 years, we could just cross that bridge when we get there...

Sergey Sharybin commented

2024-02-07 17:32:16 +01:00

@LazyDodo For that I though it will be easier and flexible to use branches. Similar to how eventually a newer glibc ABI will replace Linux libraries.

Brecht Van Lommel commented

2024-02-07 20:35:20 +01:00

For the ABI, I guess the question is if we ever want to support two ABIs and two sets of libraries at the same time. Probably best to deal with that if it becomes a problem.

For the underscores vs dashes, I forgot to mention that we probably want to keep the folder name with underscore for consistency, just the repo name would use dashes I think. The repo name for libs could also be e.g. lib-window_x64.

For the next steps:

Port 4.1 libraries to corresponding branches in the SVN->Git conversion

Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons?

Do we want assets to be a real Git submodule, or we handle it as add-ons as well?

I'm not immediately sure. Currently I don't think we care about these being tightly connected to any particular Git revision, so not having them as a submodule seems most convenient.

Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them. So maybe the asset should be connected, but the benchmarks not? It would be a bit less convenient that a Blender developer would have to do something when studio artists update these. But I guess it's justified.

For the ABI, I guess the question is if we ever want to support two ABIs and two sets of libraries at the same time. Probably best to deal with that if it becomes a problem. For the underscores vs dashes, I forgot to mention that we probably want to keep the folder name with underscore for consistency, just the repo name would use dashes I think. The repo name for libs could also be e.g. `lib-window_x64`. > For the next steps: > - Port 4.1 libraries to corresponding branches in the SVN->Git conversion > - Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons? > - Do we want assets to be a real Git submodule, or we handle it as add-ons as well? I'm not immediately sure. Currently I don't think we care about these being tightly connected to any particular Git revision, so not having them as a submodule seems most convenient. Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them. So maybe the asset should be connected, but the benchmarks not? It would be a bit less convenient that a Blender developer would have to do something when studio artists update these. But I guess it's justified.

Sergey Sharybin commented

2024-02-07 21:55:05 +01:00

The repo name for libs could also be e.g. lib-window_x64

Sounds good to me. Can also think of it as an alternative to "lib/windows_x64". Not sure it is important or just me seeing patters :)

Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them.

Or when some node group becomes incompatible with some Blender version, having stronger coupling seems to reduce risk of things getting out of sync.
Unfortunately, it seems that we'd better spent a bit more educated guess now, as changing between "floating module" and git-submodule is not impossible, but is disruptive, especially for bisect.
Perhaps we can have a quick talk with Dalai, Julien, and Simon and see if they feel strongly about having them "floating".

For the benchmarks, it seems easiest to keep it "floating". Will save us from fitting it into the make_update.py, we'd just need to git-ignore, and then it will be manual checkout for the initial svn->git switch, and then we can add it to the helper scripts. Kinda to scope things a bit more narrow.

One thing I don't really understand, is whether we need to do anything with the asset_bundles:

Can we just get the latest snapshot of all active tracks/branches, or do we need full history?
Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check

Ah, one more thing I forgot to mention: we'd need to set-up permissions on the repositories. Is easy, but we should not forget about it :)

> The repo name for libs could also be e.g. `lib-window_x64` Sounds good to me. Can also think of it as an alternative to "lib/windows_x64". Not sure it is important or just me seeing patters :) > Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them. Or when some node group becomes incompatible with some Blender version, having stronger coupling seems to reduce risk of things getting out of sync. Unfortunately, it seems that we'd better spent a bit more educated guess now, as changing between "floating module" and git-submodule is not impossible, but is disruptive, especially for bisect. Perhaps we can have a quick talk with Dalai, Julien, and Simon and see if they feel strongly about having them "floating". For the benchmarks, it seems easiest to keep it "floating". Will save us from fitting it into the `make_update.py`, we'd just need to git-ignore, and then it will be manual checkout for the initial svn->git switch, and then we can add it to the helper scripts. Kinda to scope things a bit more narrow. One thing I don't really understand, is whether we need to do anything with the `asset_bundles`: - Can we just get the latest snapshot of all active tracks/branches, or do we need full history? - Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check Ah, one more thing I forgot to mention: we'd need to set-up permissions on the repositories. Is easy, but we should not forget about it :)

👍 1

Brecht Van Lommel commented

2024-02-08 16:59:42 +01:00

One thing I don't really understand, is whether we need to do anything with the asset_bundles:

Can we just get the latest snapshot of all active tracks/branches, or do we need full history?

Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check

As far as I know it's just files that are available for download here, and not connected to Blender build and packaging.
https://www.blender.org/download/demo-files/

Once the extensions website is online, these assets should become available there. So maybe it's a more a general question, if we have any officially maintained asset extensions, where do we put the Git repository?

Since it's effectively done by the Blender Studio right now, maybe it belongs in the studio/ organization?

> One thing I don't really understand, is whether we need to do anything with the `asset_bundles`: > - Can we just get the latest snapshot of all active tracks/branches, or do we need full history? > - Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check As far as I know it's just files that are available for download here, and not connected to Blender build and packaging. https://www.blender.org/download/demo-files/ Once the extensions website is online, these assets should become available there. So maybe it's a more a general question, if we have any officially maintained asset extensions, where do we put the Git repository? Since it's effectively done by the Blender Studio right now, maybe it belongs in the `studio/` organization?

Sergey Sharybin referenced this issue from a commit

2024-02-22 13:51:09 +01:00

Switch SVN to Git submodules using Git-LFS

Sergey Sharybin referenced this issue

2024-02-22 17:50:47 +01:00

Blender 3.6: Switch SVN to Git submodules using Git-LFS #118628

Sergey Sharybin referenced this issue from a commit

2024-02-22 19:57:53 +01:00

Blender 3.6: Switch SVN to Git submodules using Git-LFS

Bastien Montagne referenced this issue

2024-02-22 20:26:59 +01:00

Blender LTS: Maintenance Task 3.6 #109399