On Mon, Mar 2, 2015 at 3:14 PM, Matt Welland <[email protected]> wrote:
> For example, if I clean up and move things around in a Fossil repo and by > force of habit do an update before a commit I *lose* some of my clean up > effort when Fossil (illogically IMHO) brings back the removed files. > Where I work, this issue is avoided by the use of "feature" (or issue) branches - that is, when one of us implements a new feature or fixes an issue, the work is done is a suitably named branch. Then the new/changed code is reviewed before merging into trunk. If another change is made to the same file(s), then which ever is reviewed/approved first will be merged first, then that will be merged in to the feature/issue branch. Then the second can be (re-)reviewed, then merged upon approval. However, I agree that "update" should not revert any pending changes, but, rather, cause warnings about potential conflicts.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
