On Mon, Feb 2, 2015 at 5:35 PM, Warren Young wrote:
> After sending that prior message, I did think of a way to allow retries
> without inconsistency, but it would surely slow Fossil down: there could be
> a mode that turns cloning into a replay of the master repo’s timeline.
>
> That is, every c
On Tue, Feb 03, 2015 at 01:48:52PM +0100, Jan Danielsson wrote:
>In terms of the type of data, our data and fossil's data is very
> different, but in terms of the time it takes to synchronize large data
> stores/repositories, we're in the exact same situation. We don't expect
> synchronization
On 02/02/15 23:23, Warren Young wrote:
>> The annoying thing is that when it fails, it wipes away whatever
>> progress it has made.
> Yes, well, that’s the nature of transactional DB updates: all or nothing.
Implied: There's only one way to use transactions when performing
initial synchroniza
Thus said Jan Danielsson on Sun, 01 Feb 2015 15:08:07 +0100:
> In that thread the commit
> http://www.fossil-scm.org/index.html/info/b4dffdac5e706980d911a0e672526ad461ec0640
> was brought up as a potential fix. I updated to get the fix and then
> tried running a clone, and I could indeed get the
On Mon, Feb 02, 2015 at 03:35:13PM -0700, Warren Young wrote:
> > On Feb 2, 2015, at 3:28 PM, Joerg Sonnenberger
> > wrote:
> >
> > On Mon, Feb 02, 2015 at 03:23:46PM -0700, Warren Young wrote:
> >>
> >> Are you seriously asking for Fossil to allow a local clone to be in an
> >> inconsistent s
> On Feb 2, 2015, at 3:28 PM, Joerg Sonnenberger
> wrote:
>
> On Mon, Feb 02, 2015 at 03:23:46PM -0700, Warren Young wrote:
>>
>> Are you seriously asking for Fossil to allow a local clone to be in an
>> inconsistent state after an error?
>
> Why does it have to be an inconsistent state? At t
On Mon, Feb 02, 2015 at 03:23:46PM -0700, Warren Young wrote:
> > On Feb 1, 2015, at 7:08 AM, Jan Danielsson
> > wrote:
> >
> > The annoying thing is that when it fails, it wipes away whatever
> > progress it has made.
>
> Yes, well, that’s the nature of transactional DB updates: all or noth
> On Feb 1, 2015, at 7:08 AM, Jan Danielsson wrote:
>
> The annoying thing is that when it fails, it wipes away whatever
> progress it has made.
Yes, well, that’s the nature of transactional DB updates: all or nothing.
> How difficult would it be to allow fossil to pick up where it left
> off
Hello,
I used to have major difficulties cloning huge repositories. (See
http://lists.fossil-scm.org:8080/pipermail/fossil-users/2014-May/016234.html).
In that thread the commit
http://www.fossil-scm.org/index.html/info/b4dffdac5e706980d911a0e672526ad461ec0640
was brought up as a potential
9 matches
Mail list logo
