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
Comments
Ideally 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 |
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 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.
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
Exactly that. But we also have some other temporary files, from One workaround that could work is to use |
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! |
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 |
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?The text was updated successfully, but these errors were encountered: