mutagen-io / mutagen

Fast file synchronization and network forwarding for remote development
https://mutagen.io
Other
3.43k stars 152 forks source link

Mutagen syncs files from beta after git checkout #269

Open ashatrov opened 3 years ago

ashatrov commented 3 years ago

I configured mutagen to sync files of php project from host to docker container on osx. When I switch git branch some files sync back from beta (docker container) to the host. I need 2 ways synchronization because php modify some files (logs, vendors, uploads etc)

Example:

Current working branch feature_A has file feature_A_file.php.

I switch to git branch feature_B on Alpha (host) and immediately file feature_A_file.php will be synchronized from Beta (container) to Alpha (host).

Maybe there is synchronization option or any setting which can solve this issue?

Mutagen version: 0.11.8 Config:

sync:
  defaults:
    flushOnCreate: true
    symlink:
      mode: "posix-raw"
    ignore:
      vcs: true
  code:
    alpha: "."
    beta: "docker://$MUTAGEN_ALPHA_CONTAINER/var/www/"
    mode: "two-way-resolved"
    configurationBeta:
      permissions:
        defaultOwner: "id:1000"
        defaultGroup: "id:1000"
        defaultFileMode: 0666
        defaultDirectoryMode: 0777
    ignore:
      paths:
        - ".git"
        - ".idea"
        - "node_modules"
JackVertigo commented 2 years ago

I am still seeing this behaviour, also when using mutagen-compose.

xenoscopic commented 2 years ago

The crux of the issue here (and in most cases where files appear to mysteriously "sync back") is that the lifetime of the Mutagen synchronization session needs to match the "lifetime" of the locations that it's targeting for synchronization. This is because every sync session maintains an internal virtual "ancestor" representation of the agreed upon file contents that it uses to perform a three-way merge of the contents.

So, for example, if a session is targeting a container or a volume, and that container/volume is recreated (with empty contents), it looks to Mutagen like a deletion of all files on that side, which (absent some safety checks) it would propagate as complete deletion to the other side.

Likewise, if the Mutagen session is deleted/recreated/reset while the sync locations remain intact, then the ancestor is "reset", and both sides appear to have created content (of which Mutagen will propagate any non-conflicting elements). I suspect this is the case that most people are observing with issues like this one.

(Note that pausing or disconnecting a session shouldn't cause problems - the ancestor can be used to reconstruct what happened during that paused/disconnected time. The issue is just when the lifetime of the session/ancestor doesn't match the lifetime of one of the endpoints.)

The idea with Mutagen Compose was to couple the sync session lifetime to the targeted volume lifetime, though I do know of a few issues where the sync session will be recreated (and hence its history reset) independent of the volume lifetime. I'm hoping to fix those next week. For now, the workaround is to perform a full mutagen-compose down --volumes if the configuration of a synchronization session in the x-mutagen block changes.

At the moment, I'm also working on a Docker Desktop extension that can be used to synchronized create filesystem caches inside the Docker Desktop VM, which may make things easier for some people and serve as an alternative to Mutagen Compose that doesn't require the Compose wrapper. This is basically a replacement of the Mutagen functionality that was briefly shipped with Docker Desktop, but with significant performance improvements. The critical design aspect for this extension though is that the session lifetime is forcibly coupled to the lifetime of the caches. That should help avoid most of these issues.

I'll ping back on this issue once the relevant changes to Mutagen Compose are made and also once that extension is available.

BreiteSeite commented 1 year ago

The idea with Mutagen Compose was to couple the sync session lifetime to the targeted volume lifetime, though I do know of a few issues where the sync session will be recreated (and hence its history reset) independent of the volume lifetime.

Is this the reason why i get a lot of Forcing synchronization cycle for session [...] when doing mutagen-compose run/up commands? It seems random - sometimes mutagen doesn't force a synchronization cycle and sometimes it does. However, because of a lof of node_modules and vendor files it always takes 30-40 seconds which is very annoying - esp. when i setup the project and there are like 10 run commands executed.

Any update here? I saw the Docker Desktop extension is already released. I'm using mutagen-compose 0.16.5

Thanks for your help!

mvaljento commented 1 year ago

Still doing it.