On Wed, Apr 22, 2015 at 9:50 PM, Andy Bradford amb-fos...@bradfords.org
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,
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, you are
2015-04-23 3:50 GMT+02:00 Andy Bradford amb-fos...@bradfords.org:
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
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
complete
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_sync,
2015-04-19 2:06 GMT+02:00 Andy Bradford amb-fos...@bradfords.org:
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
On 4/18/15, Steve Stefanovich s...@stef.rs 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
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
Let me rephrase - maybe I was a bit ambiguous what I meant.
On pull/update, when fork happens locally, the code would automatically do
what currently happens when someone edits the check-in and puts it on a new
branch.
So on a local repo/check-out, developer sees he's now on (latest leaf
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 s...@stef.rs wrote:
*From: *Ron W
*Sent: *Friday, 17 April 2015 11:04
*To: *Fossil SCM user's discussion
*Reply To: *Fossil SCM user's discussion
Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list,
but just the quote without my reply).
What I meant to say here is that the whole confusion about forks is due to the
fact that they branch out under the same tag. I can't see the case where is
this ever desirable.
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
amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote:
And a fork that ends in
12 matches
Mail list logo
