On Mon, Oct 14, 2013 at 7:25 AM, Michai Ramakers wrote:
> On 14 October 2013 12:38, Richard Hipp wrote:
> >
> > On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers
> wrote:
> >>
> >> I can make the 3 repos available for debugging (for Richard) on
> >> request, but I have a pretty thin uplink (but l
rephrase:
On 14 October 2013 13:22, Michai Ramakers wrote:
> I don't think that is it; when viewing the timeline on the server, I do see
> the check-in.
"when viewing the timeline on the server, using the web interface ..."
Michai
___
fossil-users mai
On 14 October 2013 12:37, Stephan Beal wrote:
>
> On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers
> wrote:
>>
>> 2) update local repo on S
>> 3) local repo on S doesn't show recent check-in, as per 'fossil timeline'
>> 4) CGI-shared repo on S does show the check-in as per web interface timelin
On 14 October 2013 12:38, Richard Hipp wrote:
>
> On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers wrote:
>>
>> I can make the 3 repos available for debugging (for Richard) on
>> request, but I have a pretty thin uplink (but lots of space).
>
> How big are the repositories? Can you email them?
On 14 October 2013 12:37, Stephan Beal wrote:
> On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers wrote:
>
>> 2) update local repo on S
>> 3) local repo on S doesn't show recent check-in, as per 'fossil timeline'
>> 4) CGI-shared repo on S does show the check-in as per web interface
>> timeline
>
On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers wrote:
>
> I can make the 3 repos available for debugging (for Richard) on
> request, but I have a pretty thin uplink (but lots of space).
>
How big are the repositories? Can you email them?
--
D. Richard Hipp
d...@sqlite.org
___
On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers wrote:
> 2) update local repo on S
> 3) local repo on S doesn't show recent check-in, as per 'fossil timeline'
> 4) CGI-shared repo on S does show the check-in as per web interface
> timeline
>
What is the time span between 2==>3 and 3==>4? i ask
[ following up on oldish thread from mid August this year, with the
same subject ]
I've just seen this issue here, albeit in slightly another form
perhaps (2 systems 'S' (server, amd64 netbsd) and 'C' (client, WinXP
pro). 'S' makes a repo available using CGI/inetd, and I work on 'S'
locally as wel
One thing to add here, is that when this happened for us, I had two
different clones, one in a VM, and one on my workstation, and both of these
couldn't see the 'faulty' commit until I re-cloned the repo (on both).
So it seems to be a feature of the commit (or the copy that hits the
server) rather
On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin wrote:
> >
> > That sounds familiar. For the record, let me say I never (ever) make
> > branches; all work here is done on trunk.
>
> In the repository where a fellow developer and I have seen this problem,
> there have been no intentional branches mad
On Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote:
> On 21 August 2013 05:25, Donny Ward wrote:
> >
> > I get the same problem every once in awhile. Many times actually. I consider
> > myself a heavy fossil user. My most active repository has 1087 checkins all
> > made by me.
> >
> >
On Sun, Aug 18, 2013 at 05:20:35PM +0200, Michai Ramakers wrote:
>
> 1) on host S: clone project from host S (http://S/my_repo)
> 2) on host C: clone project from host S (http://S/my_repo)
> 3) on host C: do some work, and commit changes
> 4) on host S, 'fossil up'
> 5) on host S: 'fossil timeline
On 21 August 2013 05:25, Donny Ward wrote:
>
> I get the same problem every once in awhile. Many times actually. I consider
> myself a heavy fossil user. My most active repository has 1087 checkins all
> made by me.
>
> I once submitted a ticket about it here:
> http://www.fossil-scm.org/xfer/tktv
On Aug 20, 2013 8:25 PM, "Donny Ward" wrote:
>
> Hey Richard,
>
> I get the same problem every once in awhile. Many times actually. I
consider myself a heavy fossil user. My most active repository has 1087
checkins all made by me.
>
> I once submitted a ticket about it here:
http://www.fossil-scm.
Hey Richard,
I get the same problem every once in awhile. Many times actually. I
consider myself a heavy fossil user. My most active repository has 1087
checkins all made by me.
I once submitted a ticket about it here:
http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext
I have not
On 2013-08-19 20:31, Richard Hipp wrote:
That option is unreleased, so you'll have to compile from sources. That
is easier than you might imagine. Instructions here:
http://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki
It /must/ be. Even /I/ managed it! :)
--
Thanks,
DougF (KG4LMZ)
___
On Mon, Aug 19, 2013 at 7:46 PM, Clive Hayward wrote:
> Richard,
>
> Using fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC. Command:
> "fossil
> sync --verily"
>
> Result: "unknown repository: --verily"
>
> Grepping the code I see the "--verily" option looks only applicable to the
> "fos
Richard,
Using fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC.
Command: "fossil
sync --verily"
Result: "unknown repository: --verily"
Grepping the code I see the "--verily" option looks only applicable to the
"fossil scrub" command.
Is there a particular version that supports "--veril
Richard,
Would love to share repositories but would be violating my IP agreements:(
So I'll need to try and trigger the problem with non-business data.
Thanks for the reference to "fossil sync --verily"
On Sun, Aug 18, 2013 at 11:36 AM, Richard Hipp wrote:
> I think there is a bug in the syn
I think there is a bug in the sync algorithm that sometimes causes it to
quit before both sides are fully synced up. But I don't yet have a
reproducible test case, so it is a hard problem to fix.
If you find a pair of repositories that are not fully syncing, please do
this:
(1) Make backup copie
On Sun, Aug 18, 2013 at 8:12 PM, Clive Hayward wrote:
> 5) Client C updates but only gets Client A or B's commit but not both.
>
All i can say to that is, "yeah, that's weird." Unfortunately not terribly
helpful.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgb
Stephan,
Although I haven't been able to consistently reproduce the errors. These
were definitely not network errors.
The steps involve.
1) Client A makes a commit.
2) Client B makes a commit - but is warned that they will fork.
3) Client B updates - but doesn't appear to get Client A's commit.
On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward wrote:
> Michai,
>
> In more than one instance a subsequent commit was performed on one of the
> clients (unaware that there was an issue). That commit was visible to the
> other client only after the server repository was rebuilt.
>
i've had a coup
Michai,
In more than one instance a subsequent commit was performed on one of the
clients (unaware that there was an issue). That commit was visible to the
other client only after the server repository was rebuilt.
Clive
On Sun, Aug 18, 2013 at 10:28 AM, Michai Ramakers wrote:
> did any of yo
did any of you (Steve/Clive) by any chance try committing once more (a
dummy-change or similar) on what Steve has named client A (the client
whose commit is never seen by the other host)?
(And if so, did both it and the missing commit show up?)
Michai
__
I have experienced a similar problem as Steve on several occasions. To fix
the problem I've been rebuilding the server repository and then merging on
the server. Then the clients can pull to get in sync.
Clive
On Sun, Aug 18, 2013 at 9:25 AM, Stestagg wrote:
> We had a similar situation la
We had a similar situation last week:
Fossil server hosting many repos, two active clients on one repo.
Clients A and B were both working on the same branch simultaneously.
Client A commits (commit 1)
Client B tries to commit, gets conflict warning.
Client B runs fossil update
Client B commits s
On 18 August 2013 17:43, Stephan Beal wrote:
> On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers
> wrote:
>>
>> 1) on host S: clone project from host S (http://S/my_repo)
>> 2) on host C: clone project from host S (http://S/my_repo)
>> 3) on host C: do some work, and commit changes
>> 4) on host S
On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers wrote:
> 1) on host S: clone project from host S (http://S/my_repo)
> 2) on host C: clone project from host S (http://S/my_repo)
> 3) on host C: do some work, and commit changes
> 4) on host S, 'fossil up'
> 5) on host S: 'fossil timeline' doesn't s
Oh, perhaps useful: viewing the timeline on host S using the
web-interface (pointing to host S) at step (5) (or after step (6), not
sure) showed the commit I was expecting to see.
On 18 August 2013 17:20, Michai Ramakers wrote:
> Hello,
>
> I'm probably doing somethng strange, but has anyone ever
Hello,
I'm probably doing somethng strange, but has anyone ever seen this behaviour:
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossi
31 matches
Mail list logo
