Re: [fossil-users] Fossil update

[Andy Bradford]

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.html/timeline?c=2014-07-22+22:26:50

Check your  ``fossil version'' to be  certain. If it is  indeed the same
bug, then you can use ``fossil  pull --verily'' to pull down the missing
content.

Andy
-- 
TAI64 timestamp: 40005be44f6c


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update

[Warren Young]

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 2.7 to fix the 
problem suggested by drh — someone’s been checking in SHA3-hashed artifacts — 
then you also have to update your skin.

If you were using the stock skin before, just go into Admin > Skins and select 
the Default skin again.  You might have to switch to some other skin and back 
to get it to overwrite your outdated skin files.

If you made changes to your local skin, you’ll have to merge the changes made 
to the default version of the skin you started with into your local version.

In versions 2.5 and 2.7, there were a lot of changes to the default skin, some 
of which were done to track changes made to the HTML emitted by “fossil server” 
in support of newer features.  Outdated skins won’t style the new HTML properly.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update

[Richard Hipp]

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
> old version has shown all changes and different branches were
> represented by different colours and a graphically displayed line.

Those features should be unchanged.  If you visit the canonical Fossil
self-hosting repo (https://fossil-scm.org/fossil/timeline) or the
SQLite Fossil repository (https://sqlite.org/src/timeline) you can see
that both of those show all branches using color codes.  I do not know
what might be causing your problem.  Can you provide an example?


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update

[Zoltán Kócsi]

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 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
old version has shown all changes and different branches were
represented by different colours and a graphically displayed line. That
made a side-by-side tracking of different branches a breeze without
needing to compare dates while switching between branches back and
forth.

Are those features really gone or in the new Fossil you need to
explicitly turn them on or it's just that my ancient browser (I update
browsers about as frequently as I update Fossil) can't cope with some
new HTML5 whizz-bang that Fossil now uses?

Thanks,

Best Regards,

Zoltan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update

[Richard Hipp]

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 schema changes going from 1.x to
2.x.  The big change there, and the reason for the major version
number bump, was adding support for SHA3 hashes.  1.x supported only
SHA1 hashes.  2.x supports both SHA1 and SHA3.  Thus 2.x will read and
understand 1.x repos, but 1.x cannot decode 2.x repos.

If I had to guess (with so little information) about why you are not
seeming to sync, I would suspect that somebody in your organization is
using a 2.x version of Fossil and has done one or more commits that
use a SHA3 hash.  The older 1.x versions cannot understand that and
are pretending those checkins do not exist.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Matt Welland]

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?

>>>
>>> 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?
>>>
>>>
>> 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-out, regardless of the branch.  So probably what
>> happened is that you did "fossil up --latest" at a time when the
>> pager-get-noinit branch was the latest descendent of the trunk
>> check-in that you were previously on.  But pager-get-noinit is
>> currently a dead-end.  (Maybe we'll merge it to trunk later, or maybe
>> not - still undecided on that.)  And so subsequent "fossil up
>> --latest" commands do not move you off of that check-in because that
>> check-in currently has no descendants.
>>
>
>From a design-for-humans perspective I think fossil should stick to the
branch *name*. The least surprising thing is to end up on the tip of the
branch where you were working previously, not on the tip of some new
branch. If I'm working on "trunk" and do a fossil update and end up on
"some-debug-branch" I will be confused. The symbolic name is the critical
data here IMHO.


>
>> If you want to move to the latest trunk check-in, then the command to
>> use is "fossil update trunk".
>>
>> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Ross Berteig]

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-out, regardless of the branch
If you want to move to the latest trunk check-in, then the command to
use is "fossil update trunk".


That answers a nagging question I'd had: What is the difference between 
"fossil update --latest" and "fossil update tip"?


Answer: "tip" is the very last checkin to any branch, while "--latest" 
is the very last checkin descending from "current".



So now my question is what can we do to the wording of the help for 
update that makes the actual meaning of --latest clearer?


It currently says:

Usage: %fossil update ?OPTIONS? ?VERSION? ?FILES...?

The VERSION argument can be a specific version or tag or branch
name.  If the VERSION argument is omitted, then the leaf of the
subtree that begins at the current version is used, if there is
only a single leaf.  VERSION can also be "current" to select the
leaf of the current version or "latest" to select the most recent
check-in.

Options:
   
   --latest acceptable in place of VERSION, update to
latest version
   


One thing that should be at least hinted at here is that using anything 
other than "fossil update" or "fossil update current" (which are exact 
synonyms) *can* move you to a different branch, and unless you are 
deliberately attempting to change to a different branch that move is 
likely to be surprising.


It should probably also say that "--latest" and "latest" are the same 
thing. As it is worded now, the two ways of describing it seem to hint 
at a difference that isn't there.


I'll take a crack at rewriting that "soon", but if anyone else has ideas 
I'm all ears...


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[John Regehr]

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 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-out, regardless of the branch.  So probably what
happened is that you did "fossil up --latest" at a time when the
pager-get-noinit branch was the latest descendent of the trunk
check-in that you were previously on.  But pager-get-noinit is
currently a dead-end.  (Maybe we'll merge it to trunk later, or maybe
not - still undecided on that.)  And so subsequent "fossil up
--latest" commands do not move you off of that check-in because that
check-in currently has no descendants.

If you want to move to the latest trunk check-in, then the command to
use is "fossil update trunk".


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Richard Hipp]

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?
>

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-out, regardless of the branch.  So probably what
happened is that you did "fossil up --latest" at a time when the
pager-get-noinit branch was the latest descendent of the trunk
check-in that you were previously on.  But pager-get-noinit is
currently a dead-end.  (Maybe we'll merge it to trunk later, or maybe
not - still undecided on that.)  And so subsequent "fossil up
--latest" commands do not move you off of that check-in because that
check-in currently has no descendants.

If you want to move to the latest trunk check-in, then the command to
use is "fossil update trunk".

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[John Regehr]

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 just trying to keep my 
interactions with fossil to a minimum while staying up to date with the 
latest sqlite sources.


Thanks,

John
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Scott Robison]

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 "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 sqlite and
>> the repo below shows that I don't have the latest changes. My experience is
>> that a repo that gets stuck in this fashion will continue to receive
>> artifacts from the server but will never again update my local files with
>> fresh content.
>>
>
Sorry for the premature / top posted reply previously.

Anyway, if you are not on trunk, fossil update --latest will only take you
to the latest commit on whatever branch you are on. If a branch was
renamed, you'll be some place other than where you expected.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Scott Robison]

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 "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 sqlite and
> the repo below shows that I don't have the latest changes. My experience is
> that a repo that gets stuck in this fashion will continue to receive
> artifacts from the server but will never again update my local files with
> fresh content.
>
> Thanks,
>
> John
>
>
>
> john@TrustInSoft-Box-V:~$ cd sqlite/
> john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest
> Autosync:  http://www.sqlite.org/cgi/src
> Round-trips: 3   Artifacts sent: 0  received: 53
> Pull done, sent: 2148  received: 33277  ip: 67.18.92.124
>
> ---
> checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01
> UTC
> tags: pager-get-noinit
> comment:  Avoid unnecessary memset() operations in sqlite3PagerGet().
> (user: drh)
> changes:  None. Already up-to-date
> john@TrustInSoft-Box-V:~/sqlite$
> john@TrustInSoft-Box-V:~/sqlite$
> john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest
> Autosync:  http://www.sqlite.org/cgi/src
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, sent: 289  received: 658  ip: 67.18.92.124
>
> ---
> checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01
> UTC
> tags: pager-get-noinit
> comment:  Avoid unnecessary memset() operations in sqlite3PagerGet().
> (user: drh)
> changes:  None. Already up-to-date
> john@TrustInSoft-Box-V:~/sqlite$
>
>
>
>
>
> On 3/8/16 3:47 PM, Andy Bradford wrote:
>
>> 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 about 4 times.
>>>
>>
>> Can you be a little more specific about what this means? For example, do
>> you see the remote changes in  the timeline in your local repository and
>> Fossil simply  does not update your  open checkout to those  versions of
>> the file? Or do you not see the changes at all?
>>
>> Can you provide  some output from the commands you're  running when this
>> problem happens?
>>
>> Thanks,
>>
>> Andy
>>
>> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[John Regehr]

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 
sqlite and the repo below shows that I don't have the latest changes. My 
experience is that a repo that gets stuck in this fashion will continue 
to receive artifacts from the server but will never again update my 
local files with fresh content.


Thanks,

John



john@TrustInSoft-Box-V:~$ cd sqlite/
john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest
Autosync:  http://www.sqlite.org/cgi/src
Round-trips: 3   Artifacts sent: 0  received: 53
Pull done, sent: 2148  received: 33277  ip: 67.18.92.124
---
checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 
00:44:01 UTC

tags: pager-get-noinit
comment:  Avoid unnecessary memset() operations in 
sqlite3PagerGet(). (user: drh)

changes:  None. Already up-to-date
john@TrustInSoft-Box-V:~/sqlite$
john@TrustInSoft-Box-V:~/sqlite$
john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest
Autosync:  http://www.sqlite.org/cgi/src
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 289  received: 658  ip: 67.18.92.124
---
checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 
00:44:01 UTC

tags: pager-get-noinit
comment:  Avoid unnecessary memset() operations in 
sqlite3PagerGet(). (user: drh)

changes:  None. Already up-to-date
john@TrustInSoft-Box-V:~/sqlite$





On 3/8/16 3:47 PM, Andy Bradford wrote:

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 about 4 times.


Can you be a little more specific about what this means? For example, do
you see the remote changes in  the timeline in your local repository and
Fossil simply  does not update your  open checkout to those  versions of
the file? Or do you not see the changes at all?

Can you provide  some output from the commands you're  running when this
problem happens?

Thanks,

Andy


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Andy Bradford]

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 about 4 times.

Can you be a little more specific about what this means? For example, do
you see the remote changes in  the timeline in your local repository and
Fossil simply  does not update your  open checkout to those  versions of
the file? Or do you not see the changes at all?

Can you provide  some output from the commands you're  running when this
problem happens?

Thanks,

Andy
-- 
TAI64 timestamp: 400056dee638


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Martin Gagnon]

> 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 --latest".  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 about 4 times.  When the 
>> problem occurs it is persistent and I need to save my patches off on the 
>> side and re-clone the sqlite archive.
> 
> Please try changing the update to a combination of (pull --verily) and 
> (update --latest). In the past (pull --verily) has helped work around similar 
> problems (AFAIK, the root of that particular problem has never been 
> discovered, but it crops up once in a while on the mailing list.)
> 

Please, before to do that, make a copy of your repository file in that state.

 Just in case someone from this list want it to find the root of the problem 
later.  This problem happens rarely and if I remember it use to be on private 
repository that couldn't be share. 

-- 
Martin G.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Stephan Beal]

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 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 about 4 times.  When the
> problem occurs it is persistent and I need to save my patches off on the
> side and re-clone the sqlite archive.
>

Please try changing the update to a combination of (pull --verily) and
(update --latest). In the past (pull --verily) has helped work around
similar problems (AFAIK, the root of that particular problem has never been
discovered, but it crops up once in a while on the mailing list.)


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Ory Drilon]

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, though I logged an extra comment
to ticket 683457aa0f in case it would be useful.

 i'm wondering if perhaps your server had system event and the clock was
 skewed for a brief period. That's probably impossible to know for sure now.

Perhaps the clock on the host NFS system is slower than the one on your
mac? Perhaps a time mis-sync is causing this?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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 to ask the server has anything arrives
since time X, but i don't think that actually happens.


 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, though I logged an extra comment
 to ticket 683457aa0f in case it would be useful.


The timeline will do funny things in a time skew, but it otherwise should
not cause any real grief.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Richard Hipp]

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 speculating that maybe the clock was used as
 an optimization for the client to ask the server has anything arrives
 since time X, but i don't think that actually happens.


The sync algorithm does not use timestamps.  So clock skew should not
effect sync in any way.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[j. van den hoff]

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/do checkins but he doesn't...). autosync is 'off'  
right now, so I do the `sync/push' manually (by habit I use `sync'  
although `push' would suffice since no one _ever_ does an independent  
checkin to the server-side repo (no other clone, no local developer on the  
server) and I do not expect incoming changes.


so what I have observed a week ago was some hickup (I don't recall what  
exactly, either a failed `sync' or `push') and retried (probably at that  
point `sync'). I then discovered a fork popping up in the timeline which,  
moreover, confusingly was some ten days in the past (the timeline had  
already progressed several commits after the fork).


I don't see any reason why (and any way how) this fork could have occurred.

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.


if you want to have a look, the repo is freely accessible here:

http://j...@fossil.0branch.com/sd

(maybe the repo content is even of some interest to someone ...)

the fork in question is [a8cbddcfc3]. In the meantime I have closed it  
explicitly and edited the checkin comment (the latter I did directly in  
the server-side repo where I've chosen a different user name than for the  
local clone). the original ci-comment was identical to that of  
[efd8772a0b] (and it's diff vs. [88f8514b9f] is a subset of the diff of  
[efd8772a0b] vs.  [88f8514b9f]).


I could not make head nor tail of this. I also cannot rule out completely  
that I am responsible for the fork (making some stupid error) but really  
cannot imagine how and that it has nothing to do with the problems  
discussed in this thread. but maybe it does ...



j.

On Thu, 24 Apr 2014 07:20:56 +0200, Andy Bradford  
amb-fos...@bradfords.org wrote:



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 B, worked, i.e. last 2 commits from A were pulled.


This sounds  almost identical to  the problem  that I described  that is
caused  by  a  failed  autosync  except there  is  no  mention  of  fork
happening.  The  fork  may  or  may not  happen  if  the  branches  were
different.  But, committing  after a  failed sync  will certainly  cause
another autosync and  then the push with the new  changes will cause the
missing content to show up.

Andy



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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 see it happening we can only guess as to
what might actually cause it :(. My setups are almost 100% identical to
yours - CGI repos mostly used by one user (except that i use autosync
because i forget to push if i don't). i've been using Fossil daily for over
6 years and haven't seen this happen even once. Enough people have, though,
that it's obviously happening.

the fork in question is [a8cbddcfc3]. In the meantime I have closed it
 explicitly and edited the checkin comment (the latter I did directly in the
 server-side repo where I've chosen a different user name than for the local
 clone). the original ci-comment was identical to that of [efd8772a0b] (and
 it's diff vs. [88f8514b9f] is a subset of the diff of [efd8772a0b] vs.
  [88f8514b9f]).


i'm wondering if perhaps your server had system event and the clock was
skewed for a brief period. That's probably impossible to know for sure now.


 I could not make head nor tail of this. I also cannot rule out completely
 that I am responsible for the fork (making some stupid error) but really
 cannot imagine how and that it has nothing to do with the problems
 discussed in this thread. but maybe it does ...


It does indeed sound somewhat related.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Andy Bradford]

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 closest I could get was the problem I described.

Andy
-- 
TAI64 timestamp: 400053576491


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Samuel Debionne]

 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
fossil repo !

 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 but I'm not sure.

I'm using https transport layer (lighty web server handles the SSL part,
the fossil CGI interface is used).

The three machines are clock sync with NTP.

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...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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 introduction: fossil stored basically 3 types of things:

a) the so-called Manifests, which are formal records of changes.
b) the file content which (A) refers to
c) a whole bunch of _transient_ relational data which is created based on
(A).

A rebuild basically deletes (C) then regenerates it from (A). (C) includes
things like the timeline, the parent/child relationships, and basically
anything which can be derived from the low-level (A) parts. The docs for
(A) are here:

http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki

(They're only interesting if you're into really geeky details, though.)


A snippet from some arbitrary manifest might help clarify:

[stephan@host:~/cvs/fossil/libfossil]$ f-acat current | head
B d846a10d99c1e169c7587c8dc2a67170eae8a1d7
C minor\sdoc\saddition.
D 2014-04-22T20:19:58.256
F f-apps/f-sanity.c e3e21327062f3a39c7109ce41ce616fd2a9b772c
F f-apps/f-status.c 0c6d8e9420594f21e75ff86ede758ac7d35217bf
F include/fossil-scm/fossil-cli.h c3c46f81009d410eff793d68311a769f58a5abc5
F include/fossil-scm/fossil-db.h a19862f0994b865a76831140b25f1c3cedab83a0
F include/fossil-scm/fossil-internal.h
1ca2e6dabf769a4a6bab21805e21b8ba515beb7e
F include/fossil-scm/fossil-util.h 0b765f7960e0b09286e8cd399d00cf86c8f71ee5
F src/fsl.c acce29830dd3d56053d9ee81169c51c3ede60a2d
...

All those SHA1 hashes refer to items in the (B) data set. Some of them (the
ones starting with F) are file content and some (e.g. the B part) refer
to other metadata from (A) (which is stored in (B), actually). The B part
refers to another checkin version from which this one derives certain
metadata.

We can take one of those UUID at random and get its content:

[stephan@host:~/cvs/fossil/libfossil]$ f-acat
e3e21327062f3a39c7109ce41ce616fd2a9b772c | head -5
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*-
*/
/* vim: set ts=2 et sw=2 tw=80: */
/*
   Copyright (c) 2013-2014 D. Richard Hipp

...

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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.


Then i am still at an utter loss.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Andreas Kupries]

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...


 Rebuild basically reconstructs the db from its underlying metadata. A very
 brief introduction: fossil stored basically 3 types of things:

 a) the so-called Manifests, which are formal records of changes.
 b) the file content which (A) refers to
 c) a whole bunch of _transient_ relational data which is created based on
 (A).

 A rebuild basically deletes (C) then regenerates it from (A). (C) includes
 things like the timeline, the parent/child relationships, and basically
 anything which can be derived from the low-level (A) parts. The docs for (A)
 are here:

I am wondering if the rebuild will also redo the cluster artifacts.

They are for sync optimization, i.e. telling the other side in a
single hash that a group of manifests is present.

If these are done wrongly, it may very well cause the receiver to
believe that it has stuff which it doesn't.




 http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki

 (They're only interesting if you're into really geeky details, though.)


 A snippet from some arbitrary manifest might help clarify:

 [stephan@host:~/cvs/fossil/libfossil]$ f-acat current | head
 B d846a10d99c1e169c7587c8dc2a67170eae8a1d7
 C minor\sdoc\saddition.
 D 2014-04-22T20:19:58.256
 F f-apps/f-sanity.c e3e21327062f3a39c7109ce41ce616fd2a9b772c
 F f-apps/f-status.c 0c6d8e9420594f21e75ff86ede758ac7d35217bf
 F include/fossil-scm/fossil-cli.h c3c46f81009d410eff793d68311a769f58a5abc5
 F include/fossil-scm/fossil-db.h a19862f0994b865a76831140b25f1c3cedab83a0
 F include/fossil-scm/fossil-internal.h
 1ca2e6dabf769a4a6bab21805e21b8ba515beb7e
 F include/fossil-scm/fossil-util.h 0b765f7960e0b09286e8cd399d00cf86c8f71ee5
 F src/fsl.c acce29830dd3d56053d9ee81169c51c3ede60a2d
 ...

 All those SHA1 hashes refer to items in the (B) data set. Some of them (the
 ones starting with F) are file content and some (e.g. the B part) refer
 to other metadata from (A) (which is stored in (B), actually). The B part
 refers to another checkin version from which this one derives certain
 metadata.

 We can take one of those UUID at random and get its content:

 [stephan@host:~/cvs/fossil/libfossil]$ f-acat
 e3e21327062f3a39c7109ce41ce616fd2a9b772c | head -5
 /* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*-
 */
 /* vim: set ts=2 et sw=2 tw=80: */
 /*
Copyright (c) 2013-2014 D. Richard Hipp

 ...

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster(tm)
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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 done wrongly, it may very well cause the receiver to
 believe that it has stuff which it doesn't.


It's a starting point, which is more than we've had so far :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Andreas Kupries]

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 (because
 it's way down on the list of libfossil's TODOs ;).
 If these are done wrongly, it may very well cause the receiver to
 believe that it has stuff which it doesn't.


 It's a starting point, which is more than we've had so far :/.

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



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster(tm)
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/
21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Michai Ramakers]

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 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 B, worked, i.e. last 2 commits from A were pulled.

Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Joerg Sonnenberger]

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-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Andy Bradford]

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 B, worked, i.e. last 2 commits from A were pulled.

This sounds  almost identical to  the problem  that I described  that is
caused  by  a  failed  autosync  except there  is  no  mention  of  fork
happening.  The  fork  may  or  may not  happen  if  the  branches  were
different.  But, committing  after a  failed sync  will certainly  cause
another autosync and  then the push with the new  changes will cause the
missing content to show up.

Andy
-- 
TAI64 timestamp: 400053589f5b


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Michai Ramakers]

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-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 post.)

Michai

On 22 April 2014 11:36, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote:
 Hello all,
 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

 But this time the update did not get the latest checkin.

 A complete clone / open in a different directory was OK though.

 I had to rebuild the repository on the server to make it work. Any ideas
 why ?
 Samuel
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Andy Bradford]

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 and see  if there is a
fork  somewhere that  would  have  caused your  current  checkout to  be
different from what you might expect.

Did the  sync fail on a  push from somewhere  and what you expect  to be
there isn't quite there?

Just some thoughts, not sure if these are relevant.

Andy
-- 
TAI64 timestamp: 400053567af6


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Samuel Debionne]

 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 post.)

Did not know about the '--verily' option.

As you say in your post, if it comes up again, I'll try to keep it
as-is, if that's possible, and post it on here.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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 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 post.)


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
which explain/fix it.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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 proxy server
might explain this behaviour (in which case i think there's a workaround).

(e.g. when web-deploying client-side Java applications in enterprise
environments, caching proxies often cause some clients to be served older
JAR files until the cache expires or is reset.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Matt Welland]

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 latest checkin.


 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).


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 but I'm not sure.



 (e.g. when web-deploying client-side Java applications in enterprise
 environments, caching proxies often cause some clients to be served older
 JAR files until the cache expires or is reset.)

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Stephan Beal]

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
 not enough but I'm not sure.


That's interesting. So the repo is on an NFS share. Perhaps the clock on
the host NFS system is slower than the one on your mac? Perhaps a time
mis-sync is causing this?


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Matt Welland]

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
 branch and back. If I recall correctly a checkout to the current branch was
 not enough but I'm not sure.


 That's interesting. So the repo is on an NFS share. Perhaps the clock on
 the host NFS system is slower than the one on your mac? Perhaps a time
 mis-sync is causing this?


Sorry, no Mac involved :) Linux all the way. I'm not sure how time skew
could cause this. In every case that I recall there were commits stored in
the fossil db that were more recent than the current checkout but fossil
update seemed not to see them. If it happens again I'll try to preserve
things to reproduce it.

What is the update algorithm using for a deciding basis, node time or
parent-child relationship? One thing that may be related is that if there
is a fork and you do an update fossil does not move to the latest node on
the appropriate tine of the fork. This is both silent - i.e. the user has
no feedback and must look at the node id and timeline to figure out what is
going on, and a hassle because to merge the fork you need to use checkout
to get to the tip of the tine.

In brief it seems that fossil is not moving along the timeline on update in
some cases where it could and this might be the logic that is being
triggered by the rare fails to update bug.


 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Andy Bradford]

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 which explain/fix it.)

The only time I've  ever seen it *not* update to the  latest commit in a
remote repository is when a sync has failed. For example:

$ ../fossil ci -m bottom
Autosync:  ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 2   Artifacts sent: 0  received: 18
Pull finished with 1063 bytes sent, 298025 bytes received
New_Version: 18febd6eb320521d5b730d237381d001b562496e
Autosync:  ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 1   Artifacts sent: 2  received: 0
Error: Database error: database is locked: {INSERT INTO rcvfrom(uid, mtime, 
nonce, ipaddr)VALUES(1, julianday('now'), NULL, '192.168.1.5')}
Round-trips: 1   Artifacts sent: 2  received: 0
Sync finished with 1586 bytes sent, 290 bytes received
Autosync failed
$ ../fossil up
Autosync:  ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 3   Artifacts sent: 0  received: 84
Pull finished with 3012 bytes sent, 1355913 bytes received
---
checkout: 18febd6eb320521d5b730d237381d001b562496e 2014-04-23 04:18:45 UTC
tags: trunk
comment:  bottom (user: amb)
changes:  None. Already up-to-date

But I know that  18fe is not the tip of trunk. If  I manually tell it to
update to  5f75 it will update.  Also, because the sync  failed, I don't
see my commit on the remote repository yet. Once I do a sync it shows up
though, and after I sync I actually see that a fork has occurred.

Is this the same issue that others are seeing? Hard to say, but it's the
only time I've observed any kind of failure to update.

Andy
-- 
TAI64 timestamp: 400053574221


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update goes not get lastest checkin

[Matt Welland]

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  or how to reproduce  it. (At least i  don't remember seeing
  any commits/posts which explain/fix it.)

 The only time I've  ever seen it *not* update to the  latest commit in a
 remote repository is when a sync has failed. For example:

 $ ../fossil ci -m bottom
 Autosync:  ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
 Round-trips: 2   Artifacts sent: 0  received: 18
 Pull finished with 1063 bytes sent, 298025 bytes received
 New_Version: 18febd6eb320521d5b730d237381d001b562496e
 Autosync:  ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
 Round-trips: 1   Artifacts sent: 2  received: 0
 Error: Database error: database is locked: {INSERT INTO rcvfrom(uid,
 mtime, nonce, ipaddr)VALUES(1, julianday('now'), NULL, '192.168.1.5')}
 Round-trips: 1   Artifacts sent: 2  received: 0
 Sync finished with 1586 bytes sent, 290 bytes received
 Autosync failed
 $ ../fossil up
 Autosync:  ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
 Round-trips: 3   Artifacts sent: 0  received: 84
 Pull finished with 3012 bytes sent, 1355913 bytes received

 ---
 checkout: 18febd6eb320521d5b730d237381d001b562496e 2014-04-23 04:18:45
 UTC
 tags: trunk
 comment:  bottom (user: amb)
 changes:  None. Already up-to-date

 But I know that  18fe is not the tip of trunk. If  I manually tell it to
 update to  5f75 it will update.  Also, because the sync  failed, I don't
 see my commit on the remote repository yet. Once I do a sync it shows up
 though, and after I sync I actually see that a fork has occurred.

 Is this the same issue that others are seeing? Hard to say, but it's the
 only time I've observed any kind of failure to update.


I haven't seen this problem in quite a while but what we saw was the sync
had occurred and yet we couldn't update to the tip. I had suspected this
issue was solved, perhaps indirectly or by other development. It is rare
enough and easy enough to work around that other than reporting it I
haven't worried about it. Unfortunately in every case it happened the repo
in question contained data that could not be shared so I couldn't provide a
testcase.

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.


 Andy
 --
 TAI64 timestamp: 400053574221


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil update: Total network traffic does not add up

[Richard Hipp]

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 the amount.

 Why the difference? Is one compressed and the other uncompressed?


The individual Sent and Received lines are measuring uncompressed content.
The total is showing the actual compressed byte-count sent over-the-wire.



 d:\Software\Fossilfossil update
 Autosync:  http://www.fossil-scm.org/
 Bytes  Cards  Artifacts Deltas
 Sent: 177  2  0  0
 Received:3712 81  0  0
 Sent:3937 82  0  0
 Received:  153580161  7 73
 Sent:2104 43  0  0
 Received:   20514122  1 40
 Sent: 177  2  0  0
 Received:3712 81  0  0
 Total network traffic: 4243 bytes sent, 95998 bytes received


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update FAIL

[sky5walk]

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 at 7:10 PM,  sky5w...@gmail.com wrote:
 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:             130          1          0          0
 Received:        2056         45          0          0
 Sent:            1023         20          0          0
 Received:       11346         64          0         19
 Total network traffic: 957 bytes sent, 6805 bytes received

 I then ran an update.
 c:\myrepo fossil update
 ...nothing happened. no report?
 ...But I assumed my checkout contained the latest changes.
 ...So I began to edit my code and noticed none of the changes were there.

 Question: What should I do in this case?

 I eventually got things aligned with 2 cycles of close/open.
 Not sure why?
 I ran a close.
 c:\myrepo fossil close

 I ran an open.
 c:\myrepo fossil open myrepo.fossil
 ...Still no update of my folder contents!
 Repeat worked.

 Maybe if I automated this via a script, I would have stopped
 immediately after receiving no report on the update?

 Thanks for your help.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users