On Sat, February 25, 2012 5:44 pm, Leo Razoumov wrote: > On Sat, Feb 25, 2012 at 09:17, Richard Hipp <d...@sqlite.org> wrote: >> >> A key philosophical design principle of Fossil is "no erasures". This >> is >> how business financial accounting is (or used to be) done. You write in >> ink. > > I am fine with this philosophy of "no-rewriting" of published history. > And I am *not* asking for a "git rebase" equivalent. > > But I have to follow a work-flow that consists of a cascade of > repositories.
"have to"? Why? Is this a case of having to step back and look at the aim of the workflow rather than assuming that it is set in stone? > (1) PRV.fossil -- is my private repo where all my dirty laundry is stored Do you need a repository for this? A repository is not a backup tool. > (2) TEAM.fossil -- this is a place shared by the development team. > Mistakes can be annotated as "mistake" and backed out as you said. > (3) PUBLIC.fossil -- is a clean and shiny final result that must be > devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos. Why do you need (3)? Who are you hiding stuff from? I think a clean branch is all you need. Actually I think most of your issues can be dealt with by suitable use of branches. To go back to your earlier example, if P2 has nothing to do with P1 it should probably have been in a branch of its own. Which reminds me that I was going to say earlier that I don't understand the emphasis on patches. A patch is just a way of transforming one version of a file into another version, and is not a necessary component of an SCM system. Eric -- ms fnd in a lbry _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
