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
