On Jul 6, 2017, at 1:30 PM, Natacha Porté <nata...@instinctive.eu> wrote: > > on Thursday 06 July 2017 at 14:01, Richard Hipp wrote: >> >> (1) Make edits on Linux but do not commit. >> (2) Copy the files to Windows and verify that they work there too. >> (3) Run "fossil commit" on Linux. >> ... >> Is that similar to what you are trying to do? > > Yes, this is very similar to what I usually do... > > Now imagine you leave things as they are after (3) to do some non-dev > stuff (or some dev on other repositories), and you receive a serious > windows-specific bug report. You drop everything to work on it, > forgetting the "fossil up". You eventually make a fix in some code path > that is never reached on Linux, or for another reason you decide to > commit straight away.
Unless your emergency Windows version fixes overlap the changes made on that branch since the last “fossil up”, I think “fossil up” shouldn’t cause a merge conflict even if you delay it until just before you’re ready to check your changes in. (You must do a “fossil update” here before Fossil will let you check in, unless you add --branch.) At this point, I want a working test case showing the problem. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
