Thus said Ron W on Thu, 23 Apr 2015 13:13:12 -0400:
> Only for sync, or does it also only report new forks when "fossil
> forks" is run? In my opinion, "fossil forks" should report all forks,
> even previously detected ones.
Yes, only in the context of a sync. E.g. someone makes a commit, y
On Wed, Apr 22, 2015 at 9:50 PM, Andy Bradford
wrote:
> Also, it only warns if it encounters a fork that has not
> previously been seen
Only for sync, or does it also only report new forks when "fossil forks" is
run? In my opinion, "fossil forks" should report all forks, even previously
detect
2015-04-23 3:50 GMT+02:00 Andy Bradford :
> I've altered the change and now it will only check at the end of the
> complete sync. Also, it only warns if it encounters a fork that has not
> previously been seen (ignoring any additional checkins on a fork unless
> they also are new forks).
>
>
Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200:
> Explanation: the current code in "sync-forkwarn" doesn't do the
> fork-check at the end of the sync, it does it at the end of each
> round-trip.
I've altered the change and now it will only check at the end of the
compl
Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200:
> It seems it's not wise at this moment to merge "sync-forkwarn" to
> trunk since false warnings here may be more confusing than that they
> help :-(
You're right. I thought I had moved it sufficiently to the end of the
client_s
2015-04-19 2:06 GMT+02:00 Andy Bradford :
> The only time that fork detection makes sense (if at all) is *after* a
> complete sync in the client.
Just repeated my earlier experiment using "sync-forkwarn" branch, and got:
$ time ./fossil pull -R z.fossil http://www.fossil-scm.org/index.html
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two
trunks?)
On 4/18/15, Steve Stefanovich wrote:
> How about if the fork happens, simply change the tag automatically to
> 'fork-trunk' (i.e. prefix the ex
Thus said Richard Hipp on Sat, 18 Apr 2015 07:50:42 -0400:
> When the artifacts that comprise a fork are received, the server has
> no way of knowing that new artifacts that resolve the fork (either by
> merging or by moving it onto a branch) will not be received within the
> next few milliseco
On 4/18/15, Steve Stefanovich wrote:
> How about if the fork happens, simply change the tag automatically to
> 'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or
> just tag it as 'fork', on commit?
>
When the artifacts that comprise a fork are received, the server has
no way
rk, or to rename the 'fork-' tag to meaningful branch name.
From: Ron W
Sent: Saturday, 18 April 2015 03:00
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two
trunks?)
Hello,
Did you mean for your reply to go only to me? You did not CC the Fossil
list.
On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich wrote:
>
>*From: *Ron W
> *Sent: *Friday, 17 April 2015 11:04
> *To: *Fossil SCM user's discussion
> *Reply To: *Fossil SCM user's discussion
> *Subject: *
From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford
mailto:amb-fos...@bradfords.org>> wrote:
And a fork that ends in being merged is also no l
12 matches
Mail list logo
