Closed ccarouge closed 10 months ago
We will probably need to change the way we specify CABLE branches (realisations). We currently specify branches using the path
and revision
keys.
I propose we replace the path
and revision
keys with a repo
key which can be used to specify an SVN repository or a Git repository:
realisations:
- repo:
svn:
path: branches/Users/foo/my_branch
revision: 123
realisations:
- repo:
git:
branch: 136-some-feature-branch
commit: bc08348
I want to create an interface that abstracts away the version control system being used, i.e. create a new utility module utils/repo.py
that contains the following
class Repo(AbstractBaseClass):
@abstractmethod
def checkout(self, verbose=False):
pass
@abstractmethod
def get_revision(self) -> str:
pass
and have concrete implementations of this with a git and svn backend.
However the names repo.py
and Repo
might be confused with repository.py
and CableRepository
. I'm thinking I would like to rename repository.py
to model.py
and CableRepository
to Model
. This is mostly semantics but I think we should differentiate these two classes if possible.
Once we remove checkout
and get_revision
from the CableRepository
class, don't we just end up with a ModelBuild
class instead of a Model
class?
@ccarouge I think I prefer Model
over ModelBuild
because the class is also a data structure for each "model" specified in realisations
. E.g. it seems more natural to me that a Task is comprised of a Model
rather than a ModelBuild
.
We will need to address #199 because the CABLE GitHub repository has a different directory structure to the SVN repository. Any hard coded paths to files located in the CABLE repository will fail when working with the Git version.
I like the list of sub-issues. 👍
We need this to be released on time for the CABLE transition to GitHub. Should we have both options available at first if we need to compare with something that hasn't been moved to GitHub?