I’ve recently had a few discussions about this with other Cinder devs and I was curious how everyone else tackles this in a production environment: Where do you put your Cinder project folders and how do you deal with version dependencies?
A: All projects inside Cinder folder (Cinder/my-project)
B: All projects inside Cinder subfolder (Cinder/projects/my-project)
C: Independent project and Cinder folders (C:/Cinder and C:/Users/.../my-project)
D: Cinder submodule inside each project (my-project/Cinder)
I currently have about a dozen projects across several Cinder versions (not counting prototypes/scratchpads) ranging from 0.8.6 to 0.9.2 dev, all of which are still out in the wild and could require me to get back up and running at any point.
We typically face following questions with each new project:
How do you capture where your project should be cloned to in relation to Cinder?
How do you capture dependencies to a specific Cinder version? Submodule? Readme?
How do you deal with multiple projects across multiple Cinder versions?
How do you ensure the specific Cinder version persists in the future? Do you fork and/or tag?
If you use Cinder as a submodule, how do you handle limited disk storage? Do you use shallow git clones? Do you wipe build files?
Currently—mostly because this is “the way we’ve always done things”—we put all of our projects in a shared Cinder folder for each minor version. So my Cinder directory looks like (Cinder-0.9.0/project-a, Cinder-0.9.0/project-b, Cinder-0.9.1/project-c, …).
I’m really curious how everyone else tackles this and would love to find a way that solves all of the above while being friendly to our small laptop drives. If you have any other suggestions I’ll update the poll above to capture.
Just as a brief comment, at Rare Volume we include Cinder as a submodule for “real” projects that warrant it. This is inside of the project folder, which as a side-effect costs some disk space but keeps things self-contained and reproducible.
We maintain an internal copy (technically a fork) of Cinder which we can easily create project-specific branches on if we need to. That way if we have a project-specific patch to make we can do so without impacting other projects. Also for a lightweight checkout, Cinder can be cloned with a depth of 1 to minimize size.
For experiments and similar I just maintain a consistent relative path to Cinder (e.g. ../../cinder_master) to cut down on disk space. Not perfect but it generally seems like the right trade-off between disk costs and “perfect”.
Once we’re able to free Cinder of the remaining Boost binaries, I’d like to either rewrite git history or start a fresh repo to reduce its size. However Cinder binaries are likely to always be too big to make cloning Cinder per-project a viable approach.
Thanks for sharing your process, Andrew. Sounds like a pretty robust and self-contained solution and that addresses most of our issues too. I’d much rather have the security of having a snapshot of the full codebase for each project than saving some disk space and shallow submodules sound interesting.
For the folks who use independent folders, how do you deal with different Cinder versions across projects? Do you roll back to certain commits/tags or do you usually upgrade older projects when necessary?
I use independent folders, I only got Cinder 0.9.2 and Cinder 0.8.6 folders and it’s fine for my workflow.
But I might switch to Andrew’s way because I now face a problem with rendering which seems to be impacted by the latest changes this year…
Just wanted to add my two cents by saying I use the same method as Andrew. Disk space is not really an issue these days, with Terabytes of storage space per drive. Download/upload speeds might be more of an issue when downloading large repositories, but living in The Netherlands I have pretty fast internet.
A cheap GitHub account allows you to have an almost limitless number of repositories. So if drive space does become an issue, I can simply store old projects on GitHub, then delete the local repo. Yes, I like to live on the wild side.
I have a cinder folder per official release, and one in sync with master. I will lock a project to a cinder version through its duration, and that version is guaranteed to by identical to the release downloadable from the cinder website. Any experiments I’ll use the bleeding edge version, and any new projects use the latest official release available.
I’m always short on disk space - particularly in boot camp. I can generally only afford one or two builds of Cinder, boost and Open CV. I’ve tried using git submodules with directory forks and various other clever things but it’s always a pain (particularly across platforms) so these days I just add a text file to the root of each project listing which commit of Cinder to build against, plus any peculiar build settings I need such as dynamic-vs-static runtime.
Any blocks used by a project that aren’t included with Cinder I will put into a libs folder in the project either as a copy (preferable if it’s stable) or submodule if I might edit it and push those changes.
The exceptions are Open CV and Boost which have massive binaries. I tend to keep these separate like I do with Cinder and make notes in the text file.
Thanks all, this is super insightful. We’re most likely going to move to submoduling too. Unfortunately disk space is a very real issue for us too (mostly work on laptops + bootcamp), but with forking, tagging + submoduling I’d feel much more relaxed about wiping a project from my drive since everything is captured
Static libs is a whole other story and we too try to commit them whenever appropriate + tagging exact build settings (platform, version, flags).
