On Tue, Nov 3, 2015 at 10:40 AM, Eric Rubin-Smith wrote:
> My biggest complaint about this discussion is that some folks seem to be
> coming at it like fossil is the first tool to confront this issue.
I interpret the discussion as a more philosophical one. Should
symlinks be part of a project's c
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 would agree with
>> that?
>
> i can't speak for
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
--revision option
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 cherr
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 details. Please do feel free to enhance it.
Can
On Fri, Mar 20, 2015 at 7:26 PM, Andy Bradford
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 gdiff-command idiff
>
On Wed, Feb 11, 2015 at 9:21 AM, Richard Hipp 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 nice!
On Thu, Jan 15, 2015 at 3:56 PM, Ron W wrote:
> On Thu, Jan 15, 2015 at 4:14 PM, Rich Neswold
> wrote:
>
>> Maybe the fossil schema can be enhanced by adding triggers that prevent
>> UPDATEs from occurring on critical columns.
>>
>
> Not sure how much value that
On Mon, Jan 12, 2015 at 7:40 PM, Kelly Dean 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 cannot c
On Mon, Jan 12, 2015 at 8:06 PM, Stephan Beal wrote:
> On Tue, Jan 13, 2015 at 3:01 AM, Stephan Beal
> wrote:
>
>> On Tue, Jan 13, 2015 at 2:40 AM, Kelly Dean wrote:
>>
>>> The NetBSD people would probably be happy to spend a few GB of disk
>>> space on that cache in exchange for Fossil being f
On Thu, May 8, 2014 at 10:08 PM, Andy Bradford 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:
>
> https://www.sqlite.org/lang_transaction.html
On Wed, May 7, 2014 at 12:59 AM, Andy Bradford
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, if there'
On Fri, May 2, 2014 at 10:10 AM, Rich Neswold 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'
On Thu, Apr 17, 2014 at 10:12 AM, Rich Neswold wrote:
> On Wed, Apr 16, 2014 at 3:40 PM, Rich Neswold 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 t
On Thu, Apr 17, 2014 at 2:10 PM, Richard Hipp 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 setting a
On Thu, Apr 17, 2014 at 1:46 PM, Joerg Sonnenberger
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 mine? A fossil
repos
On Wed, Apr 16, 2014 at 3:40 PM, Rich Neswold 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 fa
On Wed, Apr 16, 2014 at 11:35 AM, Joerg Sonnenberger
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 pull not being read-o
On Wed, Mar 19, 2014 at 11:59 AM, Stephan Beal 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?" It simply ne
On Fri, Feb 7, 2014 at 10:17 AM, Stephan Beal 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 repo:
I have anot
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 effor
21 matches
Mail list logo
