Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Feb 10, 2011, at 18:02 , Ramon Ribó wrote: >> And this is what private commits are for. Work pretty well if you >> have something, that you don't want to show. It's only a shame >> they're not emphasized well in the docs (or at least were not the >> last time I checked). > > Private commits a

Re: [fossil-users] re-thinking commit access to the main fossil repo...

> And this is what private commits are for. Work pretty well if you > have something, that you don't want to show. It's only a shame > they're not emphasized well in the docs (or at least were not the > last time I checked). Private commits are useless if you work in more than one computer and nee

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Feb 8, 2011, at 19:10 , Stephan Beal wrote: > 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) 26 *open* branches you meant? At least this is what the number suggests... Well, I think I have a soluti

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Feb 8, 2011, at 23:53 , Stephan Beal wrote: >> And then append the patch.txt to the ticket. >> > > i like that. And we're not tied to the ticket system - the patches could > come from email or whatever. Oh great, getting back to the nineties! ;) Kind regards, Remigiusz Modrzejewski __

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Wed, Feb 9, 2011 at 2:41 PM, Laurens Van Houtven wrote: > How difficult would it be to implement something like Launchpad's > merge proposals or Github's pull requests? We're currently using > Fossil the way drh described SQLite-like development processes and it > does indeed work very well, bu

Re: [fossil-users] re-thinking commit access to the main fossil repo...

How difficult would it be to implement something like Launchpad's merge proposals or Github's pull requests? We're currently using Fossil the way drh described SQLite-like development processes and it does indeed work very well, but it would be nice if there was a good contributor story for the pro

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Wed, Feb 9, 2011 at 12:32 AM, Andreas Kupries wrote: > So, such a bundle really is in essence a .zip with a bit of additional > information. > Thanks for that clarification. Another idea came to mind after i signed off last night... creating the bundle as a second sqlite db (not a fossil db),

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On 2/8/2011 3:26 PM, Stephan Beal wrote: > On Wed, Feb 9, 2011 at 12:25 AM, Stephan Beal > wrote: > > Maybe... i don't know if this would work, but we might have all the > features we need already: what if the patch bundle is itself a fossil > repo? > > > Cla

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Wed, Feb 9, 2011 at 12:25 AM, Stephan Beal wrote: > Maybe... i don't know if this would work, but we might have all the > features we need already: what if the patch bundle is itself a fossil repo? > Clarification: a standalone repo containing only the patch-related artifacts. (Is that possib

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Wed, Feb 9, 2011 at 12:07 AM, Nolan Darilek wrote: > Also, how does Fossil handle the case where your change might exactly > implement the patch I submitted? Is it intelligent enough to note that > the changes a remote update would apply coincide exactly with how things > stand now, or would it

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Tue, Feb 8, 2011 at 5:53 PM, Stephan Beal wrote: > > Regarding Justin's comment about patch attribution: in the larger scheme of > applying patches, regardless of the underlying SCM, credits to the > contributor are normally relegated to the commit message or changelog or > similar places. i d

Re: [fossil-users] re-thinking commit access to the main fossil repo...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fair enough. Just one request then: Is there already or might there be added a symbolic name for the most recent remote revision on a given branch? So, for instance, if I develop on trunk and I want to submit a patch, I could do: fossil diff --from r

Re: [fossil-users] re-thinking commit access to the main fossil repo...

Stephan Beal wrote: > On Tue, Feb 8, 2011 at 10:51 PM, Richard Hipp > wrote: > > fossil diff --from VERSION-WHERE-STARTED --to current >patch.txt > > > Can fossil-generated diffs be used as input to standard patch programs? Is there a standard patch program on win

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Tue, Feb 8, 2011 at 10:51 PM, Richard Hipp wrote: > fossil diff --from VERSION-WHERE-STARTED --to current >patch.txt > Can fossil-generated diffs be used as input to standard patch programs? -- - stephan beal http://wanderinghorse.net/home/stephan/ __

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Tue, Feb 8, 2011 at 10:51 PM, Richard Hipp wrote: > On Tue, Feb 8, 2011 at 4:26 PM, Nolan Darilek 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

Re: [fossil-users] re-thinking commit access to the main fossil repo...

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 wrote: > On Tue, Feb 8, 2011 at 4:26 PM, Nolan Darilek wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Actually, this sounds a bit l

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Tue, Feb 8, 2011 at 4:26 PM, Nolan Darilek 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 some

Re: [fossil-users] re-thinking commit access to the main fossil repo...

-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. Fur

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Tue, Feb 8, 2011 at 7:24 PM, Richard Hipp wrote: > 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

Re: [fossil-users] re-thinking commit access to the main fossil repo...

> 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

Re: [fossil-users] re-thinking commit access to the main fossil repo...

On Tue, Feb 8, 2011 at 1:10 PM, Stephan Beal 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 2

[fossil-users] re-thinking commit access to the main fossil repo...

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 com