On Wed, Jul 16, 2014 at 2:03 AM, Gour <g...@atmarama.net> wrote: > Ron W <ronw.m...@gmail.com> writes: > > > As best I can determine from a description of "hg bundle", a patch file > > provides similar functionality. > > I believe it's more...darcs has it, same with bzr & hg...it is the > ability to create 'bundle' which contains appropriate context of the > patch so that it's easy to send it e.g. vie email and apply without > creating conflicts. >
Reading more about bundles, they appear, in Fossil terms, to be what would be sent out by a push, or similar to an incremental export (yes, Fossil supports incremental exports). I think your definition of "creating conflicts" is too narrow. If the both the sending and receiving repos contain a commit to the same parent, there will be a fork. Merging the fork could require resolving conflicts, no different from resolving conflicts from applying a patch. Having just plain patch is, Imho, not enough, since often it can take > time since the patch creation, review etc. and the time it should be > applied on the trunk. > While applying a bundle seems to be a little easier than applying a patch, bundles still need to be created, applied and reviewed. > > To be honest, for accepting contributions from outside the core team, I > > would clone my repository, then pull the contribution into the clone. > That > > way, any side effects of the pull would be easier to contain. > > > But, I have never had contributions from outside the core team of any of > > the projects I've worked on, so I can't yet say what would work best for > me. > > I would not try to re-invent the wheel and simply take a look at > darcs/bzr/hg/git (not sure about mtn) which have ability to prepare > 'patch' with appropriate context to be sent via email and applied > cleanly. > I think you and I are using different definitions of "apply cleanly". I am not talking about the process of applying a bundle or patch, but rather the changes contained in the bundle or patch. If I apply a bundle or pull directly from a contributor's repo, I have very little control over the artifacts introduced into my repo. So, if I were to receive a bundle from a non-core contributor, I would treat it the same as pulling it directly from her/his repo: Clone my repo, apply the bundle to the clone, then review and "import" changes by diffing between the clone's workspace and my main repo's workspace. Maybe hg/git/bzr/other have mechanisms to automate what I just described. I have not had a need to use such mechanisms so have not researched them.* I am expressing a high level strategy for how I would approach the problem. * While I have made "outsider" contributions to projects, of the projects I am (or have been) a core developer, none of those accept contributions from outside the core team.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
