On Wed, Jul 24, 2013 at 2:18 PM, Ramon Ribó <ram...@compassis.com> wrote:
> As for the complexity, I do not understand why it would be so complex. > You can do it now manually by executing a collection of "update" and > "commit". It would be just to automate this. Do not think in terms of > "artifacts", think on terms of "changesets". > "Complex" in terms of philosophical problems - is it "correct" to re-build diffs between versions A and C if B is removed from between them, for example. What do we do with tags and such which reference now-gone artifacts? Remove them, orphan them, or flag them somehow has "stale"? What is "The Right Thing" in such a case, and is it really The Right Thing for every use case? Since syncing with existing copies would no longer be possible after this change, this would seem to cause more problems than it creates. Everyone would have to re-clone before continuing (which will frustrate people and break automated processes which do pull/update, e.g. for updating a web site's contents on a regular basis). The "bad"/old data is still "out there" somewhere in other clones, so the problem has not been solved. If you _really_ want to lose old history, simply create a new repo and import your current project state into it. But even that doesn't really "lose" it because some clone out there has it. AFAIK git offers a mechanism for changing history, but Fossil doesn't like for history to change. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
