3 ms·

Out of curiosity, when storing new files how do you decide between Data and Development drives or is Data fully unrelated to Development context?

• robomartin 14y ago
  I added a "Development" drive as an experiment a few years ago. I'm still on the fence about it. I own more than one business and we also do work for other businesses, so, generally speaking, the "Data" drive holds business data partitioned-off into appropriately-named directories. I also have what I call "support" directories there. For example, I have a "SolidWorks Support" directory with models, macros, tools and other items that are there to support work with that software. The same is true of Photoshop, Altium Designer, Web Design and other segmentable tasks. Then there's more mundane stuff, like "Digital Photography", "Personal", "Scans", "Temp", "Outlook Data", etc. Projects started to kind of pollute the data drive in some form. Also, the directory hierarchy started to become a little crazy. For example: D:\<company name>\Projects\<project name>\Design\Mechanical\<project work folder>\Suppliers D:\<company name>\Clients\<client name\... Even there were hardware, embedded and web projects with their own requirements. And, even though we use Git, I still have the habit of making full copies of directories every so often to freeze thing in time. With projects such as Solidworks mechanical designs or some electronics designs using source control can be painful, so, full backup copies of work directories works very well. Storage is cheap. At one point I thought that I should segregate active development from finished or shipping product. In other words, make a distinction between "project" and "product". That's why I introduced the "Develpment" drive. There's another reason. When doing FEA thermal and/or flow simulation for various projects the Data drive started to become clogged-up with simulation data. As you navigate through many iterations of design ideas and simulations you can easily fill-up gigabytes. I didn't think that this belonged anywhere near the "Data" drive. Finally, some tools (Xilinx ISE back then) did not take kindly to paths with spaces. So I always had to have a separate folder for Xilinx projects which has always bothered me. This "Development" drive now allows me to create a simple folder with a short path: Z:\ProjectA This "feels" simpler and it "feels" like the right way to do it. I also have an "xampp-sites" folder on there for web projects. The projects can live in their own directories in the "Development" drive: Z:\TheNextFacebook Z:\TheNextGoogle These have full source control, work folders and generally contain all the work resources for a project (for example a Photoshop work directory). The "xampp-sites" directory is setup as the testing server and only sees an upload of the files that would normally go to the real production server (easy to do with tools such as Dreamweaver --which is never used in design mode here!). Once a "project" graduates to being a "product" it is zipped-up and copied or moved into a "Products" folder under the appropriate company directory in the "Data" drive. As an example, if we are talking about an iOS project it turns into a product once it is submitted to the app store and approved. The jury is still out on whether or not this is a good idea or simply a reflection of being insanely anal about organizing data. I don't know. I am always open to new and interesting ideas on this front. I try to think of the "Development" drive as a dirty or work drive of sorts where I can mess with a lot of things without polluting the "Data" drive. I have this implemented in one machine and have not been compelled to do so in other machines yet. Still thinking about it.