Skip to main content
Version: 0.1.130

Upstream sync

Upstream sync brings changes made outside the platform into the project. It exists because the modernized codebase is a real repository your developers also work in, and a platform that assumed otherwise would overwrite their work.

When you need it​

  • A developer committed directly to the modernized repository.
  • Another team merged something into the base branch.
  • A project combining several source repositories, where each moves on its own.

What it does​

Inbound sync builds the project's workspace from the source repositories as they now stand. For a combined project, commits are pulled from each source repository into the combined feature branch, and work done in the combined workspace is pushed back out to the repositories it belongs to.

That round trip is the point: developers keep working in the repositories they know, and the platform keeps a coherent view across them.

Reading a sync​

Each sync is recorded with what it brought in. Open one to see which repositories moved and what came across — worth doing when an implementation starts behaving differently for no reason you can see in the platform.

Feature branches and a base that has moved​

A base branch that moves after a feature branch was cut is normal, not an error. The base branch can be merged into a feature branch to bring it current, and a reused feature worktree is kept current with the base branch automatically.

In pull-request mode, a base branch that moves before the pull request is opened is handled rather than producing a stale request.

Updating every feature branch at once​

When the base branch changes something every branch needs — a compose file, a test runner, a toolchain pin — Update feature branches in Project Settings → Integrations brings that change into every open feature branch in one go. It sits beside Sync now in the Source repositories card for a combined workspace, and in the GitHub Integration or Git connection card otherwise.

Before you press it, the card lists which feature branches are behind the base and by how many commits, compared with the base as it was last synced or fetched. The button counts only those branches.

Pressing it and confirming:

  1. Brings the base current first: a combined workspace syncs its source repositories, a pull-request project fetches its base branch, and a direct-mode project uses its own integration branch.
  2. Merges the base into every open feature branch, one at a time. It merges and never rebases, so branches under review keep their history. A clean merge runs no tests. A conflict is handed to the conflict-resolution agent, which must get the test suite passing before its resolution is kept.
  3. Pushes what the mode needs: a combined workspace pushes each published feature's combined branch (client pull requests are not changed); a pull-request project pushes the branch of every feature with an open pull request, which updates that pull request without re-running Repave's tests; a direct-mode project pushes only branches that were already on the repository.

Each branch then reads Updated, Already up to date, Skipped with the reason (no worktree, a job or a UAT session running on it, uncommitted changes), or Conflict: needs attention. A conflict the agent could not resolve leaves that branch exactly as it was; resolve it in Repave IDE from the link on the row or on the feature's page, then commit.

A dev stack or test database already running in a Repave IDE session keeps its old configuration until it is restarted, so restart them after an update that changed one.

In a combined workspace, a feature that changes only files outside every source repository — such as docker-compose.bdd.yml at the workspace root — opens no client pull request. It is verified and published straight to the combined workspace instead, which is how a change like that reaches the base in the first place.

Conflicts​

A conflicted merge into the integration branch leaves the checkout clean. You do not end up with a half-applied merge in the workspace that somebody has to unpick — the merge fails as a unit, and a failed merge job does not mark the feature itself as failed.

Resolve the conflict the way you normally would, in Repave IDE or locally, and merge again.

Where a project is linked to GitHub, the link maintains itself: it pushes on creation, syncs both ways, and pushes again at merge time. You should not need to move branches by hand to keep the two in step.