On Tue, Feb 8, 2011 at 1:10 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> Hi, all! > > This is mainly aimed at Richard, but i would also like to hear input from > those currently committing to the main repo... > > Woul it be less administrative hassle, and help reduce "pollution" of the > main repo (in the form of 26 branches - that's the current count) if, > instead of granting commit access to the main repo (except for the core > developers, who obviously need it), we instead did all "feature > experimentation" in local clones of the main repo, and send "pull requests" > to the dev team when appropriate (perhaps in the form of tickets, or a new > artifact type called "pull request")? Or would that just complicate matters? > Isn't fossil designed to allow that type of collaboration, or am i thinking > in "git mode"? > > (Personally, i don't like the idea of my "intermediary crud" adding to the > clone size of the main repo.) > That's how Git and Hg work. I deliberately tried to make Fossil different. I wanted all the code in one place. The Fossil approach works better with a close-knit integrated team where everybody is working on the code full-time (or most-time) and are all working closely together. (Ex: SQLite) The Git/Hg model works better for the open-source, come-one-come-all, contribute-to-the-pile-of-patches model. (Ex: Linux kernel) As a compromise, I would support the ability for people to experiment in their own private clones, then "export" some sub-sequence of changes into a patch-set object of some kind, which could then be imported into the official repository as a branch. Can I encourage you to work on such a feature? (In a private clone of the repository ;-)) Perhaps use the "import" and "export" commands as a baseline. Maybe an option to the "export" command that only exports a particular range of check-ins or a particular branch, and options to "import" the force all imported content to be in a particular branch, or that make all the changes imported private (none-syncing) until audited and approved in some way. > > :-? > > -- > ----- 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 > > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users