Of course, the new database would not be allowed to sync with the old one. For all effects, it is a different database.
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". RR 2013/7/24 Stephan Beal <sgb...@googlemail.com>: > On Wed, Jul 24, 2013 at 2:02 PM, Ramon Ribó <ram...@compassis.com> wrote: >> >> Would it be interesting for fossil to have an export command to a new >> fossil database, exporting only some changesets based on dates, >> branches, etc? > > > That would be an extraordinarily complex process, i think, if it's even > really possible (while maintaining data integrity). The majority of > artifacts inherit from some parent artifact. If you remove any of these > relationships you've just broken the chain. "Maybe" fossil could re-link the > neighbors on either side of such a construct and recalculate deltas for > them. That sounds reasonable, but then comes syncing... what happens to > everyone else's copy of the repo which has those artifacts? We cannot remove > those artifacts from their copies because that would open up the possibility > for one malicious user to delete all content (irrevocably) from all repos > which sync with his. As one of the Ghostbusters famously said: "That would > be bad." > > -- > ----- 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 > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
