-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually, this sounds a bit like what I mentioned several months back regarding bundles.
Fossil's model works well in lots of cases, but I too worry about my own and everyone else's experimentation cluttering the main repository in many instances. Furthermore, while it's easy for many of us to throw up a server somewhere, many others don't have it quite as easy. I wouldn't mind hosting a "lab" version of my various projects wherein I more freely grant commit access for anyone wanting to experiment without setting up a server, but in these instances it'd be great to selectively pull certain changesets into the main repository without performing a full sync. As I may have said back then, might it be possible to serialize the exports in such a way that they could be attached to tickets? Then, Fossil could detect that the attachment contains such a serialized format and allow it to be automatically merged in? The contributor workflow could then be: 1. Contributor makes a change, exporting them via "fossil bundle" or whatever the command is called (I have no personal interest in bikeshedding that, just throwing it out.) 2. The bundle is attached to a ticket containing a description. 3. The repository owner then looks over the changes and can then directly merge them in. Perhaps the "bundle" command can list contained bundles in a repository and allow them to be merged from the command line. I'm not sure how the rejection workflow might work. Maybe a shun of the bundle ID to keep the repository slim, or maybe new revisions of old bundles can just concat modifications onto the end as to track the change's full evolution. Maybe that's a bit beyond what is being considered here, and I don't intend to press the issue, but since we're now considering adding in this functionality that's similar to some of my own past thoughts, I thought I'd mention some of those again. On 02/08/2011 12:24 PM, Richard Hipp wrote: > 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 >> >> > > > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1RtSEACgkQIaMjFWMehWIqXQCfV+5Kxu75rol/N17tfqLFeDYt 29oAniu3n+L7KnmkbebBkfc/Wb/BwUCS =MpeT -----END PGP SIGNATURE----- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
