Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 12:33 AM, Stephan Beal wrote: > On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith wrote: >> A user who only ever uses fossil on unix should get unix symlink semantics >> on unix, without quirks or surprises. Surely you and DRH

Re: [fossil-users] Cancelling a cherry-pick/backout

On Mon, Oct 19, 2015 at 11:53 AM, Richard Hipp wrote: > I tried this and the "fossil revert" worked for me - it cleared out > all of the cherrypicks. Looking through my command history I see, whenever I tried 'fossil revert', I also specified a version tag which displayed "the

[fossil-users] Cancelling a cherry-pick/backout

Hello, I used 'fossil merge --cherry-pick' to grab individual patches from a different branch in my repo. After some thought, I decided I don't want those changes. They weren't committed to my branch so I'm trying to revert to the leaf. I can't seem to find the command to completely undo the

Re: [fossil-users] Web interface timeline rail colors

On Mon, Sep 7, 2015 at 6:00 AM, Richard Hipp wrote: >> On Sat, Sep 5, 2015 at 2:49 PM, Florian Balmer >> wrote: >>> I'd be happy if these small adaptations could be made. > See https://www.fossil-scm.org/fossil/artifact/005c758d3?ln=596-625 > for

Re: [fossil-users] Select specific changes within files

On Fri, Mar 20, 2015 at 7:26 PM, Andy Bradford amb-fos...@bradfords.org wrote: Or the opposite. Stash and partial pop, which apparently Fossil can already handle simply by using the ``right'' diff tool. For example, I configured Fossil to use idiff as my gdiff command $ fossil set

Re: [fossil-users] Alternative skin for the main Fossil website

On Wed, Feb 11, 2015 at 9:21 AM, Richard Hipp d...@sqlite.org wrote: You can now access the Fossil self-hosting repository using the San Francisco Modern skin at: https://www.fossil-scm.org/skin2 Please let me know if you see any problems with the look of this alternative skin. Looks

Re: [fossil-users] Some peanut gallerizing

On Mon, Jan 12, 2015 at 8:06 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jan 13, 2015 at 3:01 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jan 13, 2015 at 2:40 AM, Kelly Dean ke...@prtime.org wrote: The NetBSD people would probably be happy to spend a few GB of disk

Re: [fossil-users] Some peanut gallerizing

On Mon, Jan 12, 2015 at 7:40 PM, Kelly Dean ke...@prtime.org wrote: Stephan Beal wrote: You _cannot_ change it, so i'm not sure what your point is there. All fossil data is immutable. You _can_ change it, but if you do so, then you break things, which of course is what you mean by ‟you

Re: [fossil-users] Some peanut gallerizing

On Thu, Jan 15, 2015 at 3:56 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Jan 15, 2015 at 4:14 PM, Rich Neswold rich.nesw...@gmail.com wrote: Maybe the fossil schema can be enhanced by adding triggers that prevent UPDATEs from occurring on critical columns. Not sure how much value

Re: [fossil-users] can fossil try harder on sync failure?

On Wed, May 7, 2014 at 12:59 AM, Andy Bradford amb-sendok-1402034378.gfecjnjggaibliman...@bradfords.org wrote: Thus said Rich Neswold on Wed, 16 Apr 2014 15:40:23 -0500: It would be nice if fossil would break the pull into smaller transactions which contain valid timeline commits so

Re: [fossil-users] can fossil try harder on sync failure?

On Thu, May 8, 2014 at 10:08 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Doug Franklin on Thu, 08 May 2014 23:00:03 -0400: Does SQLite support nested transactions? If so, that would seem to be worth considering. It does appear to support them:

Re: [fossil-users] can fossil try harder on sync failure?

On Thu, Apr 17, 2014 at 10:12 AM, Rich Neswold rich.nesw...@gmail.com wrote: On Wed, Apr 16, 2014 at 3:40 PM, Rich Neswold rich.nesw...@gmail.com wrote: It would be nice if fossil would break the pull into smaller transactions which contain valid timeline commits so, if there's a database

Re: [fossil-users] can fossil try harder on sync failure?

On Fri, May 2, 2014 at 10:10 AM, Rich Neswold rich.nesw...@gmail.com wrote: That's right, my write-ahead file is 177 GB (16x the expected size of the final repository!) I'm doing a fossil sqlite and it's slowly trying to apply the transaction, but I really don't have any hope it will succeed

Re: [fossil-users] can fossil try harder on sync failure?

On Wed, Apr 16, 2014 at 3:40 PM, Rich Neswold rich.nesw...@gmail.com wrote: It would be even nicer if it didn't throw away partial pull data on a DB timeout: I'm trying to pull the latest NetBSD changes (to pull in the Heartbleed fixes) and my session keeps failing with the fudge time error

Re: [fossil-users] can fossil try harder on sync failure?

On Thu, Apr 17, 2014 at 1:46 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: Please note that while moving to a newer, faster server I also moved to source to /cvsroot to match real CVS. That was responsible for quite a few changes. So I'm sync'ing a completely new repository on top of

Re: [fossil-users] can fossil try harder on sync failure?

On Thu, Apr 17, 2014 at 2:10 PM, Richard Hipp d...@sqlite.org wrote: Every project as a project-id, which is supposed to be unique. Fossil recognizes when the project-ids do not match and refuses to sync. That said, there is nothing to prevent a clever individual, like Joerg, from manually

Re: [fossil-users] can fossil try harder on sync failure?

On Wed, Apr 16, 2014 at 11:35 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: It would also be nice if clone didn't abort with removal of the repository on such errors. pull/push should return an error etc. There are a bunch of basic usability issues in this area. This is made worse by

Re: [fossil-users] G+ Fossil page?

On Wed, Mar 19, 2014 at 11:59 AM, Stephan Beal sgb...@googlemail.com wrote: i just came across this G+ post: https://plus.google.com/100252397521353238214/posts/hW7ErV11uNB (For non-googlers; it's a release announcement for Fossil 1.28) and thought, why haven't we been doing that all along?

[fossil-users] Scalability limits

Hello, I first want to say what a terrific version control manager Fossil is! I took my first serious look at Fossil last week and have already converted a few of my personal projects away from 'git'. The built-in bug tracker and wiki are genius touches! Thank you, Fossil community, for your

Re: [fossil-users] Scalability limits

On Fri, Feb 7, 2014 at 10:17 AM, Stephan Beal sgb...@googlemail.com wrote: i'd be interested in seeing the output of 'dbstat' on your repo, except that it could take some time for it to finish generating its output (so don't feel obligated to try it). Here's the info for the current fossil core