On Thursday, December 03, 2015 5:21 AM, Andy Bradford wrote:
Thus said Andy Gibbs on Wed, 02 Dec 2015 16:56:35 +0100:
I can certainly let you know when (if?) it happens again. What can I
say about my usage patterns? ... I am certainly doing large check-ins,
for example, modifying 100s of file
Thus said Andy Gibbs on Wed, 02 Dec 2015 16:56:35 +0100:
> I can certainly let you know when (if?) it happens again. What can I
> say about my usage patterns?
Do you have multiple servers to which clients synchronize content before
it makes it back to the server where you noticed the problem
Thus said "j. van den hoff" on Wed, 02 Dec 2015 17:06:07 +0100:
> which at least means they were all post 1.30 (in which version the
> sync bug presumably was fixed) so I would take this as a strong
> indication that there still is a problem, right?
Possibly. I retried the same steps
Thus said Andy Gibbs on Wed, 02 Dec 2015 16:56:35 +0100:
> I can certainly let you know when (if?) it happens again. What can I
> say about my usage patterns? ... I am certainly doing large check-ins,
> for example, modifying 100s of files at once.
That certainly is similar to the criteria for
On Wed, Dec 2, 2015 at 5:08 PM, Tim Johnston wrote:
> I'm wondering about migrating my github 'issues' and turning them into
> fossil 'tickets'. Does anyone have experience with this? Any
> recommendations for approaching it?
>
I can't help with parsing the github tickets, but I can make suggest
On 2 December 2015 at 10:07, Stephan Beal wrote:
>
> On Dec 2, 2015 7:04 PM, "jungle Boogie" wrote:
>> So it even mentioning the fact that a commit may be crypto signed, it
>> may be a security issue?
>
> Yes. See this part of the thread you posted:
>
> http://www.mail-archive.com/fossil-users%40
Hi all,
I've decided it's about time to move my github project to a fossil
repository. I saw some instructions on the wiki for migrating my git
repository to fossil, so that part should be easy.
I'm wondering about migrating my github 'issues' and turning them into
fossil 'tickets'. Does anyone h
On Dec 2, 2015 7:04 PM, "jungle Boogie" wrote:
> So it even mentioning the fact that a commit may be crypto signed, it
> may be a security issue?
Yes. See this part of the thread you posted:
http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg13034.html
___
On 2 December 2015 at 09:37, Richard Hipp wrote:
> On 12/2/15, jungle Boogie wrote:
>>
>> Questions: Is there a setting to show if check-ins are signed with the gpg
>> key?
>> How would a visitor of a repo know if a check-in was signed vs. not signed?
>>
>
> Note currently implemented, as nobody
On 2 December 2015 at 10:00, Stephan Beal wrote:
>
> On Dec 2, 2015 6:37 PM, "Richard Hipp" wrote:
>>
>> On 12/2/15, jungle Boogie wrote:
>> >
>> > Questions: Is there a setting to show if check-ins are signed with the
>> > gpg
>> > key?
>> > How would a visitor of a repo know if a check-in was
On Dec 2, 2015 6:37 PM, "Richard Hipp" wrote:
>
> On 12/2/15, jungle Boogie wrote:
> >
> > Questions: Is there a setting to show if check-ins are signed with the
gpg
> > key?
> > How would a visitor of a repo know if a check-in was signed vs. not
signed?
> >
>
> Note currently implemented, as nob
On 12/2/15, jungle Boogie wrote:
>
> Questions: Is there a setting to show if check-ins are signed with the gpg
> key?
> How would a visitor of a repo know if a check-in was signed vs. not signed?
>
Note currently implemented, as nobody in the previous 8.37 years has
ever wanted to see that.
--
Hello All,
As I was updating the concepts.wiki page, I learned that check-ins can
be signed with a gpg key, if you enable this in the repo's settings
page.
I tested this last night and I was prompted for the gpg password, but
when reviewing the timeline, I don't see any indication that I signed
t
On Wednesday, December 02, 2015 5:06 PM, j. van den hoff wrote:
On Wed, 02 Dec 2015 16:56:35 +0100, Andy Gibbs
wrote:
I upgraded after the problem occurred. I was running 1.32 on the server
and 1.32 or 1.33 on the clients. All are running 1.34 now.
which at least means they were all post 1.
On Wed, 02 Dec 2015 16:56:35 +0100, Andy Gibbs
wrote:
I upgraded after the problem occurred. I was running 1.32 on the server
and 1.32 or 1.33 on the clients. All are running 1.34 now.
which at least means they were all post 1.30 (in which version the sync
bug presumably was fixed) so I
On Wednesday, December 02, 2015 4:40 PM, Andy Bradford wrote:
Thus said Andy Gibbs on Tue, 01 Dec 2015 19:14:13 +0100:
I am syncing with a single server, and I have made sure all the
clients have the same fossil version as the server (actually I've
upgraded them all to the latest
Thus said "j. van den hoff" on Wed, 02 Dec 2015 12:43:45 +0100:
> so, if this is correct, the phenomenon -- and thus a bug known since
> yesterday -- seems to persist in 1.34 or is this an invalid
> conclusion?
The OP did not mention what version the Fossil server was running before
Thus said Andy Gibbs on Tue, 01 Dec 2015 19:14:13 +0100:
> I am syncing with a single server, and I have made sure all the
> clients have the same fossil version as the server (actually I've
> upgraded them all to the latest released version). I have even run
> "fossil rebuild" on
On Wed, Dec 02, 2015 at 05:54:06AM -0500, Richard Hipp wrote:
> On 12/2/15, j. van den hoff wrote:
> >
> > thank you. sorry if this has been discussed/explained before: this means,
> > there still is demand for that option? why? is there still a bug out
> > there? because if not, it seems whatever
On Wed, 02 Dec 2015 13:01:42 +0100, Richard Hipp wrote:
On 12/2/15, j. van den hoff wrote:
what harm (in times of sync time/network traffic) would it do to
make `--verily' the default action of sync?
On the Fossil self-hosting repository, "fossil sync" takes 0.535s and
uses 2,961 bytes of
contrary to the `/info/artifact_id' page, where the headline reads
project name / Update of "name_of_wiki_page"
including explicit double quoting of the name of the wiki page, on the
`/whistory/?name=' page it instead reads
project name / History of name_of_wiki_page
which, depending on the
On 12/2/15, j. van den hoff wrote:
> what harm (in times of sync time/network traffic) would it do to
> make `--verily' the default action of sync?
>
On the Fossil self-hosting repository, "fossil sync" takes 0.535s and
uses 2,961 bytes of network traffic. But "fossil sync --verily" takes
4.783s
On Wed, 02 Dec 2015 11:54:06 +0100, Richard Hipp wrote:
On 12/2/15, j. van den hoff wrote:
thank you. sorry if this has been discussed/explained before: this
means,
there still is demand for that option? why? is there still a bug out
there? because if not, it seems whatever `--verily' is
I'm not sure if my previous post went through the mailing-list (format seemed
jumbled up, it could have gotten blocked perhaps, not sure). Since it’s a very
simple fix, I thought I bring it up once more just to get a conformation that
this is at least on someone’s to-do list. I hope I’m not disr
On 12/2/15, j. van den hoff wrote:
>
> thank you. sorry if this has been discussed/explained before: this means,
> there still is demand for that option? why? is there still a bug out
> there? because if not, it seems whatever `--verily' is doing here should
> be done all the time in order to avoi
On Wed, 02 Dec 2015 10:51:08 +0100, Richard Hipp wrote:
On 12/2/15, j. van den hoff wrote:
question: as per changelog of version 1.30 the sync protocol bug causing
the hiccup was fixed for that release? does this mean the `--verily'
flag
is obsolete these days?
The --verily option has b
On 12/2/15, taka <1129-no-rep...@suika.spawn.jp> wrote:
> sorry , I don't know english. I am using google to translate.
Your mother tongue is Japanese, correct?
Judging from the patches you sent, you seem like a good programmer.
Please consider printing the contributors agreement
(https://www.fos
On 12/2/15, j. van den hoff wrote:
>
> question: as per changelog of version 1.30 the sync protocol bug causing
> the hiccup was fixed for that release? does this mean the `--verily' flag
> is obsolete these days?
The --verily option has been added to the command-line docs.
--
D. Richard Hipp
d
On Wed, 02 Dec 2015 08:44:42 +0100, Andy Gibbs
wrote:
Next time this happens, try running:
fossil sync --verily
question: as per changelog of version 1.30 the sync protocol bug causing
the hiccup was fixed for that release? does this mean the `--verily' flag
is obsolete these days
29 matches
Mail list logo
