Hi Philip, Thanks for taking the time...
The requirements for different names does not come from a previous VCS. It comes from our particular work environment. I work on Nuclear Simulators and we have to have 2-3 active "loads" (which are simply different VCS Revisions) at any given time. It's a little involved to discuss the details here, but let's just say we need to be able to define a "load" simply by changing the main directory name on the Main Simulator Computer. Also, each "load" has access to all its source files so we can debug issues on the fly, if need be. Many of the projects within a load, are even compiled with additional debug information to catch things like divisions by zero (in thermodynamic calculations, for instance). So it's definitely not a standard environment. Yesterday, I tried one approach for the Common files and we'll see how that works in the long term. It's definitely prone to error but I'm usually the only one messing around with those files, so risks are more limited (unless I unexpectedly die). But what I decided to do is to basically have 2 .git projects for the Common files. One which only tracks the \Src (named .\Source Files in my original post) & \Include folders and ignores the \Bin & \Lib folders... The other which only tracks the \Bin, \Lib & \Include folders but ignores the \Src folder. When I want to change the Common code, I use the CommonSrc git repo. After I test everything and build all my final binaries, I update the revision on the CommonSrc repo. Then I can move my binary files over to the \CommonBin git repo and update the revision to match the number on the other repo. Finally... As far as tying the Common revision to the MainProjects... I still have to think about this one... Finally... as for GitLFS... I *have* looked into that... But I couldn't get it to work on a LAN and I was getting into all sorts of issues... So I eventually gave up on it. I also started to look into git-annex a couple of days ago. It *would* be nice to be able to properly implement one of those binary-handling options on a LAN, if I can figure out how. I really do appreciate the time you took to provide your ideas. If you have more comments, I'd be happy to hear them. Enrique That said... maybe I don't need to have the entire .git content under each "load" folder since each load will be able to be duplicated through the revision in git, defined somewhere else. On Tuesday, January 10, 2017 at 10:10:47 AM UTC-5, ThermoX wrote: > > I'm relatively new to git and I've been struggling to come up with a > directory/repo structure for our setup at work. So here's the current > directory structure and characteristics: > > > Common to all *MainProjects* defined below. These files don't change very > often. > > - .\Common\Bin > - .\Common\Lib > - .\Common\Include > - .\Common\Source Files... > > Below, *MainProject1* contains entirely different code than *MainProject2*. > HOWEVER, I must be able to tweak the names of the *MainProject* folders > to account for different revisions... So, for instance, > *MainProject1_ver1*, *MainProject1_ver2*, etc... > > - .\MainProject1 > - .\MainProject2 > > So typically, I would create a separate repo for the .\Common files. Then, > I'd create two separate repos for the *MainProjects* and simply rename > their container to match whatever revision they contained. However, the > *MainProjects* are tied to a specific version of the .\Common files. And > the .\Common files, which don't change often, would be "outside" of the > *MainProjects* repos. > > This almost sounds like I should have 2 superprojects, with .\Common & > .\MainProject1 in one superproject... and .\Common & .\MainProject2 in the > other superproject. But the problem with superprojects is that it *seems* I > won't be able to customise the *MainProject* names to reflect their > revision. > > > What's more... I don't want to recompile the .\Common binaries on all > instances of MainProjects. I simply want direct access to the binaries. In > this case, should I create 2 different repos for the .\Common files; one > which contains the source files and another which contains the generated > binaries only? If so, I'd create the above-mentioned superprojects out of > the "binary" version of the .\Common files? > > > This really is biting me... Just can't think of a good way of doing > this... Any help would be greatly appreciated. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
