Enrique,
You have my sympathies - the Nuclear industry can be cautious...
One technique that is relatively new to Git is the ability to checkout into
separate worktrees (I haven't used them myself) which should allow you to
checkout the different versions into their different worktrees (directories).
Philip
----- Original Message -----
From: ThermoX
To: Git for human beings
Sent: Wednesday, January 11, 2017 1:47 PM
Subject: [git-users] Re: git directory/repo structure suggestions
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.
a.. .\Common\Bin
b.. .\Common\Lib
c.. .\Common\Include
d.. .\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...
a.. .\MainProject1
b.. .\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.
--
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.
