Thus said Zolt?n K?csi on Wed, 07 Nov 2018 20:48:11 +1100:
> 'fossil update' (autosync/push/pull enabled) updates the local tree
> but not to the latest version.
This sounds like a cluster synchronization bug that was squashed after
Fossil 1.29 was released:
https://www.fossil-scm.org/index
On Nov 7, 2018, at 6:18 AM, Zoltán Kócsi wrote:
>
> For some projects we used colour-coding of the Timeline entries, for
> example releases were coloured differently from developers-only commits
> and so on. That all seems to have gone.
If you upgraded your central repository server from 1.29 to
On 11/7/18, Zoltán Kócsi wrote:
>
> For some projects we used colour-coding of the Timeline entries, for
> example releases were coloured differently from developers-only commits
> and so on. That all seems to have gone.
>
> Also, the Timeline now seems to show only one branch at a time while the
Richard,
> > Is the latest Fossil binary compatible with the 1.29 version on the
> > repo file level?
>
> Yes.
Thanks! It worked fine.
However, a quick question:
For some projects we used colour-coding of the Timeline entries, for
example releases were coloured differently from developers-only
On 11/7/18, Zoltán Kócsi wrote:
>
> Is the latest Fossil binary compatible with the 1.29 version on the
> repo file level? That is, will it be able to read the old SQLite file
> and modify/update its schema to the latest version without losing
> anything?
Yes.
In fact, I don't recall any major s
On Thu, Apr 7, 2016 at 5:04 AM, John Regehr wrote:
> Argh, thanks, sorry for the noise!
>
> John
>
>
> On 4/7/16 2:02 PM, Richard Hipp wrote:
>
>> On 4/7/16, John Regehr wrote:
>>
>>> What is the branch tag reported by fossil status? Perhaps the branch you
were on got renamed?
>>>
>>>
On 4/7/2016 5:02 AM, Richard Hipp wrote:
On 4/7/16, John Regehr wrote:
Is that expected that I will be silently moved between branches?
Normally Fossil does not move between branches. Except, if you use
the --latest option, it will move to the most latest descendent of the
current check
Argh, thanks, sorry for the noise!
John
On 4/7/16 2:02 PM, Richard Hipp wrote:
On 4/7/16, John Regehr wrote:
What is the branch tag reported by fossil status? Perhaps the branch you
were on got renamed?
It says this:
tags: pager-get-noinit
whereas I had previously been on the trunk. Is
On 4/7/16, John Regehr wrote:
>> What is the branch tag reported by fossil status? Perhaps the branch you
>> were on got renamed?
>
> It says this:
>
> tags: pager-get-noinit
>
> whereas I had previously been on the trunk. Is that expected that I
> will be silently moved between branches?
>
Norm
What is the branch tag reported by fossil status? Perhaps the branch you
were on got renamed?
It says this:
tags: pager-get-noinit
whereas I had previously been on the trunk. Is that expected that I
will be silently moved between branches?
Sorry if I'm asking dumb questions-- I'm really ju
On Thu, Apr 7, 2016 at 4:45 AM, Scott Robison
wrote:
> What is the branch tag reported by fossil status? Perhaps the branch you
> were on got renamed?
>
> On Thu, Apr 7, 2016 at 2:43 AM, John Regehr wrote:
>
>> Hi Andy,
>>
>> I'm returning to this topic because I again have a repo that got "stuc
What is the branch tag reported by fossil status? Perhaps the branch you
were on got renamed?
On Thu, Apr 7, 2016 at 2:43 AM, John Regehr wrote:
> Hi Andy,
>
> I'm returning to this topic because I again have a repo that got "stuck".
>
> Please see the interaction with fossil below. I ran "foss
Hi Andy,
I'm returning to this topic because I again have a repo that got "stuck".
Please see the interaction with fossil below. I ran "fossil update
--latest" and it received 53 artifacts, but didn't end up updating and
of my local files. And in fact, a diff between a fresh checkout of
sql
Thus said John Regehr on Tue, 08 Mar 2016 10:18:15 +0100:
> This usually works, but every couple of weeks my local repository gets
> somehow stuck in a state where the remote changes appear to be pulled
> from the server, but then they are not applied to my local sources.
> This has happened a
Thanks for the help Martin and Stephan!
Unfortunately I already nuked the stuck repository. However, I will save
a copy next time this happens, it seems somewhat predicable.
John
On 3/8/16 12:28 PM, Martin Gagnon wrote:
Le 8 mars 2016 à 05:23, Stephan Beal mailto:sgb...@googlemail.com>> a
> Le 8 mars 2016 à 05:23, Stephan Beal a écrit :
>
>> On Tue, Mar 8, 2016 at 10:18 AM, John Regehr wrote:
>> I have an extremely simply use case for fossil: I'm tracking the latest
>> sqlite sources but I have some modifications in my local repository. Every
>> few days I run "fossil update --
On Tue, Mar 8, 2016 at 10:18 AM, John Regehr wrote:
> I have an extremely simply use case for fossil: I'm tracking the latest
> sqlite sources but I have some modifications in my local repository. Every
> few days I run "fossil update --latest". This usually works, but every
> couple of weeks my
On Fri, Apr 25, 2014 at 8:32 AM, Stephan Beal wrote:
> On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon wrote:
>
>> Is there a known problem with time skew in the first place? Maybe
>> resolving that would fix these untraceable phantoms.
>>
>
> Not that i'm aware of - i was speculating that maybe the
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon wrote:
> Is there a known problem with time skew in the first place? Maybe
> resolving that would fix these untraceable phantoms.
>
Not that i'm aware of - i was speculating that maybe the clock was used as
an optimization for the client to ask the ser
Is there a known problem with time skew in the first place? Maybe
resolving that would fix these untraceable phantoms.
I also bumped into something similar when hosting the same .fossil on
two different servers with a time skew between them. Everything was
fine when I fixed the time settings, thou
On Thu, Apr 24, 2014 at 10:36 AM, j. van den hoff wrote:
> maybe this additional observation helps to get this "missing commit"
> phenomenon sorted out -- it really is a bit scary even if nothing really
> bad is happening to the repo content.
>
It is indeed, but until we can see it happening we
just for the record, I believe I encountered something similar:
I have a very simple setup: a remote (cgi-served) repo (acting
essentially only as a backup but publicly accessible) and _one_ local
clone where only _one_ user (me) does checkins (the owner of the remote
server _could_ clone/d
Thus said Michai Ramakers on Wed, 23 Apr 2014 18:34:32 +0200:
> I have no clue on sync logic at all, but perhaps this helps: in all
> cases I remember here (3 or so), when sync of commit on host A was not
> seen during sync on host B, doing a dummy-commit on host A, then
> pulling again o
On Wed, Apr 23, 2014 at 09:12:28AM -0700, Andreas Kupries wrote:
> I am wondering if the rebuild will also redo the cluster artifacts.
No, but it does rebuild the phantom table, a.k.a. the missing artifacts.
Joerg
___
fossil-users mailing list
fossil-us
On 23 April 2014 18:28, Andreas Kupries wrote:
>
> Another would be to see what the --verily is doing differently from
> regular sync.
> For ex. does it bypass the cluster optimizations ?
> I.e. any code bypassed by --verily would be suspect
I have no clue on sync logic at all, but perhaps this h
On Wed, Apr 23, 2014 at 9:15 AM, Stephan Beal wrote:
> On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries
> wrote:
>>
>> I am wondering if the rebuild will also redo the cluster artifacts.
>
>
> i have no idea - i'm not at all familiar with the sync-related code (because
> it's way down on the list
On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries
wrote:
> I am wondering if the rebuild will also redo the cluster artifacts.
>
i have no idea - i'm not at all familiar with the sync-related code
(because it's way down on the list of libfossil's TODOs ;).
> If these are done wrongly, it may ver
On Wed, Apr 23, 2014 at 8:38 AM, Stephan Beal wrote:
> On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne
> wrote:
>>
>> The only clue for you I have is that a rebuild on the server did the
>> trick. I'm no sure what "fossil rebuild" does though...
>
>
> Rebuild basically reconstructs the db from i
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne <
samuel.debio...@ujf-grenoble.fr> wrote:
> No proxy involved. The three machines are sitting on my desk. As a side
> note, the server is a raspberry PI and it does a great job at hosting
> fossil repo !
> ...
>
The three machines are clock sync wit
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne <
samuel.debio...@ujf-grenoble.fr> wrote:
> The only clue for you I have is that a rebuild on the server did the
> trick. I'm no sure what "fossil rebuild" does though...
>
Rebuild basically reconstructs the db from its underlying metadata. A very
> Out of curiosity: is there a proxy between them? A caching proxy
> server "might" explain this behaviour (in which case i think there's
> a workaround).
No proxy involved. The three machines are sitting on my desk. As a side
note, the server is a raspberry PI and it does a great job at hosting
f
Thus said Matt Welland on Tue, 22 Apr 2014 22:22:16 -0700:
> This has happened enough that I'm sure it was a real issue but it has
> been long enough since anyone reported it to me that I'd assumed it
> was fixed.
Unfortunately, nobody has been able to reproduce so it's kind of hard to
fix. T
On Tue, Apr 22, 2014 at 9:30 PM, Andy Bradford wrote:
> Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
>
> > Just to confirm that: this has come up several times before in the
> > past year and, so far, has remained unexplained. We're not sure what
> > causes it or how to reprod
Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
> Just to confirm that: this has come up several times before in the
> past year and, so far, has remained unexplained. We're not sure what
> causes it or how to reproduce it. (At least i don't remember seeing
> any commits/posts
On Tue, Apr 22, 2014 at 1:03 PM, Stephan Beal wrote:
> On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland wrote:
>
>> I have seen this issue a few times and this was with using file:// for
>> the transport to the "server". I've fixed it by doing a checkout to another
>> branch and back. If I recall c
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland wrote:
> I have seen this issue a few times and this was with using file:// for the
> transport to the "server". I've fixed it by doing a checkout to another
> branch and back. If I recall correctly a checkout to the current branch was
> not enough bu
On Tue, Apr 22, 2014 at 9:36 AM, Stephan Beal wrote:
> On Tue, Apr 22, 2014 at 11:36 AM, Samuel Debionne <
> samuel.debio...@ujf-grenoble.fr> wrote:
>
>> fossil commit -m "Blabla" from my PC
>> fossil update from my Mac
>>
>> But this time the update did not get the latest c
On Tue, Apr 22, 2014 at 11:36 AM, Samuel Debionne <
samuel.debio...@ujf-grenoble.fr> wrote:
> fossil commit -m "Blabla" from my PC
> fossil update from my Mac
>
> But this time the update did not get the latest checkin.
>
Out of curiosity: is there a proxy between them? A ca
On Tue, Apr 22, 2014 at 11:51 AM, Michai Ramakers wrote:
> not sure if this is the same issue you're seeing, but this has come up
> here a few times - commits not seen on pull/sync from different host.
>
> There's a '--verily' option to 'sync' iirc, to work around what may be
> a bug; see for exam
> There's a '--verily' option to 'sync' iirc, to work around what may be
> a bug; see for example this mail thread:
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12979.html.
> I'm not sure the issue has been solved in the meanwhile. (I haven't
> seen missing commits since that
Thus said Samuel Debionne on Tue, 22 Apr 2014 11:36:46 +0200:
> Here is a sequence I'm doing several times a day for years and that did
> not work this morning :
>
> fossil commit -m "Blabla" from my PC
> fossil update from my Mac
Has a fork happened? Have a look at the ti
Hello,
not sure if this is the same issue you're seeing, but this has come up
here a few times - commits not seen on pull/sync from different host.
There's a '--verily' option to 'sync' iirc, to work around what may be
a bug; see for example this mail thread:
https://www.mail-archive.com/fossil-u
On Sat, Apr 14, 2012 at 4:30 AM, Jos Groot Lipman wrote:
> **
> I did a recent update of my fossil repository. It shows that a total of
> 4243 bytes were sent and 95998 bytes were received.
> However if I add the numbers in the bytes column I get 6395 and 181518
> bytes, almost double the amount.
Ok,
Didn't realize there was a disconnected Leaf in the remote repo.
c:\myrepo> fossil merge 88d803c051
worked.
We still are unsure what created the disconnect?
Though we seem to have hiccups when upgrading the fossil.exe and doing
rebuilds on both local and remote repos.
On Tue, Aug 30, 2011 a
Hi,
I ran into a snag today after a week away on vacation.
This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC
I performed a pull.
c:\myrepo> fossil pull t:\myrepo\myrepo1.fossil
...lots of changes came down the network...
Bytes Cards Artifacts Deltas
Sent:
45 matches
Mail list logo
