The use case is obvious: inform the user about the state of the SVC. Once the user is aknowledged that there are changes to update/merge he can:
1- Merge them automatically 2- Check file by file manually to review the differences 3- Start a branch with own changes 4- Do not update and wait for something to change 5- Go to the other user desk and discuss about the changes 6- Etc. About Richard question, for me it sound ok that "fossil update -n" should perform a previous "sync" if auto-commit is active. RR 2011/8/30 Konstantin Khomoutov <[email protected]>: > Also how about the fact there's an inherent race condition between > adjacent calls to any fossil command which interacts with a remote > repo: you can run `fossil whatever --dry-run` and see everything's OK > and then the next call to it will hit a modified state of that same > repo because some other developer happened to update it in the meantime _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
