On Fri, Jul 20, 2012 at 6:12 PM, Andy Gibbs <andyg1...@hotmail.co.uk> wrote:
> (1) A user wishes to split a large source file into two, uses copy to > link the second file to the common ancestor and makes the various > modifications to both files to remove from each the duplicate > code where required, and commits. The commit history for the > files can then show how the file forked. > i can't say whether or not fossil could do that. Richard will have to answer that one. > (2) During development, a file is discarded as redundant but later > found to be useful; it can then be restored from its earlier > version, complete with revision history. > If i'm not mistaken, "fossil rm" then "fossil add" will allow resurrecting a file? (i might be wrong - i can't say i've tried it.) My question, sorry it has taken so long to get to it, is, is my > simulation in the first example a valid approach, and for the > second example, would it not be necessary to augment the F-card > to include the uuid of the check-in from which the copy has been > made so that it can be found by the timeline functions? And > would such a change to the manifest file structure be acceptable? > That was quick progress. i'm not familiar enough with the manifest format to know whether that is kosher long-term or if the above could be somehow fatal. Again, we'll have to wait on someone who knows those bits better. > Thanks for your time in guiding me! > Glad to help. -- ----- 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
