-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fs: support version_aware ? #207
Comments
What’s the difference between opening a new filesystem and this? |
@skshetry No difference, but possible to use in one place. Similar to how s3fs/etc supports it directly and not as a new fs instance (though that obviously doesn't make any sense for them since only files can be versioned and not directories). Having it all in one fs will allow us to treat it as we treat versioned filesystems. For example, to check if updates are available we could do it the same way we do it for |
Obviously this is kinda awkward when you start dealing with it initially, but it makes more sense the more you use it. Since we have s3fs/gcsfs/adlfs already and have to deal with those, it makes sense to consider the same for gitfs since they have a lot of similarities. Maybe it could be done with two filesystems |
With |
I have been thinking something similar on dvcfs side: TheOneFileSystem that can traverse between multiple revisions. But I just want to avoid filesystems in general. It already has gone too far. :) |
Stepping stone to simplifying `dvc fetch/pull` by using index. Fetch handles regular imports through index already, but not repo imports because their processing is much more involved (e.g. chained imports) in the current arch. With `FileStorage` support introduced into `DataIndex` and `datafs` supporting imports overall, `dvcfs` can now handle repo imports (even chained ones). This will soon allow us to handle repo imports the same way we handle regular ones, improve performance and get rid of a lot of messy code (e.g. DependencyRepo). Related iterative/scmrepo#207 Related iterative/dvc-data#315 Related https://github.com/iterative/studio/issues/5261
Stepping stone to simplifying `dvc fetch/pull` by using index. Fetch handles regular imports through index already, but not repo imports because their processing is much more involved (e.g. chained imports) in the current arch. With `FileStorage` support introduced into `DataIndex` and `datafs` supporting imports overall, `dvcfs` can now handle repo imports (even chained ones). This will soon allow us to handle repo imports the same way we handle regular ones, improve performance and get rid of a lot of messy code (e.g. DependencyRepo). Related iterative/scmrepo#207 Related iterative/dvc-data#315 Related https://github.com/iterative/studio/issues/5261
Stepping stone to simplifying `dvc fetch/pull` by using index. Fetch handles regular imports through index already, but not repo imports because their processing is much more involved (e.g. chained imports) in the current arch. With `FileStorage` support introduced into `DataIndex` and `datafs` supporting imports overall, `dvcfs` can now handle repo imports (even chained ones). This will soon allow us to handle repo imports the same way we handle regular ones, improve performance and get rid of a lot of messy code (e.g. DependencyRepo). Related iterative/scmrepo#207 Related iterative/dvc-data#315 Related https://github.com/iterative/studio/issues/5261
Stepping stone to simplifying `dvc fetch/pull` by using index. Fetch handles regular imports through index already, but not repo imports because their processing is much more involved (e.g. chained imports) in the current arch. With `FileStorage` support introduced into `DataIndex` and `datafs` supporting imports overall, `dvcfs` can now handle repo imports (even chained ones). This will soon allow us to handle repo imports the same way we handle regular ones, improve performance and get rid of a lot of messy code (e.g. DependencyRepo). Related iterative/scmrepo#207 Related iterative/dvc-data#315 Related https://github.com/iterative/studio/issues/5261
Currently, gitfs works on one single revision, but we could totally make
version_aware
version (similar to s3fs, gcsfs, adlfs) and support revisions asversion_id
. The implementation is fairly straightforward (just useTree
for a particularversion_id
and the rest is the same). This seems to make a lot of sense in dvc context of unifying get/import with get-url/import-url and gettind rid ofDependencyRepo
.The text was updated successfully, but these errors were encountered: