It would be nice to attribute the patch to a particular author. Other than that, sounds reasonable.
On Tue, Feb 8, 2011 at 4:51 PM, Richard Hipp <d...@sqlite.org> wrote: > On Tue, Feb 8, 2011 at 4:26 PM, Nolan Darilek <no...@thewordnerd.info>wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Actually, this sounds a bit like what I mentioned several months back >> regarding bundles. >> > > Yes. > > After thinking things over, I'm inclined to say just use plan old > diff-patches. > > So if somebody wants to propose a change, they clone the repository and > start > making changes. Then submit them by doing: > > fossil diff --from VERSION-WHERE-STARTED --to current >patch.txt > > And then append the patch.txt to the ticket. > > Meanwhile, the integrator can use the patch command to add the patch to a > checkout, see if it makes sense, test it, and commit it or not, onto a > branch or into the trunk, as she sees fit. > > That approach drops the "history" of the patch - the sequence of individual > checkins that the contributor used in developing the patch - and makes the > patch a single big change. I'm not sure that is such a bad thing, though. > > > >> >> 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 >> > > > > -- > 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 > > -- Justin Mazzi
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
