Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-4847

Fork syncing, the remote edition?

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Answered
    • None
    • None
    • None
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Hi,

      We are in the process of acquiring a 50 user Stash license to run a couple of pilots in NA, however, we would be looking forward to have our Android development group (which partly resides in India and partly in NA, around 100 extra users) also be able to use it in about a year, and we also have some groups in Germany doing Linux Kernel development that need something to manage git.

      We want to keep application instances to a minimum (a single one, we've done it successfully with JIRA, Confluence and Fisheye+Crucible) to simplify IT ops, so I've been trying to think how can I setup Stash transparently to a globally distributed audience. We also currently use Perforce and they have the concept of replication proxies, although not completely transparent by itself, we have an internal script that lets us submit changes to different Perforce servers in a single operation.

      My best idea so far is to do a DNS-like replication mechanism through Git repository hooks, and setting some kind of actual DNS redirectioning; e.g. so that the guys from Germany actually push to repository mirror server in Germany, which would then replicate back to Stash. In other words, facilitate replication transparency outside the application itself taking advantage of the distributed traits of git, but this poses new challenges: e.g. should all the repositories be replicated everywhere?, if you take into account using SSD storage, that can become very expensive over time.

      I'm also working on rolling out a pilot for Bamboo, and it would be awesome if something like Remote Agents existed for Stash, meaning: setting up servers outside the Stash application to host the repositories, determine what servers host/mirror which repositories, and have the application itself deal with things transparently (propagating changes to all mirrors, even doing load balancing for cloning depending on server I/O & CPU load).

      So, it just struck my mind: could there be an easy way to extend the current Repository Fork Syncing feature in Stash to use remote repositories instead of local ones?, as this looks just like what we need, only having forks reside in another server. Perhaps through a network mount?, command wrapper?, remote hook configuration?, simple polling?, don't know.

      This is not just mirroring, as handling conflicts in the exact same way it is done for the Fork Syncing feature is required:

      https://confluence.atlassian.com/display/STASH/Keeping+forks+synchronized

      I think this would make Stash very powerful as an enterprise solution, as dealing with big concurrent geographically distributed teams is common for big engineering corporations.

      The proposal is to augment the current fork syncing feature to support remote repositories in heterogeneous systems, with the only difference that the syncing would be configured at the Stash repo (upstream may be a vendor, in which case the "original" Stash repo may be the fork; downstream may be a bare daemonized git repo in a server somewhere)

            Unassigned Unassigned
            1ae864c8726d David Vega
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: