On Tue, Sep 2, 2014 at 11:26 PM, wrote:
>
> (2) Fossil's purpose is to be able to recreate historical versions of the
> project - exactly. It cannot do that if historical images have been
> deleted.
> I understand the purity intended, but continue to be frustrated by it. :)
> I merely seek an
(2) Fossil's purpose is to be able to recreate historical versions of the
project - exactly. It cannot do that if historical images have been
deleted.
I understand the purity intended, but continue to be frustrated by it. :) I
merely seek an automated way within Fossil to manage garbage. Re-repo
On 9/2/2014 15:11, Richard Hipp wrote:
(1) Fossil *does* store binary files as diffs from their predecessor, if
they are sufficiently similar (that is, if the diff is smaller than the
file itself). the problem is that with compressed images, changing a
single pixel can potentially change most b
On 9/2/2014 15:07, sky5w...@gmail.com wrote:
If you could flag a file as "Keep latest only", that would be less
painless.
That wouldn't work for me. I want the past versions of the image. [*]
The branch I made of the web app three years ago won't run right with
the current bitmaps. The new
On Tue, Sep 2, 2014 at 5:07 PM, wrote:
> While disabling checksums helps with speed
> http://www.fossil-scm.org/index.html/help?cmd=settings
> It does not help with redundant binary images in the repo.
> For that, you have to shun and rebuild.
> If you could flag a file as "Keep latest only", tha
On Tue, Sep 2, 2014 at 5:04 PM, Warren Young wrote:
> On 9/2/2014 14:47, Joerg Sonnenberger wrote:
>
>> On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote:
>>
>>> Fossil currently wants to do a cryptographically strong checksum on
>>> every version of every graphic file I've ever create
While disabling checksums helps with speed
http://www.fossil-scm.org/index.html/help?cmd=settings
It does not help with redundant binary images in the repo.
For that, you have to shun and rebuild.
If you could flag a file as "Keep latest only", that would be less
painless. I don't mind the artifact
On 9/2/2014 14:47, Joerg Sonnenberger wrote:
On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote:
Fossil currently wants to do a cryptographically strong checksum on
every version of every graphic file I've ever created on every
checkin. Consequently, a checkin takes several seconds he
On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote:
> Fossil currently wants to do a cryptographically strong checksum on
> every version of every graphic file I've ever created on every
> checkin. Consequently, a checkin takes several seconds here.
>
> There was a recent proposal that
On 9/2/2014 08:27, Stephan Beal wrote:
On Tue, Sep 2, 2014 at 4:18 PM, mailto:sky5w...@gmail.com>> wrote:
Will Fossil ever seek to address very large source control?
Fossil's main target is sqlite (it's a cyclic relationship), and in my
humble (but quite fallible) opinion that project won'
On Tue, Sep 2, 2014 at 10:27 AM, Stephan Beal wrote:
> but by "very large source control" i envision something akin to git's
> octopus model, reaching fractally out into the universe
>
Fossil uses the "octopus model" as well. I just don't know of any projects
using Fossil that have more than 2 "
On Tue, Sep 2, 2014 at 4:18 PM, wrote:
> My reservation being scalability of large repo support. While I am
> unaffected, those professionals charged with release and maintenance of
> large code bases look past Fossil and its SQLite core.
> Questions:
> Will Fossil ever seek to address very large
12 matches
Mail list logo
