On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers m.ramak...@gmail.comwrote:
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
On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers m.ramak...@gmail.comwrote:
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 14 October 2013 12:37, Stephan Beal sgb...@googlemail.com wrote:
On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers m.ramak...@gmail.comwrote:
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
On 14 October 2013 12:38, Richard Hipp d...@sqlite.org wrote:
On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers m.ramak...@gmail.com 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
On 14 October 2013 12:37, Stephan Beal sgb...@googlemail.com wrote:
On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers m.ramak...@gmail.com
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
rephrase:
On 14 October 2013 13:22, Michai Ramakers m.ramak...@gmail.com 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
___
On Mon, Oct 14, 2013 at 7:25 AM, Michai Ramakers m.ramak...@gmail.comwrote:
On 14 October 2013 12:38, Richard Hipp d...@sqlite.org wrote:
On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers m.ramak...@gmail.com
wrote:
I can make the 3 repos available for debugging (for Richard) on
On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com 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:
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 Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote:
On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com 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
On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin c...@apotheon.net 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
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)
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 Aug 20, 2013 8:25 PM, Donny Ward donnyjw...@gmail.com 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:
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 --verily for
On Mon, Aug 19, 2013 at 7:46 PM, Clive Hayward haywa...@chayward.comwrote:
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
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)
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 m.ramak...@gmail.com wrote:
Hello,
I'm probably doing somethng strange,
On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.comwrote:
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
On 18 August 2013 17:43, Stephan Beal sgb...@googlemail.com wrote:
On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.com
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,
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
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 stest...@gmail.com wrote:
We had a
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
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
On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward haywa...@chayward.comwrote:
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.
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
On Sun, Aug 18, 2013 at 8:12 PM, Clive Hayward haywa...@chayward.comwrote:
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/
27 matches
Mail list logo
