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:
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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,
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon o...@drilon.com 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
On Fri, Apr 25, 2014 at 8:32 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon o...@drilon.com 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
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_
On Thu, Apr 24, 2014 at 10:36 AM, j. van den hoff veedeeh...@googlemail.com
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
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. The
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
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
brief
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 with NTP.
On Wed, Apr 23, 2014 at 8:38 AM, Stephan Beal sgb...@googlemail.com wrote:
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...
On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries
andre...@activestate.comwrote:
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
On Wed, Apr 23, 2014 at 9:15 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries andre...@activestate.com
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
On 23 April 2014 18:28, Andreas Kupries andre...@activestate.com 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
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
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 on
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:
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 timeline
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
On Tue, Apr 22, 2014 at 11:51 AM, Michai Ramakers m.ramak...@gmail.comwrote:
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
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 caching
On Tue, Apr 22, 2014 at 9:36 AM, Stephan Beal sgb...@googlemail.com 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
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland estifo...@gmail.com 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
On Tue, Apr 22, 2014 at 1:03 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland estifo...@gmail.com 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
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 9:30 PM, Andy Bradford amb-fos...@bradfords.orgwrote:
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
On Sat, Apr 14, 2012 at 4:30 AM, Jos Groot Lipman donts...@home.nl 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
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
43 matches
Mail list logo