When real time sync is not the best choice
Live sync plays a crucial role for team work allowing all team members to bring their work in one place and see what is being done by the others at the same moment in time. While it is very useful for people who do not edit the same exact thing, it can be less reliable and even dangerous for those who make changes for their own use.
What can go wrong with live sync
When managing localisation for a mobile app in the past, live sync with Google Docs was a very important part of my life. Each member of our international team could translate the same segment of text in their own dedicated column and I could see which languages were already done and which were still being edited. Great for knowing when an urgent task is going to be completed and how long is left to wait.
But if while working on one document two members of the team make a change to the same segment at the same time, only the one will be kept. So the slower person will loose their changes. Not such a disaster if it is just one line of text. For big changes it can however be more annoying.
So, it would be great if the users had a choice to either revoke their own changes or override the changes made by their colleagues or even keep them all. Though, this would result in a constant distraction as the users will have to make this choice every time there is a conflict not being able to concentrate on their work any more.
What we did in Paw
As I changed my professional field and started to integrate into the developers world more and more I realised that real time sync couldn’t be the best choice for team collaboration. Concentrating on my own part of the project then syncing with the others when ready and making a clear choice of what should be kept in case of a conflict was a better flow.
That is why we’ve put so much work into the team sync feature here in Paw. Using gitlike system on our backend we have also created much more custom merge code so that we can do additional checks during merge. The uncommitted changes are still tracked in the Cloud giving users the ability to peek into others working state without them explicitly committing their changes to a branch.
In the team projects in Paw each team member can start working from any point in the history of the project. All changes are autosaved to their working state in the Cloud. They can create named snapshots which will be always accessible and push their changes to a branch when they are ready to share them with the rest of the team. If there is a merge conflict Paw gives the merge options and visualises the result, the user explicitly confirms every merge. We believe that it is very important for users to see what exactly is going to happen before they confirm the merge. This way we can prevent unexpected results and loss of important parts of their work. In our case users could loose their requests or even groups of requests if they were not asked to confirm the merge every time.
In the case of an HTTP client such as Paw, we couldn’t have chosen the more simple route of live sync, because of the specificity of developer work. We decided to choose this more sophisticated way so that our users can sync their work safely. In general, while being useful for working on projects when editing needs to be done simultaneously, real time sync might not be the best option for teams when everyone is making edits for their own use and when loosing a change if there is a conflict can result in losing hours of work.