Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

one-way-unsafe sync mode #150

Open
mentos1386 opened this issue Sep 20, 2019 · 4 comments
Open

one-way-unsafe sync mode #150

mentos1386 opened this issue Sep 20, 2019 · 4 comments

Comments

@mentos1386
Copy link

We have a use case, where we to use one way sync. Developers code to docker container. And we want changes from Alpha (the code on laptop) to override anything on Beta (docker container). For this we can use one-way-replica.

But, the issue comes with out build tool. It creates temporary files all over the code base, so we can't easily add them to ignore list. And using one-way-replica removes them, which means that build process fails.

Solution for this is to use one-way-safe. But then the problem is when we switch branches, bunch of conflicts, it get's messy fast.

Workaround for this is to use two-way-resolved, but we end up with bunch of build artifacts that we don't want on Alpha.

Could we get a one-way-unsafe where all changes on Alpha are forced on Beta. But beta can still create new files, if this aren't existing on Alpha?

I see that this feature was already existing before #42 (comment) with --conflict-resolution-mode=alpha-wins but was removed?

@xenoscopic
Copy link
Member

Ideally one-way-safe would be the best mode to use here, but maybe there are some additional heuristics or options (maybe something like #114) that would behave better in your use case.

Can you tell me a little bit about the types of conflicts that are coming up on branch switches? It would be a big help in understanding exactly what sort of behavior is required.

One case I've already experienced personally is a Python module directory with .pyc files in it that are ignored but which cause problems if the directory exists on one branch but not the other. With something like --unsafe-ignore=*.pyc, Mutagen could ignore these files but also feel safe to delete them when deleting a parent directory after a branch switch. I'd be curious to know if your case is something similar.

@mentos1386
Copy link
Author

Ideally one-way-safe would be the best mode to use here, but maybe there are some additional heuristics or options (maybe something like #114) that would behave better in your use case.

That would be kinda okay. But problem with that is that we have mono-repo development workflow with mono-image (for now). Which would result in a lot of --unsafe-ignore needed, for all the languages etc.

I would prefer something that wouldn't try resolve conflicts. As a developer, i want the source of truth to be the code i see in my editor.

I don't really care if i overwrite something in the container. But i also want to give container the freadom to create/edit/remove files as it wishes (but not the ones i have on my laptop). So it can do building and compiling.

Can you tell me a little bit about the types of conflicts that are coming up on branch switches? It would be a big help in understanding exactly what sort of behavior is required.

When you switch branch, you change your local code, but the code in the container(image) stays from the old one. This results in conflicts when container code has files/folders that aren't present in local code.

Example, when i switch to branch without services/sqs-metrics-exporter folder.
Screenshot-20190924085835-608x42

One case I've already experienced personally is a Python module directory with .pyc files in it that are ignored but which cause problems if the directory exists on one branch but not the other. With something like --unsafe-ignore=*.pyc, Mutagen could ignore these files but also feel safe to delete them when deleting a parent directory after a branch switch. I'd be curious to know if your case is something similar.

Exactly that. But we also have some other temporary files, from sbt. Same as first point, with multi language mono-repo, there would be alot of --unsage-ignore. It's not as straight forward as it could be.


One workaround that could work is to use one-way-replica and use --ignore the same way as you would --unsafe-ignore with one-way-safe. But then is the same issue, that we would need a lot of --ignore.

@gauthier
Copy link

Hi guys, I'm facing the same kind of dilemma when choosing the sync mode of my projects.

I'm evaluating Mutagen in the context of containerized php projects. At first, I was truly amazed by the performance of this solution. I was so happy that I immediately started migrating some projects.

After a while, I realized that I lost all the code I had on Alpha side :( I was unsure under what circumstances this loss appears, so I tried to switch from two-way-resolved to two-way-safe mode, worked again, but at one time, my code disappeared again on my laptop...

Long story short, this happens when I rebuild the sync'ed container without stopping the mutagen session before. I guess this not a bug, rather a side-effect, but this still is very dangerous...

And the one-way-* modes aren't applicable in my case since the project dependencies are installed depending on system configuration, so it's safer to install them from inside the container, but we also need to access the installed dependencies in the IDE side... I'm not sure I'm very clear :(

Anyway, I'd like a sync mode somewhere between the existing one and two-way modes : one-way would be much safer, but I'd need to tell mutagen that some specific paths should be back-sync'ed from Beta to Alpha.

Maybe is this already doable playing with params? Maybe not :)

Thanks for your help!

@d4rky-pl
Copy link

I found this ticket while looking if someone is running into similar problems that we do. This is definitely something we'd need to be able to use mutagen properly in our use case as well. Right now git rebase causes a mess in the host directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants