In order to properly support clustered environments, such as d.o, we should introduce a 'host' field onto {versioncontrol_repositories} and corresponding objects. I don't think we need to go changing all the APIs around actually using alternative host data just yet, but I'd like to have the basic data there for when we do start in on needing it.

Note that while the role of this field is pretty clear for a DVCS, it's potentially ambiguous for a CVCS. So, to be clear - if we introduce support for remote repositories, this field should NOT be used for that purpose. Rather, it's used to record the cluster-accessible host on which the local version is being stored.

Comments

marvil07’s picture

marvil07 commented

It would be great if you can add an example. I do not really get the idea of cluster here, we currently have a path to a repository, that should be enough.

If by cluster you mean a group of different servers with data(i.e. git repositories in two servers), that would make some sense, but I would rather prefer to not add it to this api module. Instead, I would go for hiding that to the api using other tools(i.e. network mounts).

Is this still a release blocker?

sdboyer’s picture

sdboyer commented
Issue tags: -versioncontrol-6.x-2.0-release-blocker

no, it's not a release blocker, so removing that.

yes, i mean a group of different servers. whether that's git repositories split over multiple physical machines, or (as in the case of drupal.org) simply having webheads which do not have any direct access to the repositories, this is important.

marvil07’s picture

marvil07 commented
Issue tags: +vc-next

During triage