Details
- Reviewers
olasd - Group Reviewers
Reviewers - Commits
- rDSTOCe962cdd71772: RevisionVaultCooker: factor out tar creation function
rDSTOC327924dde65a: RevisionVaultCooker: add naive flatten implementation
R65:327924dde65a: RevisionVaultCooker: add naive flatten implementation
R65:e962cdd71772: RevisionVaultCooker: factor out tar creation function
rDSTOe962cdd71772: RevisionVaultCooker: factor out tar creation function
rDSTO327924dde65a: RevisionVaultCooker: add naive flatten implementation
Diff Detail
- Repository
- rDSTO Storage manager
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Hey,
There's a tiny bit of duplication that we should avoid now before we start adding more methods: the tar generation method should be moved to the base class.
That way we can centralize the "varying output format" logic, as well as the actual archive creation logic (we'll soon want to generate the file on-disk rather than in RAM).
So there's another problem with that: can there be multiple "output formats"? like, flattened tar, flattened zip, flattened git-ish tar, flattened git-ish zip? Should we differenciate the archive format from the output format?
Yeah, we should probably distinguish on "output format" rather than "archive format". However I don't think we need the two separate concepts.
(As an aside, I'm still not entirely convinced that providing a choice between zip and tar is worth the effort, as tar is superior in every way, and it's easy to support even on Windows)
In any case, "making a tar from a directory" sounds like something that we'll have to do a lot :)