- cloning large legacy systems are often too large in disk space to actually clone the repository, not because the bare source code files and resources are large, but that the version control software itself takes probably more than 90% of the disk space usage for the repository.
- It feels that even though we’ve gone so far ahead with in the software industry we’re still lacking more advanced tools for versioning our software more efficiently.
- We need more creative ways or options to allow us to work with large repositories much easier.
- Sure we have distributed version control, maybe we can have sharded or partially distributed version control software too where not all of the history for every single file is kept locally. Why would we need all this history for daily dev activities? they’re never needed to build a project, only to understand and to revert to early versions of the codebase. Surely we can split the need for daily version control with legacy or historical version control?
- git’s general interface to work with is pretty okay. Some of the commands can be cleaned up for daily version control activities but that’s another topic for another day.
- I’ve posted about this previously that git allows you to shallow clone a repository like git clone https://somerepo.git –depth=1
- It’s a great option but not a first class citizen for working with git. No where near default behaviour that the average git user is aware off.
- I’d love to formulate some concepts for new version control software. Need to read up on diff algorithms: https://en.wikipedia.org/wiki/Diff
Version control software
by
Tags:
Leave a Reply