Hi Enrique,
I think you have mixed requirements and prior practice here which are confusing
the issues.
Git is normally a SOURCE versioning system, so all those binary and library
parts should be considered to be stored elsewhere in you build environment (or
perhaps be sub-modules as they are rarely changing).
You then say that you must be able to change the directory names as the new
versions arrive. This sounds like a solution developed for a previous VCS. Try
unwinding that to get to your true requirement - in Git the same structure and
pathnames are used between branches (which often map to versions and features)
because it is very quick to swap out one branch and bring back the other
(almost instantaneous for moderate size projects - less than a network round
trip even).
Also have a look at the GitLFS (Large File System) as an adjunct to regular Git
to allow your bin and lib systems to exist at their relative versions.
The main issue is to stop trying to re-implement an old VCS approach, but to
step back and use this as an oppotunity to modernise, ... and distribute
control to the devs (so they can and will use it), leaving just the approval of
versioning (e.g. by tagging) as the consolidated management activity. It's over
easy to misuse a VCS, as many approaches have shown ;-)
Philip.
----- Original Message -----
From: Enrique Benedicto
To: Git for human beings
Sent: Tuesday, January 10, 2017 3:10 PM
Subject: [git-users] git directory/repo structure suggestions
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.
