On 01/28/2016 02:28 PM, Stephan Eggermont wrote:
On 28-01-16 19:26, Dale Henrichs wrote:
Well, this is a direction that could be taken, but there some advantages to sharing the actual checkouts ... in my workflow, I have a collection of git repos that represent my current base system and I have a number of stones (images) that share this same base system and when I make a bugfix in one, I am interested in being able to easily load the bugfix into the other stones before starting work in that particular stone so having a shared "current directory" amongst a set of stones is actually convenient .... this "convenience" also extends to building a new stone (image) since the build scripts only need to load from the currently checkout versions without having to know the specific SHA of interest ...
So we'd basically have a directory of vms, one of image templates and one of git repos, and a project directory where I'd make a particular combination of the three? Or when multi-platform a platform directory above the vms and images one?
Stephan, It does make sense to begin thinking about a structure that makes sense for Pharo. In GsDevKit_home, I have a $GS_HOME env var that points to the root of the directory structure for a collection of stones and the top-level directory structure looks like the following: ⸠$GS_HOME ⸠bin/ ⸠dev/ ⸠docs/ ⸠etc/ ⸠server/ ⸠shared/ ⸠sys/ ⸠tests/ ⸠travis/ and for just the stones and git structure, I have the following: ⸠$GS_HOME â¾ server/ ⸠stones/ ⸠<stone-name-1>/ ⸠git/ ⸠product/ ⸠<stone-name-2>/ ⸠git/ ⸠product/ ⸠<stone-name-3>/ ⸠git/ ⸠product/ â¾ shared/ ⸠downloads/ ⸠products/ ⸠repos/ where: - $GS_HOME/shared/repos is the location for the shared git repositories - $GS_HOME/shared/downloads/products is the location of the GEMSTONE distibution basically vms and templates - $GS_HOME/server/stones/<stone-name-1> is the location of the stone-specific files and directories. - $GS_HOME/server/stones/<stone-name-1>/product is a symbolic link from the stone to the $GS_HOME/shared/downloads/products/<gemstone-product> directory - $GS_HOME/server/stones/<stone-name-1>/git is the standard location for stone-specific git clones You can see that I make provision for "shared repos" and "stone-specific" repos --- the stone-specific repo comes into play only occasionally but making a provision for this possibility is useful on the odd occasion when you are going to do protracted work on one of the shared repositories and that work is likely to break something important ... I think of the stone-specific directories as transient and once the work is done and integrated into the shared/repos git repo, the local clone is destroyed... So in your case you might have something like this: â¾ projects/ â¾ <project-1>/ ⸠git/ ⸠project.image ⸠project.changes/ â¾ <project-2>/ ⸠git/ ⸠project.image ⸠project.changes/ ⸠repos/ ⸠templates/ ⸠vms/ The idea with the projects directory is that you might have a multiple images in play at once and the <project-n> directory would give you isolation for independent git repos as well as other artifacts that should be kept separate ... If it makes more sense to keep all of the image and changes files in a common directory, then an perhaps the following would be more appropriate: â¾ projects/ ⸠<project-1>.image ⸠<project-1>.changes ⸠<project-2>.image ⸠<project-2>.changes â¾ git/ ⸠<project-1>/ â¸<project-2>/ ⸠repos/ ⸠templates/ ⸠vms/ or something different:) For GemStone it is necessary to to dedicate a directory per stone, because of the volume of files/directory involved: ⸠backups/ ⸠bin/ ⸠extents/ ⸠git/ ⸠logs/ ⸠product/ ⸠snapshots/ ⸠stats/ ⸠tranlogs/ For Pharo, there might not need to be such separation on a per image/changes combo, although I can image that applications may indeed need additional files or directories associated in which case a directory per image would be useful ... Well I think this just about covers most of the things I was going to talk about on the topic of "sharing git repos between separate active images. Dale