On Wed, Feb 9, 2011 at 12:07 AM, Nolan Darilek <no...@thewordnerd.info>wrote:
> Also, how does Fossil handle the case where your change might exactly > implement the patch I submitted? Is it intelligent enough to note that > the changes a remote update would apply coincide exactly with how things > stand now, or would it throw up a bunch of conflicts? > Very true. The "pure /usr/bin/patch" approach would almost certainly cause conflicts where there are really none. The interface i envision would be basically what Richard and Jeff suggested: fossil patch create --from version --to version [-f filename, default=stdout] (or similar) which would generate either unified diff format (if we forego, or can otherwise overcome, the (theoretical) "phantom conflict" problem), or a fossil-specific bundle, as Nolan recommends (which overcomes that problem but may have portability problems, e.g. when creating patches which will end up in another SCM). i expect that the bundle approach has more long-term advantages, e.g. could be extended later on to include metadata like contributor info, an embedded license release form, a digital signature, or whatever. To apply them, as Jeff suggested: fossil patch apply [-f filename, default=stdin] possibly with a [--to version] option to apply it to a specific version (but i don't feel that that's required - it's easy enough to check out that version/branch manually first). :-? Maybe... i don't know if this would work, but we might have all the features we need already: what if the patch bundle is itself a fossil repo? Could we then import those changes back into another repository, or does ancestor tracking not work across unrelated repos, e.g. via a hypothetical extension to 'merge' fossil merge -p patches.fossil artifact_id :-? -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
