Project

General

Profile

Enstore Git

Quick Start

Git Quick Start

  • clone enstore source tree
  • install and initialize 'git workflow' in your repository
  • rebuild git subtree if you need to support enstore dependencies like ftt and commit code upstream

git subtree and Enstore subprojects

CVS repository has several modules to keep Enstore code and dependencies. It also contains configuration files used in production system.
We follow this structure and also copied configuration files to separate repository. We split project into three sub projects as different people will access the code.
In Redmine the project can have subprojects. Each subproject can have multiple repositories.

Projects:

Repositories:

enstore - this is where all enstore code resides, including dependencies merged with git subtree
https://cdcvs.fnal.gov/redmine/projects/enstore/repository

core - the core enstore code. This is enstore2 CVS module converted to git.
https://cdcvs.fnal.gov/redmine/projects/enstore/repository/core

this is enstore2 module in CVS directly accessed by redmine.
https://cdcvs.fnal.gov/redmine/projects/enstore/repository/cvs-enstore2

https://cdcvs.fnal.gov/redmine/projects/ftt/repository

  • project:enstore-deps - several OpenSource projects. code converted from CVS module to git repository

DBUtils
https://cdcvs.fnal.gov/redmine/projects/enstore-deps/repository/dbutils

gadfly
https://cdcvs.fnal.gov/redmine/projects/enstore-deps/repository/gadfly
HTMLgen
https://cdcvs.fnal.gov/redmine/projects/enstore-deps/repository/htmlgen

psycopg2
https://cdcvs.fnal.gov/redmine/projects/enstore-deps/repository/psycopg2

PyGreSQL
https://cdcvs.fnal.gov/redmine/projects/enstore-deps/repository/pygresql

xml2ddl
https://cdcvs.fnal.gov/redmine/projects/enstore-deps/repository/xml2ddl

  • project:enstore-config*

enstore-config - we split selected configuration files from enstore/etc into enstore/config directory to be managed by SSA
https://cdcvs.fnal.gov/redmine/projects/enstore-config/repository

git subtree

git has 'modules' but reportedly there are some issues with that, you may look for discussion elsewhere.

We use 'git subtree' contributed project to git project. It comes with git distribution but it needs to be rebuild separately.
https://github.com/git/git/tree/master/contrib/subtree
https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt

git subtree works in way that we 'merge' external "module" like ftt (or htmlgen,...) as directory in core enstore tree (like /opt/enstore), and all files from all subtrees present when you do clone or pull.

We did merge once and do not expect to do 'split' and 'merge' very often. As a practical matter we will work with the merged code in 'main' enstore repository and use repositories for dependencies if we need to push code upstream.

We do not do modifications to subtrees very often. When there is need for such modification, we can 'split' subproject and contribute changes to upstream project.
The documentation suggests to avoid committing files from different subtrees in the same commit. Please do separate commit to each subtree. This will allow cleanly separate commits and history to different subtrees, like to enstore and ftt.

We used git subtree to split enstore configuration files into separate repository. git subtree operates with subdirectory, therefore we put (copied) configuration files into separate "config" directory where SSA can modify files.

git flow workflow

historically enstore team kept the 'production' releases on cvs trunk and tagged pristine code approved in code review with cvs tag 'production.' That version of code was tagged too as enstore release when code is released and rpm built.

We found there is git workflow model close to what we used with cvs and there is implementation as a set of git scripts.
We will keep 'pristine' code on develop branch and the final product leave on production branch with proper tags as release numbers.

During git flow initialization it is possible to select different names of branches, it suggests few as a choice, we use 'production' to name production branch.
When reading gitflow presentations and documentation please substitute "master" branch by "production."

See more details at page Git Flow

Reading