I want to use Git to store and version data efficiently, but I also want to be able to change revisions on demand.
So I want to use Git with many branches instead of the usual revisions. For every “version” of my data there will be a branch.
Only a few files will change per branch and there would be 1-10 revisions per branch, depending on how often a certain revision has to change.
So the file/data load would be almost normal, I would only have a lot of branches instead of revisions.
I know that this is a strange way to use Git, but would it scale?
dbyrne asked for the usecase. I am not sure if helps, but here it is:
- I plan to version Vagrant metadata
- I have some project in a separate SCM (e.g. SVN) and every revision belongs to a Vagrant VM
- Every Vagrant VM has metadata and install files, which will often be the same for many revisions
- Sometimes I have to change the metadata and I need to support branches of my project, so I wanted to use Git branches for every revision
- My application will keep track of project revisions and Git metadata
- My application will check out the relevant files for every given project version
- With the metadata it is possible to aromatically create a VM for every project revision
In general, git handles branching very efficiently. You can switch back and forth between branches very quickly, and they have a small footprint because each branch only stores the delta (not an entire copy).
How many branches are you planning to have? I think a little more background about your use case might be helpful in answering this question.