On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland <estifo...@gmail.com> wrote: > foo.txt has changes A, B, C and D. > > After each change the developer had the foresight to do a "fossil stash > snapshot". Now the developer decides to put changes B and D into branch b-d > and keep changes A and C on the trunk:
Ah, foresight. I should be blessed, but I am not, for that that's not how I work. Sometimes I don't realize that A is really two separable changes worth separating. Or maybe I don't think they are worth separating but my upstream does. Or maybe I'm the upstream and it's a contributor that I am asking to split up A. Counting on foresight is not a good plan :) The main reasons I can think of to not have an index are that one either really is so careful that they have such foresight, and/or one does not [have to] care to disentangle changes. Fossil and SQLite3 seem to only move forwards: there are no maintenance release branches, because there are no maintenance releases. Need a bug fixed? Get on the bleeding edge. That works fine for some projects, in which case Fossil will do. Otherwise one must very manually disentangle changes or not use Fossil. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
