[fossil-users] Two trunks?

[Sean Woods]

I am working on a project with a colleague. We're working from
different machines.

When I look at the timeline, it appears that at some point recently the
trunk "diverged." In other words, what was once one stream of updates
(depicted visually with the boxes and lines) is now two lines, each line
with their own boxes.

It's almost like I have a branch, but when I do `fossil branches` I
don't see it there, and they are both tagged with "trunk"

On a recent `fossil update` I got a cryptic message that I don't
remember that alluded to this problem. I Googled and I think I found a
solution by typing - don't quote me - `fossil update trunk`.

Sorry for not writing that down but I thought at the time it fixed the
problem.

How can I "merge" both of these "branches" back into one trunk?

[Richard Hipp]

On 4/3/15, Sean Woods <***@seanwoods.com> wrote:
>
> How can I "merge" both of these "branches" back into one trunk?

"fossil merge" (with no arguments) should merge together all forks of
the branch you are working on.

--
D. Richard Hipp
***@sqlite.org

[Sean Woods]

On Fri, Apr 3, 2015, at 08:25 AM, Richard Hipp wrote:
> On 4/3/15, Sean Woods <***@seanwoods.com> wrote:
> >
> > How can I "merge" both of these "branches" back into one trunk?
>
> "fossil merge" (with no arguments) should merge together all forks of
> the branch you are working on.

Thanks, that fixed it. What is this scenario called? Is it a fork?

[Richard Hipp]

On 4/3/15, Sean Woods <***@seanwoods.com> wrote:
> On Fri, Apr 3, 2015, at 08:25 AM, Richard Hipp wrote:
>> On 4/3/15, Sean Woods <***@seanwoods.com> wrote:
>> >
>> > How can I "merge" both of these "branches" back into one trunk?
>>
>> "fossil merge" (with no arguments) should merge together all forks of
>> the branch you are working on.
>
> Thanks, that fixed it. What is this scenario called? Is it a fork?

Yes. It happens sometimes, when two separate users try to commit at
the same time. See, for example
(https://www.sqlite.org/src/timeline?c=2015-03-21+12:22:16). It is
harmless. All you have to do is merge the fork back together.
--
D. Richard Hipp
***@sqlite.org

[Matt Welland]

On Fri, Apr 3, 2015 at 6:11 AM, Richard Hipp <***@sqlite.org> wrote:

> On 4/3/15, Sean Woods <***@seanwoods.com> wrote:
> > On Fri, Apr 3, 2015, at 08:25 AM, Richard Hipp wrote:
> >> On 4/3/15, Sean Woods <***@seanwoods.com> wrote:
> >> >
> >> > How can I "merge" both of these "branches" back into one trunk?
> >>
> >> "fossil merge" (with no arguments) should merge together all forks of
> >> the branch you are working on.
> >
> > Thanks, that fixed it. What is this scenario called? Is it a fork?
>
> Yes. It happens sometimes, when two separate users try to commit at
> the same time. See, for example
> (https://www.sqlite.org/src/timeline?c=2015-03-21+12:22:16). It is
> harmless. All you have to do is merge the fork back together.
>

Whist a fork may be harmless to a savvy fossil user they are disconcerting,
confusing and problematic for casual users. I request the devs consider
implementing something like the following:

On "fossil update" check if there are other leaves on the current branch,
if so put out a warning and take the user to the tip of the current tine of
the fork. The warning should ideally inform the user that there is a fork
and they can run "fossil merge" followed by "fossil commit" to correct it.

Forks are such a problem for us that one user created an automatic fork
detector script that is called when fossil files are touched. If there is a
fork it sends email to the people who created it asking them to correct it.
If my suggestion above was implemented I think there would be no need for
the detector, however I have considered having the detector automatically
correct the fork. It would be very cool if on update if a fork was detected
it was (optionally) automerged. If the merge had conflicts then it would be
rolled back and the user notified.

Forks in fossil are an artifact of a distributed system trying to pretend
it is centralized. Auto fork correction might help maintain the illusion of
being centralized.


> --
> D. Richard Hipp
> ***@sqlite.org
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[t***@acm.org]

But, what if the two forks become incompatible when merged? For your proposed auto-merge to work, it’s enough that the two forks simply touch (alter) different files.

An auto-merge would obviously work without producing conflicts as neither fork touches files touched by the other fork.

Now, it’s quite possible that either fork which built OK before the merge, no longer does.

The simplest example is to consider as a sole change the addition of a new file in fork 2 which depends on an external function name called xxx(). Fork 1, however, has just changed that function from xxx() to yyy(). Neither fork will compile anymore (assuming the new file is now part of the build process).
It seems that merging can only be done manually, as only a human can know the implications of the changes in the merged files.
Disclaimer: I may have misunderstood your suggestion.

From: Matt Welland
It would be very cool if on update if a fork was detected it was (optionally) automerged. If the merge had conflicts then it would be rolled back and the user notified.

Forks in fossil are an artifact of a distributed system trying to pretend it is centralized. Auto fork correction might help maintain the illusion of being centralized.

[Matt Welland]

On Apr 5, 2015 12:13 PM, <***@acm.org> wrote:
>
> But, what if the two forks become incompatible when merged? For your
proposed auto-merge to work, it’s enough that the two forks simply touch
(alter) different files.
>
> An auto-merge would obviously work without producing conflicts as neither
fork touches files touched by the other fork.
>
> Now, it’s quite possible that either fork which built OK before the
merge, no longer does.
>
> The simplest example is to consider as a sole change the addition of a
new file in fork 2 which depends on an external function name called
xxx(). Fork 1, however, has just changed that function from xxx() to
yyy().
> Neither fork will compile anymore (assuming the new file is now part of
the build process).
>
> It seems that merging can only be done manually, as only a human can know
the implications of the changes in the merged files.
>
> Disclaimer: I may have misunderstood your suggestion.

The auto fork merge is the same as the automatic merge that one of the fork
creators would have experienced if they had done their commit a few minutes
later. They would have gotten a "fossil would fork" message, done "fossil
update" (where the merge happens) and committed. If there is a conflict the
auto fork merge would be canceled obviously.

Anyhow, it is just my $0.02. The poor handling of symlinks and annoying
forks are the two remain things that users gripe about occasionally. Oh,
and the two step rm and mv. In a perfect universe Fossil would have a
non-distributed mode for those of us trying to use it in a corporate
setting and a Unix mode where the constraints of Microsoft Windows could be
ignored :)

>
> From: Matt Welland
> It would be very cool if on update if a fork was detected it was
(optionally) automerged. If the merge had conflicts then it would be rolled
back and the user notified.
> Forks in fossil are an artifact of a distributed system trying to pretend
it is centralized. Auto fork correction might help maintain the illusion of
being centralized.
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Joerg Sonnenberger]

On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote:
> The auto fork merge is the same as the automatic merge that one of the fork
> creators would have experienced if they had done their commit a few minutes
> later. They would have gotten a "fossil would fork" message, done "fossil
> update" (where the merge happens) and committed. If there is a conflict the
> auto fork merge would be canceled obviously.

Note that just because a merge passes automatically doesn't mean it did
the correct thing. Trying to hide it sounds like a recipe for head
aches.

Joerg

[Matt Welland]

On Sun, Apr 5, 2015 at 12:48 PM, Joerg Sonnenberger <***@britannica.bec.de
> wrote:

> On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote:
> > The auto fork merge is the same as the automatic merge that one of the
> fork
> > creators would have experienced if they had done their commit a few
> minutes
> > later. They would have gotten a "fossil would fork" message, done "fossil
> > update" (where the merge happens) and committed. If there is a conflict
> the
> > auto fork merge would be canceled obviously.
>
> Note that just because a merge passes automatically doesn't mean it did
> the correct thing. Trying to hide it sounds like a recipe for head
> aches.
>

If that is a genuine concern then you best turn off the auto merging that
happens every time you do "fossil update". My point above is that the auto
merge is *exactly* the same as the merge that would have happened had one
of the users done a "fossil update" and pulled in the changes made by the
other user.


>
> Joerg
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Joerg Sonnenberger]

On Sun, Apr 05, 2015 at 01:56:06PM -0700, Matt Welland wrote:
> On Sun, Apr 5, 2015 at 12:48 PM, Joerg Sonnenberger <***@britannica.bec.de
> > wrote:
>
> > On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote:
> > > The auto fork merge is the same as the automatic merge that one of the
> > fork
> > > creators would have experienced if they had done their commit a few
> > minutes
> > > later. They would have gotten a "fossil would fork" message, done "fossil
> > > update" (where the merge happens) and committed. If there is a conflict
> > the
> > > auto fork merge would be canceled obviously.
> >
> > Note that just because a merge passes automatically doesn't mean it did
> > the correct thing. Trying to hide it sounds like a recipe for head
> > aches.
> >
>
> If that is a genuine concern then you best turn off the auto merging that
> happens every time you do "fossil update". My point above is that the auto
> merge is *exactly* the same as the merge that would have happened had one
> of the users done a "fossil update" and pulled in the changes made by the
> other user.

The difference is I don't hit commit blindly after that merge. I either
test it by running a build or by reading the diff or whatever.

Joerg

[Matt Welland]

On Sun, Apr 5, 2015 at 2:13 PM, Joerg Sonnenberger <***@britannica.bec.de>
wrote:

> On Sun, Apr 05, 2015 at 01:56:06PM -0700, Matt Welland wrote:
> > On Sun, Apr 5, 2015 at 12:48 PM, Joerg Sonnenberger <
> ***@britannica.bec.de
> > > wrote:
> >
> > > On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote:
> > > > The auto fork merge is the same as the automatic merge that one of
> the
> > > fork
> > > > creators would have experienced if they had done their commit a few
> > > minutes
> > > > later. They would have gotten a "fossil would fork" message, done
> "fossil
> > > > update" (where the merge happens) and committed. If there is a
> conflict
> > > the
> > > > auto fork merge would be canceled obviously.
> > >
> > > Note that just because a merge passes automatically doesn't mean it did
> > > the correct thing. Trying to hide it sounds like a recipe for head
> > > aches.
> > >
> >
> > If that is a genuine concern then you best turn off the auto merging that
> > happens every time you do "fossil update". My point above is that the
> auto
> > merge is *exactly* the same as the merge that would have happened had one
> > of the users done a "fossil update" and pulled in the changes made by the
> > other user.
>
> The difference is I don't hit commit blindly after that merge. I either
> test it by running a build or by reading the diff or whatever.
>

True. Auto-merging of forks would not be appropriate for all. However a
warning would always be appropriate. Even better would be fossil setting an
"I'm committing" flag in the upstream database and blocking other
commits/sync's until the commit is done. I understand (mostly) why git
doesn't have this problem, it makes no pretense about being centralized and
it doesn't allow the fork to happen by blocking the push that is "behind"
the tip. How do the other DSCM systems handle this problem?


> Joerg
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Joerg Sonnenberger]

On Sun, Apr 05, 2015 at 02:59:27PM -0700, Matt Welland wrote:
> I understand (mostly) why git
> doesn't have this problem, it makes no pretense about being centralized and
> it doesn't allow the fork to happen by blocking the push that is "behind"
> the tip. How do the other DSCM systems handle this problem?

It certainly happen with git except you *can't* use temporary forks when
it makes sense. Why people continue to sell lack of forks as a feature
is beyond me. Seriously, merge or die is not a solution. This is not
about pretending to oe centralized either...

Joerg

[Matt Welland]

On Mon, Apr 6, 2015 at 2:53 AM, Joerg Sonnenberger <***@britannica.bec.de>
wrote:

> On Sun, Apr 05, 2015 at 02:59:27PM -0700, Matt Welland wrote:
> > I understand (mostly) why git
> > doesn't have this problem, it makes no pretense about being centralized
> and
> > it doesn't allow the fork to happen by blocking the push that is "behind"
> > the tip. How do the other DSCM systems handle this problem?
>
> It certainly happen with git except you *can't* use temporary forks when
> it makes sense. Why people continue to sell lack of forks as a feature
> is beyond me. Seriously, merge or die is not a solution. This is not
> about pretending to oe centralized either...
>

I thought forks were blocked by the push in git. What scenario can lead to
dual heads in git?

Fossil "pretending" to be centralized is a fantastic feature. For me at
least this *is* about factors that make Fossil simple to learn and use.
Autosync is a plus. Forks are a minus.


>
> Joerg
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[James Moger]

>
> I thought forks were blocked by the push in git. What scenario can lead to
> dual heads in git?
>

By default non-fast-forward pushes (fork in Fossil terms) are blocked.

If you have permission to force a non-fast-forward push then you can
replace/overwrite the current branch "tip/HEAD" pointer. This most likely
means the previous branch "tip/HEAD" pointer is de-referenced (i.e. no
longer accessible through a named branch or tag). These original tip/HEAD
commits are still in the repository but eventually they will be
garbage-collected.

There is no *direct* analog of the Fossil fork feature, although you could
crudely simulate one, I suppose, with server-side refs.

-J

[Ron W]

On Mon, Apr 6, 2015 at 1:05 PM, James Moger <***@gmail.com> wrote:

> There is no *direct* analog of the Fossil fork feature, although you could
> crudely simulate one, I suppose, with server-side refs.
>

Forks are not a feature, just an "unnamed" branch. I use the quotes because
a fork could happen in a named branched, so "unnamed" in that context would
mean not having a new name.

Such forks can occur in any DVCS. Fossil just doesn't block them during a
push/pull/sync operation. (And other DVCSs don't call them forks.)

[Matt Welland]

On Mon, Apr 6, 2015 at 10:05 AM, James Moger <***@gmail.com> wrote:

> I thought forks were blocked by the push in git. What scenario can lead to
>> dual heads in git?
>>
>
> By default non-fast-forward pushes (fork in Fossil terms) are blocked.
>

This is what I thought. So what technical obstacles are there preventing
fossil from adopting this behavior?

One idea: all blobs could be sync'd but blobs would need to be blessed
before becoming part of the official fossil record. Various mechanisms
might exist for such blessing. The anti-fork mechanism: before a node is
blessed it would need to prove that the node it was derived from had no
children unless the branch name was different. Anyone trying to push a
non-blessed blob would get a big fat warning and the onus would be on them
to resolve at their end before trying to sync again.


>
> If you have permission to force a non-fast-forward push then you can
> replace/overwrite the current branch "tip/HEAD" pointer. This most likely
> means the previous branch "tip/HEAD" pointer is de-referenced (i.e. no
> longer accessible through a named branch or tag). These original tip/HEAD
> commits are still in the repository but eventually they will be
> garbage-collected.
>
> There is no *direct* analog of the Fossil fork feature, although you could
> crudely simulate one, I suppose, with server-side refs.
>
> -J
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Ron W]

On Mon, Apr 6, 2015 at 3:48 PM, Matt Welland <***@gmail.com> wrote:

> On Mon, Apr 6, 2015 at 10:05 AM, James Moger <***@gmail.com>
> wrote:
>>
>> By default non-fast-forward pushes (fork in Fossil terms) are blocked.
>>
>
> This is what I thought. So what technical obstacles are there preventing
> fossil from adopting this behavior?
>

I don't think they should be blocked, but the upstream repo should detect
them and warn about them. (which I outlined in an earlier post)


> One idea: all blobs could be sync'd but blobs would need to be blessed
> before becoming part of the official fossil record. Various mechanisms
> might exist for such blessing. The anti-fork mechanism: before a node is
> blessed it would need to prove that the node it was derived from had no
> children unless the branch name was different. Anyone trying to push a
> non-blessed blob would get a big fat warning and the onus would be on them
> to resolve at their end before trying to sync again.
>

I think this is too complicated.

If all development is done on its own branches, and all merges are
coordinated with the affected parties[1], then no "forks" should appear.
But, sometimes a mistake occurs and a "fork" is created. In theory, this is
most likely to occur when merging a branch into another, whether the target
branch is "trunk", a release branch, or another dev branch.

In the past, when I brought this up, somebody claimed that forks are
already obvious by looking at the timeline graph. On the one hand, I agree
that branch maintainers should be watching their branches extremely
carefully AND that committers should always check, repeatedly, that their
commits have not been accidentally orphaned. On the other hand, I know that
developers are people and people make mistakes, including overlooking other
people's mistakes.

[1] By "affect parties" I mean the devs responsible for the target branch.

[Ron W]

On Mon, Apr 6, 2015 at 12:27 PM, Matt Welland <***@gmail.com>
wrote:

> Fossil "pretending" to be centralized is a fantastic feature. For me at
> least this *is* about factors that make Fossil simple to learn and use.
> Autosync is a plus. Forks are a minus.
>

Fossil doesn't pretend to be centralized, unless you consider multiple
checkouts from a single repo to be "pretending to be centralized."

Auto-sync is handy. At least when there isn't a lot to pull.

Auto-sync helps to avoid forks. But the best way to avoid forks is good
communication between contributors. Still, I would like to see the ability
to generate a warning when a Fossil server receives a commit against a
parent that already has a child on the same branch as the just received
commit.

I realize this would require a table to maintain "parent to child"
relations, but Richard (in a thread about Git) asked about being able to
browse the Git timeline in both directions. This suggests that a "parent to
child" already exists in Fossil.

As for how to propagate fork warnings, I suggest that a special tag be
auto-added to the commit (via the existing mechanism for adding tags to
commits). Then when a Fossil server receives any such tags, it prints a
warning, much like it prints information and error messages during a
push/pull/sync operation.

Also, the timeline page could distinctly highlight commits with that
special tag.

[Piotr Orzechowski]

W dniu 07.04.2015 o 18:03, Ron W pisze:
> I don't think they should be blocked, but the upstream repo should
> detect them and warn about them.
If they can happen when two people push to central repository one after
another, then IMHO they should be blocked. Or at least there should be a
possibility to enable/disable some kind of lock mechanism.

W dniu 07.04.2015 o 21:20, Ron W pisze:
> But the best way to avoid forks is good communication between
> contributors.
I agree that good communication is essential, yet I also think the best
way is to make software actively protecting us from making forks by
accident. E.g. block accidental forks on the same branch, but inform
user, that there's a possibility to "--force" push. I'm talking about
the git-like situation mentioned earlier.

Just my $0.02. ;)

--

Pozdrawiam / With best regards,
Orzech

[Piotr Orzechowski]

Now I get it. Thanks for summing up your stance.

Pozdrawiam / With best regards,
Orzech

W dniu 07.04.2015 o 20:17, Ron W pisze:
> I am saying warn. The louder the better.
>
> Naturally, when (a) auto-sync is enabled, and (b) you have
> connectivity with your upstream, then it is POSSIBLE for the commit to
> be "blocked" before the "fork" is committed. BUT, even then, there is
> still a window of vulnerability for 2 (or more) commits to the same
> parent.
>
> These accidental "forks" can and should be detected and warnings
> issued. The louder the better. Everyone committing to the project
> should see the warning. This way, it is less likely to accidentally
> loose an orphaned commit.
>
> Also, an upstream automatically blocking an incoming commit is
> anathema to Fossil's underlying promise to preserve the history. While
> Fossil does have a shunning mechanism, it is driven by explicit human
> intervention. This was designed that way because shunning discards
> information.
>
> Far better to auto-add a special tag (via the existing mechanism for
> adding tags to a commit) and have BOTH warnings displayed when the tag
> is received and timeline provide special highlighting of commits with
> the special tag.

[Andy Bradford]

Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200:

> If they can happen when two people push to central repository one
> after another, then IMHO they should be blocked. Or at least there
> should be a possibility to enable/disable some kind of lock mechanism.

I wonder just what this means? What part of the sync should be blocked?

If I'm not mistaken, Fossil's design prefers to have the fork than not.

> I agree that good communication is essential, yet I also think the
> best way is to make software actively protecting us from making forks
> by accident.

The software already warns users that a fork is imminent. They have the
choice to ignore the warning, or not.

Andy
--
TAI64 timestamp: 4000000055248f46

[Matt Welland]

On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200:
>
> > If they can happen when two people push to central repository one
> > after another, then IMHO they should be blocked. Or at least there
> > should be a possibility to enable/disable some kind of lock mechanism.
>
> I wonder just what this means? What part of the sync should be blocked?
>
> If I'm not mistaken, Fossil's design prefers to have the fork than not.
>
> > I agree that good communication is essential, yet I also think the
> > best way is to make software actively protecting us from making forks
> > by accident.
>
> The software already warns users that a fork is imminent. They have the
> choice to ignore the warning, or not.
>

If only this were true then this discussion would have been over long ago.
Today I got to hear from a team that had a very near serious QA escape due
to an undetected fork. In my opinion Fossil needs to either block a push
that would result in a fork or on any and every operation loudly complain
about any forks lingering in the timeline.

Forks add little value but have a potentially high cost because they can be
so confusing when they happen. To reiterate; An adequate solution would be
on every checkout or update loudly inform the user that there is a fork in
the timeline. A much better solution is to block a push that creates a fork
and inform the user that they need to fix the fork and push again.


>
> Andy
> --
> TAI64 timestamp: 4000000055248f46
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Joerg Sonnenberger]

On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote:
> Forks add little value but have a potentially high cost because they can be
> so confusing when they happen.

I completely disagree on this. Forks add a lot of value and getting
complains for every single action would be extremely annoying.

> To reiterate; An adequate solution would be
> on every checkout or update loudly inform the user that there is a fork in
> the timeline.

Inacceptable for me.

> A much better solution is to block a push that creates a fork
> and inform the user that they need to fix the fork and push again.

This is practically impossible by the nature of the sync protocol.

Joerg

[Martin Gagnon]

On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote:
> On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford
> <[1]amb-***@bradfords.org> wrote:
>
> Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200:
> > If they  can happen  when two  people push  to central  repository one
> > after another,  then IMHO they  should be  blocked. Or at  least there
> > should be a possibility to enable/disable some kind of lock mechanism.
>
> I wonder just what this means? What part of the sync should be blocked?
>
> If I'm not mistaken, Fossil's design prefers to have the fork than not.
> > I agree  that good communication  is essential,  yet I also  think the
> > best way is to make software  actively protecting us from making forks
> > by accident.
>
> The software already warns users that  a fork is imminent. They have the
> choice to ignore the warning, or not.
>
> If only this were true then this discussion would have been over
> long ago. Today I got to hear from a team that had a very near
> serious QA escape due to an undetected fork. In my opinion Fossil
> needs to either block a push that would result in a fork or on any
> and every operation loudly complain about any forks lingering in
> the timeline.

What are you supposed to do when you try to push (or pull) and it get
blocked because of a fork ? If there's a fork, it's too late.

Fork's happens because autosync is off or because some commits was done
while the remote repo was not accessible. When it's not the case, if you
try to commit while you are not in sync with the remote repo, you get a
warning that it might create a FORK and fossil give you chance to do a
*up* before. Then you can figure out if there's some conflict, fix them
if necessary, have a discussion with the other developer if necessary
and commit again.

>
> Forks add little value but have a potentially high cost because
> they can be so confusing when they happen. To reiterate; An
> adequate solution would be on every checkout or update loudly
> inform the user that there is a fork in the timeline. A much better
> solution is to block a push that creates a fork and inform the user
> that they need to fix the fork and push again.

Sometimes, Fork are inevitable. User should understand the concept of a
distributed SCM. Fossil have a nice timeline graph that will show you
the FORK clearly. And the CLI timeline command tell you that there's a
FORK. (by adding *FORK* to the checkin entry):
http://www.fossil-scm.org/index.html/info/62b10da0e1fe8ee5fa8b1af9aa35696079bb48ee?txt=1&ln=1825+1829


May be it could help if "fossil status" or "fossil change" command could
print a warning when the current checkin is part of a fork ?

Regards,

--
Martin G.

[Joerg Sonnenberger]

On Wed, Apr 08, 2015 at 06:55:17AM -0400, Martin Gagnon wrote:
> Sometimes, Fork are inevitable. User should understand the concept of a
> distributed SCM. Fossil have a nice timeline graph that will show you
> the FORK clearly.

Also: fossil leaves --bybranch

Joerg

[Ron W]

On Wed, Apr 8, 2015 at 6:55 AM, Martin Gagnon <***@gmail.com> wrote:

> Fossil have a nice timeline graph that will show you
> the FORK clearly. And the CLI timeline command tell you that there's a
> FORK. (by adding *FORK* to the checkin entry):


I had not encountered this. Nor the "would fork" warning when doing a
commit. Obviously my teammates and I have been following our procedures
well enough to successfully avoid forks.

Question: Does the timeline webpage similarly highlight forks?

Still, I think that auto-adding a special tag to a fork-commit, when
detected, will reduce the cost of emitting warnings to the developers.

(And yes, a configuration option to enable/disable these warnings would be
appropriate.)

[Richard Hipp]

On 4/8/15, Matt Welland <***@gmail.com> wrote:
> Today I got to hear from a team that had a very near serious QA escape due
> to an undetected fork.

Can you provide more detail on this incident so that I can better
understand what Fossil can do to help prevent a recurrence?

--
D. Richard Hipp
***@sqlite.org

[Matt Welland]

On Wed, Apr 8, 2015 at 6:16 AM, Richard Hipp <***@sqlite.org> wrote:

> On 4/8/15, Matt Welland <***@gmail.com> wrote:
> > Today I got to hear from a team that had a very near serious QA escape
> due
> > to an undetected fork.
>
> Can you provide more detail on this incident so that I can better
> understand what Fossil can do to help prevent a recurrence?
>

The problem:

What we are seeing is that forks happen due to simultaneous, partially
overlapping, commits and that neither party involved in the two commits has
any idea that a fork was committed. Fossil sometimes doesn't give the
"multiple descendents" message and so a fork can go undetected in the
timeline. In the case in question a critical change was committed but it
ended up being isolated on the tip of a fork and was lost in the hundreds
of subsequent commits. Luckily a QA check caught the issue but only very
late in the game and there was quite a scramble to recover. Needless to say
this upset quite a few people. The picture below is of a fork that happened
a few days ago in one of our busiest repos where we are seeing as much as
several forks a week. Most devs using that repo are now being vigilant and
fixing the forks as they happen but this is an annoying distraction from
getting real work done. BTW, we've had a few cases of committing of a fork
fix create another fork.

[image: Inline image 1]

A case of fixing a fork creating a new fork:

[image: Inline image 2]

Possible solutions:

1. Aggressive notification of existing forks on running any of; update,
sync, pull, push, commit, checkout, or status.

2. Improved on sync detection during commit (the git model of blocking
forks or similar).

3. Add a setting controlled server mode where the commit process gets a
server-side lock to serialize commits.


> --
> D. Richard Hipp
> ***@sqlite.org
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700:

> What we are seeing is that forks happen due to simultaneous, partially
> overlapping, commits and that neither party involved in the two
> commits has any idea that a fork was committed.

Perhaps this will help:

http://www.fossil-scm.org/index.html/info/6b410f914ef5be53

Probably needs a review and possibly some testing, but it does seem to
work for me:

$ fossil set autosync
autosync (local) off
$ echo $RANDOM > file
$ fossil ci -m forked
New_Version: cd32dadcd1658f99ead152583122df658c9ce458
$ fossil sync
Sync with http://***@remote:8080/
Round-trips: 1 Artifacts sent: 2 received: 0
Server says: ****** WARNING: a fork has occurred ******
Round-trips: 2 Artifacts sent: 2 received: 2
Sync done, sent: 3135 received: 3102 ip: 192.168.50.39

Thanks,

Andy
--
TAI64 timestamp: 400000005525ceb8

[Ron W]

On Wed, Apr 8, 2015 at 8:57 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Perhaps this will help:
>
> http://www.fossil-scm.org/index.html/info/6b410f914ef5be53


Thanks.

I would still like to see a special tag automatically added to a fork
commit when one is detected.

2 reasons:

1. If there is an intermediate repo, the fork might not be detected until
the commit is pushed/pulled further upstream. (Or if there is a "cluster"
of Fossil servers not unlike how fossil-scm.org is redundantly hosted on 3
servers.)

2. The presence of such a tag will serve as a reminder that the fork exists.

[Andy Bradford]

Thus said Ron W on Wed, 08 Apr 2015 22:27:57 -0400:

> 2. The presence of such a tag will serve as a reminder that the fork
> exists.

If the goal is simply to make it easier to find forks, I don't think a
tag is necessary for that.

Fossil can already calculate the presence of forks, so maybe this is
more about just extracting the data from Fossil and displaying it
better?

As for what currently works, there is /leaves which will show all open
leaves. Maybe it could be extended to only show leaves that are forks?

Or something else?

Thanks,

Andy
--
TAI64 timestamp: 400000005525f727

[Matt Welland]

On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700:
>
> > What we are seeing is that forks happen due to simultaneous, partially
> > overlapping, commits and that neither party involved in the two
> > commits has any idea that a fork was committed.
>
> Perhaps this will help:
>
> http://www.fossil-scm.org/index.html/info/6b410f914ef5be53
>
> Probably needs a review and possibly some testing, but it does seem to
> work for me:
>

Thanks Andy, this looks like a serious move in the right direction (at
least from my point of view). Here is what I see:

# Sync with the "server" - yep, get WARNINGS, very nice!
#
***@xena:/tmp/testing$ fossil sync
Sync with file:///home/matt/fossils/blah.fossil
Round-trips: 1 Artifacts sent: 4 received: 0
Server says: ****** WARNING: a fork has occurred ******
Server says: ****** WARNING: a fork has occurred ******
Round-trips: 1 Artifacts sent: 4 received: 0
Sync done, sent: 618 received: 467 ip:

# No messages on update
#
***@xena:/tmp/testing$ fossil up
Autosync: file:///home/matt/fossils/blah.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 267 received: 412 ip:
-------------------------------------------------------------------------------
checkout: 90420628697a12efe24747212c0ecdcb159706a3 2015-04-08 06:13:23
UTC
leaf: open
tags: trunk
comment: Fooblah (user: matt)
changes: None. Already up-to-date

# No message on status
#
***@xena:/tmp/testing$ fossil status
repository: /tmp/testing/../blah.fossil
local-root: /tmp/testing/
config-db: /home/matt/.fossil
checkout: 90420628697a12efe24747212c0ecdcb159706a3 2015-04-08 06:13:23
UTC
parent: 0b2ffb8eedfaaf7cb53a6461dd905411811b829c 2015-04-08 06:12:46
UTC
leaf: open
tags: trunk
comment: Fooblah (user: matt)
***@xena:/tmp/testing$

Would it be possible to detect and warn on update, status and push?

Thanks much for your effort on this.

Matt
-=-

>
> $ fossil set autosync
> autosync (local) off
> $ echo $RANDOM > file
> $ fossil ci -m forked
> New_Version: cd32dadcd1658f99ead152583122df658c9ce458
> $ fossil sync
> Sync with http://***@remote:8080/
> Round-trips: 1 Artifacts sent: 2 received: 0
> Server says: ****** WARNING: a fork has occurred ******
> Round-trips: 2 Artifacts sent: 2 received: 2
> Sync done, sent: 3135 received: 3102 ip: 192.168.50.39
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 400000005525ceb8
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:

> ***@xena:/tmp/testing$ fossil sync
> Sync with file:///home/matt/fossils/blah.fossil
> Round-trips: 1 Artifacts sent: 4 received: 0
> Server says: ****** WARNING: a fork has occurred ******
> Server says: ****** WARNING: a fork has occurred ******

I assume you actually had 2 forks in the content that you were syncing?

> Would it be possible to detect and warn on update, status and push?

push should behave the same as sync already.

I'm not sure about update and status at the moment and just what that
might involve. status will already show multiple children if you are on
a node that has forked, however, if you are at the tip of a fork, that
is a bit trickier to handle (I think).

Also, update will complain if you are on a node that has forked and try
to update without specifying which of the descendants you want to use.

They may require more thought...

Thanks,

Andy
--
TAI64 timestamp: 40000000552602a5

[Matt Welland]

On Wed, Apr 8, 2015 at 9:39 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:
>
> > ***@xena:/tmp/testing$ fossil sync
> > Sync with file:///home/matt/fossils/blah.fossil
> > Round-trips: 1 Artifacts sent: 4 received: 0
> > Server says: ****** WARNING: a fork has occurred ******
> > Server says: ****** WARNING: a fork has occurred ******
>
> I assume you actually had 2 forks in the content that you were syncing?
>

One fork:

fossil leaves
(1) 2015-04-08 06:14:13 [0c744c0023] Borked (user: matt tags: trunk)
(2) 2015-04-08 06:13:23 [9042062869] Fooblah (user: matt tags: trunk)



> > Would it be possible to detect and warn on update, status and push?
>
> push should behave the same as sync already.
>

Ah, I see. The check and message only happens when there is data synced.


> I'm not sure about update and status at the moment and just what that
> might involve. status will already show multiple children if you are on
> a node that has forked, however, if you are at the tip of a fork, that
> is a bit trickier to handle (I think).
>
> Also, update will complain if you are on a node that has forked and try
> to update without specifying which of the descendants you want to use.
>

# Detection of multiple descendants only happens if the forked nodes are
ahead in time
#
***@xena:/tmp/testing$ fossil update
Autosync: file:///home/matt/fossils/blah.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 267 received: 410 ip:
=== 2015-04-08 ===
06:14:13 [0c744c0023] Borked (user: matt tags: trunk)
06:13:23 [9042062869] Fooblah (user: matt tags: trunk)
+++ no more data (2) +++
Multiple descendants

# If you are on the tip of one of the legs of the fork - no warning
#
***@xena:/tmp/testing$ fossil co 0c74
Blahfoo
***@xena:/tmp/testing$ fossil update
Autosync: file:///home/matt/fossils/blah.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 266 received: 412 ip:
-------------------------------------------------------------------------------
checkout: 0c744c002354132468b38afa0e128cd76a024e5e 2015-04-08 06:14:13
UTC
leaf: open
tags: trunk
comment: Borked (user: matt)
changes: None. Already up-to-date

This last one is the worst scenario, the user has a potentially serious
problem and *no* hint that it exists.


> They may require more thought...
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40000000552602a5
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Wed, 08 Apr 2015 22:39:36 -0700:

> > > Server says: ****** WARNING: a fork has occurred ******
> > > Server says: ****** WARNING: a fork has occurred ******
> >
> > I assume you actually had 2 forks in the content that you were
> > syncing?
> >
>
> One fork:

Can you tell me how you got that output then? In my testing, I only get
one warning (because I only fork 1 node).

I do get 2 warnings if I make 2 forks and then sync.

Thanks,

Andy
--
TAI64 timestamp: 40000000552615c3

[Matt Welland]

This is the timeline from that repo. If there is data to sync and you are
in the 0b2ff node then you get the double WARNING.
[image: Inline image 1]

On Wed, Apr 8, 2015 at 11:01 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Matt Welland on Wed, 08 Apr 2015 22:39:36 -0700:
>
> > > > Server says: ****** WARNING: a fork has occurred ******
> > > > Server says: ****** WARNING: a fork has occurred ******
> > >
> > > I assume you actually had 2 forks in the content that you were
> > > syncing?
> > >
> >
> > One fork:
>
> Can you tell me how you got that output then? In my testing, I only get
> one warning (because I only fork 1 node).
>
> I do get 2 warnings if I make 2 forks and then sync.
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40000000552615c3
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:

> Would it be possible to detect and warn on update, status and push?

What about pull??

E.g. if I pull in new content that creates a fork should the pull issue
a warning?

Thanks,

Andy
--
TAI64 timestamp: 400000005526904a

[Matt Welland]

On Thu, Apr 9, 2015 at 7:43 AM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:
>
> > Would it be possible to detect and warn on update, status and push?
>
> What about pull??
>
> E.g. if I pull in new content that creates a fork should the pull issue
> a warning?
>

Yes, I think a warning on seeing a fork in the timeline on pull is
important. Below is my rationale, just another stream-of-conciousness rant,
no loss if readers stop reading here :-)

Forks are, in part, a consequence of Fossils aggressive stance to
preserving data and I can see the arguments against blocking them at sync
time. However forks are potentially disruptive as they can linger silently
in the timeline of a busy project and create problems at a later time. The
compromise solution is to ensure that if there is a fork on the timeline
every effort is made to keep users informed over and over again until it is
resolved.

That said, I still think forks are an unnecessary evil in a highly
connected environment and that ideally Fossil would (optionally) prevent
them from ever happening. For genuine distributed use of course they would
be allowed. How many of the Fossil developers keep autosync on most of the
time? There was an article shared on this list where the author made the
point that the distributed quality of the new generation of SCM tools is
the least needed feature and actually not the key differentiator between
the old and new tools. This is a keen insight. If you didn't autosync then
your data isn't safe and you aren't co-developing to the fullest extent. If
you are using autosync then there is no fundamental technical need for a
fork to happen.

Imagine a use model for Fossil where there is no private database. You can
get very close to this today with multiple users accessing a central
.fossil by using the file:// transport. Out of the box this would be highly
resilient to forks as sqlite3 transactions would prevent overlapping
commits.

Based on my experience with Fossil in a high activity corporate
co-development environment the fork issue is a possible deal breaker. The
expectation of a user in this kind of environment is that if their commit
completes then it is in the timeline and visible to others. It would be
fine if the system told them that they had to resolve something and try to
commit again but for the commit to succeed but be essentially broken is not
tenable.

I think Fossil is fast converging on a near perfect SCM tool for both
distributed small teams and larger teams in a corporate close-coupled
environment. The remaining rough edges are forks, symlink handling and the
behavior of rm and mv (fixed already I think?).

I can't say it often enough, thanks to all who have made Fossil what it is
today!

Thanks,
>
> Andy
> --
> TAI64 timestamp: 400000005526904a
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Thu, 09 Apr 2015 08:25:35 -0700:

> Yes, I think a warning on seeing a fork in the timeline on pull is
> important.

Well, I've added that ability here:

https://www.fossil-scm.org/index.html/info/9d45319345b5fa76

It works quite well, too aggressively, in fact. Basically, on a pull,
any new content that has forks will generate a warning when pulled into
your repository.

This also includes forks that have been merged. E.g. someone commits, it
forks, notices that they forked, merged it and then pushed. Now, when
another comes along and pulls, he will be alerted that a fork has
happened. He'll look at the timeline and see that it was merged.

Is this sufficient? Will forks be rare enough that seeing a warning for
a fork that has also already been merged be a problem? Is it better to
err on the side of caution and just print the warning?

Given the potential for ample warnings, should fork warnings on pull be
opt-in?

Other thoughts?

Thanks,

Andy
--
TAI64 timestamp: 40000000552752d8

[Matt Welland]

I'll test this at work tomorrow but unfortunately I think it will be
problematic. The issue will be warning fatigue due to the false warnings.

Could you increment fork count on a branch with your detection;
count_nonbranch_children(primary_parent_pid_from_rid(rid))>1 and then
detect two nodes, same branch going into one node and decrement the fork
count. If odd => have a fork to report?

On Thu, Apr 9, 2015 at 9:33 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Matt Welland on Thu, 09 Apr 2015 08:25:35 -0700:
>
> > Yes, I think a warning on seeing a fork in the timeline on pull is
> > important.
>
> Well, I've added that ability here:
>
> https://www.fossil-scm.org/index.html/info/9d45319345b5fa76
>
> It works quite well, too aggressively, in fact. Basically, on a pull,
> any new content that has forks will generate a warning when pulled into
> your repository.
>
> This also includes forks that have been merged. E.g. someone commits, it
> forks, notices that they forked, merged it and then pushed. Now, when
> another comes along and pulls, he will be alerted that a fork has
> happened. He'll look at the timeline and see that it was merged.
>
> Is this sufficient? Will forks be rare enough that seeing a warning for
> a fork that has also already been merged be a problem? Is it better to
> err on the side of caution and just print the warning?
>
> Given the potential for ample warnings, should fork warnings on pull be
> opt-in?
>
> Other thoughts?
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40000000552752d8
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Thu, 09 Apr 2015 21:48:56 -0700:

> Could you increment fork count on a branch with your detection;
> count_nonbranch_children(primary_parent_pid_from_rid(rid))>1 and then
> detect two nodes, same branch going into one node and decrement the
> fork count. If odd => have a fork to report?

If I'm not mistaken, this would mean walking down each descendant in one
fork and checking to see if it has ever been merged back into any
descendant of the other fork.

This will need a new query and function than is provided by
count_nonbranch_children... unless one already exists. It seems like a
common ancestor type query e.g. find the last leaf on each fork, and
then see if the common ancestor between the two is the node that forked.
If not, then remove the fork from the count.

Or?

Andy
--
TAI64 timestamp: 4000000055275f01

[Jan Nijtmans]

2015-04-10 7:25 GMT+02:00 Andy Bradford <amb-***@bradfords.org>:

> This will need a new query and function than is provided by
> count_nonbranch_children... unless one already exists. It seems like a
> common ancestor type query e.g. find the last leaf on each fork, and
> then see if the common ancestor between the two is the node that forked.
> If not, then remove the fork from the count.
>

Something like:
<http://fossil-scm.org/index.html/info/32998a20f90bc6a2>
???


demo:
fossil update dg-misc
.....
UPDATE www/wikitheory.wiki

-------------------------------------------------------------------------------
updated-to: 22d9cff0c326374eb75ce228a3ab059b3f3b7ee5 2013-12-19
22:04:43 UTC
leaf: open
tags: dg-misc
comment: Merge from trunk. (user: dg)
changes: 298 files modified.
WARNING: fork detected, please do a "fossil merge"
"fossil undo" is available to undo changes to the working checkout.

The branch "dg-misc" has a fork for more than a year now, no-one will
notice - nor be troubled - until someone starts to work on it. That's when
I would expect a warning.

The same warning could be added to "fossil info", "fossil status" and
may-be some more command. Feedback welcome.

Regards,
Jan Nijtmans

[Matt Welland]

On Fri, Apr 10, 2015 at 1:01 AM, Jan Nijtmans <***@gmail.com>
wrote:

> 2015-04-10 7:25 GMT+02:00 Andy Bradford <amb-***@bradfords.org>:
>
>> This will need a new query and function than is provided by
>> count_nonbranch_children... unless one already exists. It seems like a
>> common ancestor type query e.g. find the last leaf on each fork, and
>> then see if the common ancestor between the two is the node that forked.
>> If not, then remove the fork from the count.
>>
>
> Something like:
> <http://fossil-scm.org/index.html/info/32998a20f90bc6a2>
> ???
>
>
> demo:
> fossil update dg-misc
> .....
> UPDATE www/wikitheory.wiki
>
> -------------------------------------------------------------------------------
> updated-to: 22d9cff0c326374eb75ce228a3ab059b3f3b7ee5 2013-12-19
> 22:04:43 UTC
> leaf: open
> tags: dg-misc
> comment: Merge from trunk. (user: dg)
> changes: 298 files modified.
> WARNING: fork detected, please do a "fossil merge"
> "fossil undo" is available to undo changes to the working checkout.
>
> The branch "dg-misc" has a fork for more than a year now, no-one will
> notice - nor be troubled - until someone starts to work on it. That's when
> I would expect a warning.
>
> The same warning could be added to "fossil info", "fossil status" and
> may-be some more command. Feedback welcome.
>

My preference would be to see a warning for forks on any branch but
certainly same-branch warnings are good. When I tested this change by doing
an update to a node part way along a timeline I get a false warning:

> fossil up d014
Autosync: file:///tmp/mrwellan/delme/blah-bak.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 267 received: 481 ip:
-------------------------------------------------------------------------------
checkout: d014b7e8315a643a9069b1857d4b43b365a0a299 2015-03-02 21:01:09
UTC
leaf: no
tags: trunk
comment: added blah (user: mrwellan)
changes: None. Already up-to-date
WARNING: fork detected, please do a "fossil merge"
> fossil leaves
(1) 2015-03-02 21:22:01 [63b5b3e8be] Added foo/blah* (user: mrwellan
tags:
trunk)

[image: Inline image 1]


>
> Regards,
> Jan Nijtmans
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Andy Bradford]

Thus said Matt Welland on Fri, 10 Apr 2015 08:22:51 -0700:

> My preference would be to see a warning for forks on any branch but
> certainly same-branch warnings are good. When I tested this change by
> doing an update to a node part way along a timeline I get a false
> warning:

Yes, I think it would be nice if pulls gave you 1 warning when you first
receive the fork (what we're trying to arrive at on sync-forkwarn), but
Jan's change makes it possible to have a gentle reminder if you forget
about it and then update to the fork.

Andy
--
TAI64 timestamp: 400000005527f25c

[Jan Nijtmans]

2015-04-10 17:22 GMT+02:00 Matt Welland <***@gmail.com>:

> When I tested this change by doing an update to a node part way along a
> timeline I get a false warning:
>
>
>

Indeed! Fixed now:
<https://www.fossil-scm.org/index.html/info/11b7fa691499c047>

Such a "fork" warning only makes sense on a leaf, indeed.

Ron W wrote:
> One of the advantages of my special "fork" tag idea is that the special
tag can be canceled. Either explicitly with the exiting commands to manage
tags, or
> implicitly in the event the "fork" commit is used as the root of a new
branch.

There is such a tag already, it's "closed". Putting that tag on one of the
fork tips will resolve the fork as well, by
'abandoning' one of its parts.

I think this branch is ready to be merged to trunk. Any objections/remarks ?

Regards,
Jan Nijtmans

[Ron W]

On Fri, Apr 10, 2015 at 12:46 PM, Jan Nijtmans <***@gmail.com>
wrote:

> Ron W wrote:
> > One of the advantages of my special "fork" tag idea is that the special
> tag can be canceled. Either explicitly with the exiting commands to manage
> tags, or
> > implicitly in the event the "fork" commit is used as the root of a new
> branch.
>
> There is such a tag already, it's "closed". Putting that tag on one of the
> fork tips will resolve the fork as well, by
> 'abandoning' one of its parts.
>

That's the reverse of what I was suggesting: The "FORK" would cause the
warning to be displayed. To stop the warnings for that commit, cancel that
tag.

An advantage being that there is less ambiguity about the status of the
fork-commit.

Another advantage of the "FORK" tag is that once it is attached to a
commit, finding all outstanding forks becomes just a tag search.

[Andy Bradford]

Thus said Ron W on Fri, 10 Apr 2015 12:57:29 -0400:

> Another advantage of the "FORK" tag is that once it is attached to a
> commit, finding all outstanding forks becomes just a tag search.

Once Fossil warns the user about forks, and can efficiently detect them,
cannot the user put a tag on it for later?

I'm still not sure why Fossil should be adding automatic tags like this.
Seems that if Fossil can use SQL to determine forks, all that is missing
is a page that helps users identify potential forks in their timeline.

The command-line ``fossil timeline'' will print *FORK* when it
encounters a fork in the timeline already. I think we just need to
expose it a little more in other areas.

Just my $0.02.

Thanks,

Andy
--
TAI64 timestamp: 4000000055280805

[Matt Welland]

I myself prefer not to see additional info like this that can be derived
from querying the db added to the timeline. I'm keen to see the work that
Andy and Jan have done make it into the trunk and will test it ASAP.

Just my $0.02 :)

On Fri, Apr 10, 2015 at 10:27 AM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Ron W on Fri, 10 Apr 2015 12:57:29 -0400:
>
> > Another advantage of the "FORK" tag is that once it is attached to a
> > commit, finding all outstanding forks becomes just a tag search.
>
> Once Fossil warns the user about forks, and can efficiently detect them,
> cannot the user put a tag on it for later?
>
> I'm still not sure why Fossil should be adding automatic tags like this.
> Seems that if Fossil can use SQL to determine forks, all that is missing
> is a page that helps users identify potential forks in their timeline.
>
> The command-line ``fossil timeline'' will print *FORK* when it
> encounters a fork in the timeline already. I think we just need to
> expose it a little more in other areas.
>
> Just my $0.02.
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 4000000055280805
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Ron W]

On Fri, Apr 10, 2015 at 2:16 PM, Matt Welland <***@gmail.com>
wrote:

> I myself prefer not to see additional info like this that can be derived
> from querying the db added to the timeline. I'm keen to see the work that
> Andy and Jan have done make it into the trunk and will test it ASAP.
>

There is a difference between "derived from querying the db" and just
querying the db. If a FORK tag is auto-added, it can be queried just like
any other tag.

[Andy Bradford]

Thus said Jan Nijtmans on Fri, 10 Apr 2015 18:46:27 +0200:

> There is such a tag already, it's "closed". Putting that tag on one of
> the fork tips will resolve the fork as well, by 'abandoning' one of
> its parts.

I ``closed'' one leaf that was causing a fork and when I update to that
leaf, I still get the warning.

I'm not sure that's a bad thing, but it doesn't seem to fit the
description above.

If I update to the other fork, I don't get the warning (it's clearly
ignoring the leaf that is closed).

Other than this, it seems ready to merge.

Thanks,

Andy
--
TAI64 timestamp: 4000000055280734

[Andy Bradford]

Thus said Matt Welland on Fri, 10 Apr 2015 11:16:32 -0700:

> I myself prefer not to see additional info like this that can be
> derived from querying the db added to the timeline. I'm keen to see
> the work that Andy and Jan have done make it into the trunk and will
> test it ASAP.

It's not yet merged to trunk, but I have borrowed from Jan's work and
merged into the sync-forkwarn branch for what I think will provide a
better experience (e.g. almost no false positives).

I say almost none, because it's possible that if your sync is cut-off,
you may end up with a node that has a fork which has already been
merged, but for which you didn't receive the correction (what are the
odds?).

But on the whole, I think this is much more reliable:

https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6

Thanks,

Andy
--
TAI64 timestamp: 40000000552b46a9

[Jan Nijtmans]

2015-04-13 6:31 GMT+02:00 Andy Bradford <amb-***@bradfords.org>:

> It's not yet merged to trunk, but I have borrowed from Jan's work and
> merged into the sync-forkwarn branch for what I think will provide a
> better experience (e.g. almost no false positives).
>
> I say almost none, because it's possible that if your sync is cut-off,
> you may end up with a node that has a fork which has already been
> merged, but for which you didn't receive the correction (what are the
> odds?).
>
> But on the whole, I think this is much more reliable:
>
> https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6
>

Just two remarks:
- I'm not sure if I want to be reminded when someone else causes a
fork on a branch I'm not working on. But if there is such a desire
with other people, I'm not principally against it.
- The function primary_parent_pid_from_rid() is not used anywhere.

I went ahead, so the fork detection for fossil update/status/info
(I din't hear anyone against that) will receive some more
wide-spread testing. I'll do more testing on the "sync-forkwarn".

Any more feedback welcome!

Regards,
Jan Nijtmans

[Matt Welland]

On Mon, Apr 13, 2015 at 1:59 AM, Jan Nijtmans <***@gmail.com>
wrote:

> 2015-04-13 6:31 GMT+02:00 Andy Bradford <amb-***@bradfords.org>:
>
>> It's not yet merged to trunk, but I have borrowed from Jan's work and
>> merged into the sync-forkwarn branch for what I think will provide a
>> better experience (e.g. almost no false positives).
>>
>> I say almost none, because it's possible that if your sync is cut-off,
>> you may end up with a node that has a fork which has already been
>> merged, but for which you didn't receive the correction (what are the
>> odds?).
>>
>> But on the whole, I think this is much more reliable:
>>
>> https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6
>>
>
On a branch with a fork if I do "fossil up <someoldnode>" I do not get a
warning about the fork.
fossil status => no warning (expected I think from the conversation)
fossil up branchname => get warning
fossil up <othertip-nodeid> => get warning

Pretty nice. I'd have liked fossil status to report forks but as is this
covers most scenarios.


>
> Just two remarks:
> - I'm not sure if I want to be reminded when someone else causes a
> fork on a branch I'm not working on. But if there is such a desire
> with other people, I'm not principally against it.
> - The function primary_parent_pid_from_rid() is not used anywhere.
>
> I went ahead, so the fork detection for fossil update/status/info
> (I din't hear anyone against that) will receive some more
> wide-spread testing. I'll do more testing on the "sync-forkwarn".
>
> Any more feedback welcome!
>
> Regards,
> Jan Nijtmans
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Jan Nijtmans]

2015-04-14 5:46 GMT+02:00 Andy Bradford <amb-***@bradfords.org>:
> Thanks. One thing to note is that I extended the function
> fossil_find_nearest_fork to be able to work without checking the vmerge
> table which is only available for a repository that is open, however,
> fossil sync may actually be run with -R and there may or may not be a
> vmerge table for that.
>
> Perhaps a better option would be to check for the vmerge table if it
> exists and use it, otherwise don't?

I really don't know what would be best here. My only concern is the additional
time this check takes when syncing. So, let's do a little stress-test.
First create
an empty repository in which we are going to pull the complete content of
the fossil self-hosting repository:
$ fossil new z.fossil
...
$ fossil sqlite -R z.fossil
SQLite version 3.8.9 2015-04-08 12:16:33
Enter ".help" for usage hints.
sqlite> update config set
value='CE59BB9F186226D80E49D1FA2DB29F935CCA0333' where
name='project-code';
sqlite> .exit

So, now we can pull the full content:
$ time fossil pull -R z.fossil http://www.fossil-scm.org/index.html
Round-trips: 344 Artifacts sent: 0 received: 30646
Pull done, sent: 1124980 received: 19585724 ip: 67.18.92.124

real 27m21.480s
user 1m18.421s
sys 0m25.240s

Now, repeat the same steps but using fossil compiled from the
"sync-forkwarn" branch:
Round-trips: 362 Artifacts sent: 0 received: 30646
Pull done, sent: 1186697 received: 19659128 ip: 67.18.92.124
***** WARNING: a fork has occurred *****

real 25m49.494s
user 1m18.780s
sys 0m27.752s

Conclusion:
1) The fork-detection during sync works, the fork in the "dg-misc"
branch is detected correctly.
2) The additional time spent in the fork-detection is negligible.

The fork in "dg-misc" is already there for more than a year without causing
any harm. I really doubt the value of this WARNING, since there
is no clue at all where the fork is. Most people won't have any idea
why the warning was there, and what to do about it. I guess it will
only cause more confusion than that it helps people getting the
repository fork-free.

Maybe more valuable would be to adapt the /leaves page, so people
searching forks have an easy way to do so.

Just my 2c

Regards,
Jan Nijtmans

[Jan Nijtmans]

2015-04-14 21:11 GMT+02:00 Andy Bradford:
> Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
>> Maybe more valuable would be to adapt the /leaves page, so people
>> searching forks have an easy way to do so.
>
> I proposed this very thing a few days ago, and I think that this is
> something that should be done regardless of the discussion on sync
> warnings.

There's a "fossil forks" command on trunk now:

$ ./fossil forks --bybranch
*** ben-minorchanges ***
(1) 2011-09-07 08:12:27 [27a4518e13c41e] Make it easier to use
Events as quick notes: Display the title just above the text
on Event pages. If there's no title in the wiki text, use the
comment as a title. (user: ben tags: ben-minorchanges)
(2) 2011-08-23 08:37:23 [0f0a94730c0ae9] Cache values of
versionable settings read from files. (user: ben tags: ben-
minorchanges)
*** dg-misc ***
(3) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
dg tags: dg-misc)
(4) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
dg tags: dg-misc)
*** msw-docco ***
(5) 2012-04-19 14:34:59 [626a317e5cea1f] Catch up w/ trunk &
document --case-sensitive option in the add and addremove
commands. (user: martin.weber tags: msw-docco)
(6) 2012-02-10 18:02:40 [587dd57fe194af] climb up the trunk. From
up here, clarify wording of the "building and installing"
wiki page: you don't need to log in to get the source code for
released versions of fossil, the download page will have
a shiny source package for you to fetch. (user: martin.weber
tags: msw-docco)
*** side-by-side-edit ***
(7) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
the text area small so it will always fit in the column.
After page loaded enlarge the text area with Javascript. But
leave a little room (40px) as a margin between the two
columns. This insurers that side by side always succeeds.
(user: renez tags: side-by-side-edit)
(8) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
changes so that the branches can be more easily compared.
(user: drh tags: side-by-side-edit)


I used this to close some trivial ones (which were already merged to
trunk), those are the 4 left at this
moment. None of them are harmfull, they all lived happily in the
fossil repo for more than a year.

Regards,
Jan Nijtmans

[Matt Welland]

On Thu, Apr 16, 2015 at 1:38 AM, Jan Nijtmans <***@gmail.com>
wrote:

> 2015-04-14 21:11 GMT+02:00 Andy Bradford:
> > Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
> >> Maybe more valuable would be to adapt the /leaves page, so people
> >> searching forks have an easy way to do so.
> >
> > I proposed this very thing a few days ago, and I think that this is
> > something that should be done regardless of the discussion on sync
> > warnings.
>
> There's a "fossil forks" command on trunk now:
>
> $ ./fossil forks --bybranch
> *** ben-minorchanges ***
> (1) 2011-09-07 08:12:27 [27a4518e13c41e] Make it easier to use
> Events as quick notes: Display the title just above the text
> on Event pages. If there's no title in the wiki text, use the
> comment as a title. (user: ben tags: ben-minorchanges)
> (2) 2011-08-23 08:37:23 [0f0a94730c0ae9] Cache values of
> versionable settings read from files. (user: ben tags: ben-
> minorchanges)
> *** dg-misc ***
> (3) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
> dg tags: dg-misc)
> (4) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
> dg tags: dg-misc)
> *** msw-docco ***
> (5) 2012-04-19 14:34:59 [626a317e5cea1f] Catch up w/ trunk &
> document --case-sensitive option in the add and addremove
> commands. (user: martin.weber tags: msw-docco)
> (6) 2012-02-10 18:02:40 [587dd57fe194af] climb up the trunk. From
> up here, clarify wording of the "building and installing"
> wiki page: you don't need to log in to get the source code for
> released versions of fossil, the download page will have
> a shiny source package for you to fetch. (user: martin.weber
> tags: msw-docco)
> *** side-by-side-edit ***
> (7) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
> the text area small so it will always fit in the column.
> After page loaded enlarge the text area with Javascript. But
> leave a little room (40px) as a margin between the two
> columns. This insurers that side by side always succeeds.
> (user: renez tags: side-by-side-edit)
> (8) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
> changes so that the branches can be more easily compared.
> (user: drh tags: side-by-side-edit)
>
>
> I used this to close some trivial ones (which were already merged to
> trunk), those are the 4 left at this
> moment. None of them are harmfull, they all lived happily in the
> fossil repo for more than a year.
>

I'm confused by this. If the fork was merged to trunk it is no longer a
fork and should not be detected. Can you elaborate?


>
> Regards,
> Jan Nijtmans
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Jan Nijtmans]

2015-04-16 13:44 GMT+02:00 Matt Welland <***@gmail.com>:
> I'm confused by this. If the fork was merged to trunk it is no longer a fork
> and should not be detected. Can you elaborate?

In fossil it is possible to merge a branch to trunk, but leave the
branch open. It could have been a partial merge, fossil has no way
to know that, until the user explicitly closes the branch. Therefore,
such a branch needs to be included in the fork-detection.

Down to two:
$ fossil forks --bybranch
*** dg-misc ***
(1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
dg tags: dg-misc)
(2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
dg tags: dg-misc)
*** side-by-side-edit ***
(3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
the text area small so it will always fit in the column.
After page loaded enlarge the text area with Javascript. But
leave a little room (40px) as a margin between the two
columns. This insurers that side by side always succeeds.
(user: renez tags: side-by-side-edit)
(4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
changes so that the branches can be more easily compared.
(user: drh tags: side-by-side-edit)

Analysing those last two, it's not difficult to see what happened:
<https://fossil-scm.org/index.html/timeline?n=100&r=dg-misc>
<https://fossil-scm.org/index.html/timeline?n=100&r=side-by-side-edit>

The oldest commits were nothing more than merging trunk changes into
the branch. But later the user forgot about that (without seeing the
warning). So it's safe to assume that the older of the two commits
will not be continued upon, and can be closed. Done now.

The fossil self-hosting repository is fork-free now (FWIW) !
Anyway, we still can test the fork-detection on SQLite ;-)
$ fossil forks --bybranch
*** branch-3.7.16 ***
(1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user:
drh tags: release, version-3.7.16.2, branch-3.7.16)
(2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process
tester to the last released version. (user: mistachkin
tags: branch-3.7.16)
*** mistake ***
(3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX,
REINDEX and VACUUM statements by taking better advantage of
the fact that index keys are being inserted into b-trees in
sorted order. (user: dan tags: mistake)
(4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because
this commit contains a typo causing a test to fail.
Was: Add an extra test to further verify that the FTS
notindexed option is working properly. (user: dan tags: mistake)


Hope this helps,
Jan Nijtmans

[Matt Welland]

On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans <***@gmail.com>
wrote:

> 2015-04-16 13:44 GMT+02:00 Matt Welland <***@gmail.com>:
> > I'm confused by this. If the fork was merged to trunk it is no longer a
> fork
> > and should not be detected. Can you elaborate?
>
> In fossil it is possible to merge a branch to trunk, but leave the
> branch open. It could have been a partial merge, fossil has no way
> to know that, until the user explicitly closes the branch. Therefore,
> such a branch needs to be included in the fork-detection.
>

Since these are effectively forks that have been resolved by merging is it
possible to detect them as such and not report them?


>
> Down to two:
> $ fossil forks --bybranch
> *** dg-misc ***
> (1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
> dg tags: dg-misc)
> (2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
> dg tags: dg-misc)
> *** side-by-side-edit ***
> (3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
> the text area small so it will always fit in the column.
> After page loaded enlarge the text area with Javascript. But
> leave a little room (40px) as a margin between the two
> columns. This insurers that side by side always succeeds.
> (user: renez tags: side-by-side-edit)
> (4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
> changes so that the branches can be more easily compared.
> (user: drh tags: side-by-side-edit)
>
> Analysing those last two, it's not difficult to see what happened:
> <https://fossil-scm.org/index.html/timeline?n=100&r=dg-misc>
> <https://fossil-scm.org/index.html/timeline?n=100&r=side-by-side-edit>
>
> The oldest commits were nothing more than merging trunk changes into
> the branch. But later the user forgot about that (without seeing the
> warning). So it's safe to assume that the older of the two commits
> will not be continued upon, and can be closed. Done now.
>
> The fossil self-hosting repository is fork-free now (FWIW) !
> Anyway, we still can test the fork-detection on SQLite ;-)
> $ fossil forks --bybranch
> *** branch-3.7.16 ***
> (1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user:
> drh tags: release, version-3.7.16.2, branch-3.7.16)
> (2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process
> tester to the last released version. (user: mistachkin
> tags: branch-3.7.16)
> *** mistake ***
> (3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX,
> REINDEX and VACUUM statements by taking better advantage of
> the fact that index keys are being inserted into b-trees in
> sorted order. (user: dan tags: mistake)
> (4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because
> this commit contains a typo causing a test to fail.
> Was: Add an extra test to further verify that the FTS
> notindexed option is working properly. (user: dan tags: mistake)
>
>
> Hope this helps,
> Jan Nijtmans
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Ron W]

On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland <***@gmail.com>
wrote:

>
>
> On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans <***@gmail.com>
> wrote:
>
>> 2015-04-16 13:44 GMT+02:00 Matt Welland <***@gmail.com>:
>> > I'm confused by this. If the fork was merged to trunk it is no longer a
>> fork
>> > and should not be detected. Can you elaborate?
>>
>> In fossil it is possible to merge a branch to trunk, but leave the
>> branch open. It could have been a partial merge, fossil has no way
>> to know that, until the user explicitly closes the branch. Therefore,
>> such a branch needs to be included in the fork-detection.
>>
>
> Since these are effectively forks that have been resolved by merging is it
> possible to detect them as such and not report them?
>
>
>>
>> Down to two:
>> $ fossil forks --bybranch
>> *** dg-misc ***
>> (1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
>> dg tags: dg-misc)
>> (2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
>> dg tags: dg-misc)
>> *** side-by-side-edit ***
>> (3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
>> the text area small so it will always fit in the column.
>> After page loaded enlarge the text area with Javascript. But
>> leave a little room (40px) as a margin between the two
>> columns. This insurers that side by side always succeeds.
>> (user: renez tags: side-by-side-edit)
>> (4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
>> changes so that the branches can be more easily compared.
>> (user: drh tags: side-by-side-edit)
>>
>> Analysing those last two, it's not difficult to see what happened:
>> <https://fossil-scm.org/index.html/timeline?n=100&r=dg-misc>
>> <https://fossil-scm.org/index.html/timeline?n=100&r=side-by-side-edit
>> >
>>
>> The oldest commits were nothing more than merging trunk changes into
>> the branch. But later the user forgot about that (without seeing the
>> warning). So it's safe to assume that the older of the two commits
>> will not be continued upon, and can be closed. Done now.
>>
>> The fossil self-hosting repository is fork-free now (FWIW) !
>> Anyway, we still can test the fork-detection on SQLite ;-)
>> $ fossil forks --bybranch
>> *** branch-3.7.16 ***
>> (1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user:
>> drh tags: release, version-3.7.16.2, branch-3.7.16)
>> (2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process
>> tester to the last released version. (user: mistachkin
>> tags: branch-3.7.16)
>> *** mistake ***
>> (3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX,
>> REINDEX and VACUUM statements by taking better advantage of
>> the fact that index keys are being inserted into b-trees in
>> sorted order. (user: dan tags: mistake)
>> (4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because
>> this commit contains a typo causing a test to fail.
>> Was: Add an extra test to further verify that the FTS
>> notindexed option is working properly. (user: dan tags: mistake)
>>
>>
>> Hope this helps,
>> Jan Nijtmans
>> _______________________________________________
>> fossil-users mailing list
>> fossil-***@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Ron W]

On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland <***@gmail.com>
wrote:

> Since these are effectively forks that have been resolved by merging is it
> possible to detect them as such and not report them?
>

I think they probably could be reported as "merged forks", but I'm not sure
that adds value. What if someone assumes that whomever merged the fork's
content had simply forgotten to either close the fork or otherwise
"resolve" it?

Absent a comment or other explicit indicator of intent, any fork, merged or
not, should be carefully reviewed and its status explicitly denoted.

[Matt Welland]

On Thu, Apr 16, 2015 at 1:22 PM, Ron W <***@gmail.com> wrote:

> On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland <***@gmail.com>
> wrote:
>
>> Since these are effectively forks that have been resolved by merging is
>> it possible to detect them as such and not report them?
>>
>
> I think they probably could be reported as "merged forks", but I'm not
> sure that adds value. What if someone assumes that whomever merged the
> fork's content had simply forgotten to either close the fork or otherwise
> "resolve" it?
>

I think merging a fork resolves then it and it is no longer a fork. Only
open forks represent potentially orphaned changes. Maybe we need better
terminology. I don't call a merged fork a fork. The word "fork" implies
divergence to me (consistent with the usage in another thread about project
forks). If xemacs and emacs projects merge together they are no longer
forked. I suppose they were previously forked but if I'm an emacs
aficionado I don't care about a fork in the past that has been merged.

By my working definition of the word "fork" reporting a fork that was
merged back to the origin branch is a false error.


> Absent a comment or other explicit indicator of intent, any fork, merged
> or not, should be carefully reviewed and its status explicitly denoted.
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Andy Bradford]

Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200:

> - I'm not sure if I want to be reminded when someone else causes a
> fork on a branch I'm not working on. But if there is such a desire
> with other people, I'm not principally against it.

I asked a question a few days ago about whether this kind of
notification should be opt-in (e.g. a setting that is disabled by
default). I never got feedback on it.

> - The function primary_parent_pid_from_rid() is not used anywhere.

Yes, thank you, I forgot to remove it. It became obsolete after using
fossil_find_nearest_fork was written. :-)

Thanks,

Andy
--
TAI64 timestamp: 40000000552bdff7

[Matt Welland]

Does fork notification really warrant another setting? If there is a fork
on some other branch either fix by merging it or rename one of the legs.
There is no sensible need for a fork to exist in a timeline that I can
think of. Forks are rare in most repos (the intensely busy repos I deal
with seem to be the exception). Given these points surely a fork warning is
a harmless or at worst mildly annoying rare occurrence so please make it
the default behavior or make it non-configurable.

On Mon, Apr 13, 2015 at 8:25 AM, Andy Bradford <amb-***@bradfords.org>
wrote:

> Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200:
>
> > - I'm not sure if I want to be reminded when someone else causes a
> > fork on a branch I'm not working on. But if there is such a desire
> > with other people, I'm not principally against it.
>
> I asked a question a few days ago about whether this kind of
> notification should be opt-in (e.g. a setting that is disabled by
> default). I never got feedback on it.
>
> > - The function primary_parent_pid_from_rid() is not used anywhere.
>
> Yes, thank you, I forgot to remove it. It became obsolete after using
> fossil_find_nearest_fork was written. :-)
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40000000552bdff7
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

[Andy Bradford]

Thus said Matt Welland on Mon, 13 Apr 2015 15:57:53 -0700:

> Does fork notification really warrant another setting?

Generally, I would prefer to avoid another setting, but wanted to make
sure.

> Forks are rare in most repos (the intensely busy repos I deal with
> seem to be the exception). Given these points surely a fork warning is
> a harmless or at worst mildly annoying rare occurrence so please make
> it the default behavior or make it non-configurable.

I agree that for repositories where forks are rare, it is a minor
nuisance at worst. It may be helpful in most cases if the fork didn't
get noticed for a while, but it may also alert people who are
disinterested (e.g. working on a branch in which there are no forks) if
the fork isn't merged before they pull it in. I suppose notifying the
committer that a fork has occurred during their sync operation may cause
the fork to be merged more quickly thus minimizing the number of folks
who will actually see a warning.

If my SQL is correct, there have been 74 forks in Fossil since 2007. It
would seem that many of the early forks were due to either not having
branching, or using the fork as the branch. Later commits to Fossil seem
to involve fewer forks and more branches.

This year so far has only seen 1 unintentional fork:

http://www.fossil-scm.org/index.html/timeline?n=25&y=all&v=0&c=2015-03-30+20%3A34%3A39

It would seem that the frequency of forks is low for Fossil. I suppose
worst case, we merge sync-forkwarn to trunk and see how it fares prior
to the next release.

Andy
--
TAI64 timestamp: 40000000552c8ccd

[Andy Bradford]

Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200:

> I'll do more testing on the "sync-forkwarn".

Thanks. One thing to note is that I extended the function
fossil_find_nearest_fork to be able to work without checking the vmerge
table which is only available for a repository that is open, however,
fossil sync may actually be run with -R and there may or may not be a
vmerge table for that.

Perhaps a better option would be to check for the vmerge table if it
exists and use it, otherwise don't?

Thanks,

Andy
--
TAI64 timestamp: 40000000552c8dca

[Andy Bradford]

Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:

> 2) The additional time spent in the fork-detection is negligible.

I too was concerned about the additional time that might be spent
checking and whether or not it would be worth the extra time. Thanks for
taking the time to profile it a bit to discover its impact.

> The fork in "dg-misc" is already there for more than a year without
> causing any harm. I really doubt the value of this WARNING, since
> there is no clue at all where the fork is. Most people won't have any
> idea why the warning was there, and what to do about it.

This is not how it works though. :-) Normal Fossil use does
not recommend making a new empty Fossil repository, changing the
project-code and then pulling the Fossil repository (clever way to
profile by the way). Recommended use is to begin a new clone with
``fossil clone.''

And if they are using clone, they will not see:

> ***** WARNING: a fork has occurred *****

Because the code that prints it has a condition:

if( (syncFlags & SYNC_CLONE)==0 && g.forkSeen ){

So, only after a repository has been cloned and there are new unresolved
forks will this warning be present during a sync. Nobody will know about
the fork in dg-misc after cloning unless they update to that branch, or
new code is committed that forks again at that same node.


> Maybe more valuable would be to adapt the /leaves page, so people
> searching forks have an easy way to do so.

I proposed this very thing a few days ago, and I think that this is
something that should be done regardless of the discussion on sync
warnings.


Now, regarding the rest of the discussion...

Clearly the primary concern is about the additional time people, some of
whom are potentially uninterested parties, will spend tracking down
forks. And perhaps also there is concern that the warning will become
the ``boy who cried wolf'' of Fossil causing many people to run to the
village to look for forks, but eventually resulting in a user base
wielding instead pitchforks ready to burn someone at the stake, because
the forks had already been merged.

This seems like something we cannot know a priori: will this negatively
impact all of us, or will it have negligible impact because it will
assist speedy handling of forks causing them to be handled before anyone
gets the warning?

What if the fork is intentially left unhandled? This means that all
parties will be alerted to the fact that there exists a fork because it
was intentionally left a fork. Is this acceptable? Will this be
confusing for anonymous or other users of a given repository when the
developers intentionally leave a fork and they get a warning about it
the next time they sync?

Forks are so rare in Fossil proper, that it's hard to use it as a
test-bed. There has only been 1 so far this year.

Feedback?

Thanks,

Andy
--
TAI64 timestamp: 40000000552d667a

[Ron W]

On Tue, Apr 14, 2015 at 3:11 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> What if the fork is intentially left unhandled? This means that all
> parties will be alerted to the fact that there exists a fork because it
> was intentionally left a fork. Is this acceptable? Will this be
> confusing for anonymous or other users of a given repository when the
> developers intentionally leave a fork and they get a warning about it
> the next time they sync?
>

Off hand, the only reason I can think for intentionally leaving the fork a
fork would be so the warning continues to be displayed. Otherwise, I would
expect the devs to give it a proper, new branch name.

I don't think this is something we can do anything about.

[Matt Welland]

In short, if there are no false positive notifications on forks the fallout
from this change should really be very minimal and the benefits for those
who need it are substantial.

The long-winded response:

Mark Twain said it well, “I've lived through some terrible things in my
life, some of which actually happened.” For a very small number of fossil
users switching to the fork-alert code the experience will go something
like this: "oh, I have a fork, I had no idea.", ten minutes later they will
have found the fork, smiled at how now they now understand why they had to
implement such-and-such a feature twice, closed or merged the fork and they
move on.

For folks working in intensely busy repos who have been burned before by
forks the experience will be a little better, they will now get more timely
alerts when a fork happens. This is far from ideal (the forks should not be
happening IMHO) but at least they won't sit on potential timebombs for
extended periods of time as they can fix the forks in near real time.

-=-
Matt

On Tue, Apr 14, 2015 at 12:27 PM, Ron W <***@gmail.com> wrote:

> On Tue, Apr 14, 2015 at 3:11 PM, Andy Bradford <amb-***@bradfords.org>
> wrote:
>
>> What if the fork is intentially left unhandled? This means that all
>> parties will be alerted to the fact that there exists a fork because it
>> was intentionally left a fork. Is this acceptable? Will this be
>> confusing for anonymous or other users of a given repository when the
>> developers intentionally leave a fork and they get a warning about it
>> the next time they sync?
>>
>
> Off hand, the only reason I can think for intentionally leaving the fork a
> fork would be so the warning continues to be displayed. Otherwise, I would
> expect the devs to give it a proper, new branch name.
>
> I don't think this is something we can do anything about.
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Andy Bradford]

Thus said Jan Nijtmans on Thu, 16 Apr 2015 10:38:17 +0200:

> There's a "fossil forks" command on trunk now:

Thank you. Looks great.

Oops...

$ ./fossil new /tmp/new.fossil > /dev/null
$ ./fossil forks -R /tmp/new.fossil
SQLITE_ERROR: no such table: vmerge
./fossil: no such table: vmerge
SELECT leaf.rid FROM leaf, event WHERE leaf.rid=event.objid AND leaf.rid!=1 AND leaf.rid NOT IN (SELECT merge FROM vmerge) AND NOT EXISTS(SELECT 1 FROM tagxref WHERE rid=leaf.rid AND tagid=9 AND tagtype>0) AND (SELECT value FROM tagxref WHERE tagid=8 AND rid=1 AND tagtype>0) = (SELECT value FROM tagxref WHERE tagid=8 AND rid=leaf.rid AND tagtype>0) ORDER BY event.mtime DESC LIMIT 1

I made changes to handle this in sync-forkwarn branch.

Maybe should have a vote on sync-forkwarn?

Thanks,

Andy
--
TAI64 timestamp: 4000000055300619

[Andy Bradford]

Thus said Matt Welland on Thu, 16 Apr 2015 15:55:47 -0700:

> I think merging a fork resolves then it and it is no longer a fork.
> Only open forks represent potentially orphaned changes. Maybe we need
> better terminology.

I think by definition it must be considered no longer a fork, however,
it may be a leaf if it is the tip of that branch of the fork.

Perhaps there is some confusion in the use of open/close with respect to
a fork? ``Close'' does have a specific meaning in Fossil and there is
certainly not an explicit ``close'' tag on the node that has been merged
from a fork. Only if someone were to commit against this node, it would
begin a new fork.

But a fork that ends in a leaf that is ``closed'' is not considered a
fork. And a fork that ends in being merged is also no longer a fork.

Andy
--
TAI64 timestamp: 4000000055305312

[Ron W]

On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> And a fork that ends in being merged is also no longer a fork.


I disagree. While it might be the most common case, merging does not
explicitly state any intent beyond the merge itself, even a full merge.
After all, a merge doesn't automatically close a named branch. So why would
a merge automatically make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly
indicate an intent to remove "fork" status.

[Steve Stefanovich]

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-***@bradfords.org<mailto:amb-***@bradfords.org>> wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an intent to remove "fork" status.

[Ron W]

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 <***@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
> *Subject: *Re: [fossil-users] Two trunks?
>
> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org
> > wrote:
>
>> And a fork that ends in being merged is also no longer a fork.
>
>
> I disagree. While it might be the most common case, merging does not
> explicitly state any intent beyond the merge itself, even a full merge.
> After all, a merge doesn't automatically close a named branch. So why would
> a merge automatically make a "fork" not a fork?
>
> Closing it or making it the start of a new, named branch explicitly
> indicate an intent to remove "fork" status.
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Steve Stefanovich]

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.

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?

That would be very visible, either prompting people to merge back and close the fork, 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 <***@stef.rs<mailto:***@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
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org<mailto:amb-***@bradfords.org>> wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an intent to remove "fork" status.

[Steve Stefanovich]

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.

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?

That would be very visible, either prompting people to merge back and close the fork, 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 <***@stef.rs<mailto:***@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
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org<mailto:amb-***@bradfords.org>> wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an intent to remove "fork" status.

[Richard Hipp]

On 4/18/15, Steve Stefanovich <***@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 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 milliseconds. Hence, what you suggest could result in
strange and mysterious changes occurring to the check-in topologies
during a push. Very undesirable, I think.

--
D. Richard Hipp
***@sqlite.org

[Joerg Sonnenberger]

On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org>
> wrote:
>
> > And a fork that ends in being merged is also no longer a fork.
>
>
> I disagree. While it might be the most common case, merging does not
> explicitly state any intent beyond the merge itself, even a full merge.
> After all, a merge doesn't automatically close a named branch. So why would
> a merge automatically make a "fork" not a fork?

You can still create commits from it, but update will move past it.
That's why it is no longer a fork.

Joerg

[Jan Nijtmans]

2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger <***@britannica.bec.de>:
> On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
>> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org>
...
>> I disagree. While it might be the most common case, merging does not
>> explicitly state any intent beyond the merge itself, even a full merge.
>> After all, a merge doesn't automatically close a named branch. So why would
>> a merge automatically make a "fork" not a fork?
>
> You can still create commits from it, but update will move past it.
> That's why it is no longer a fork.

Let's try that with a branch which is recently merged to trunk:

$ fossil update update-fork-warn
....
updated-to: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10
17:33:18 UTC
leaf: closed
tags: update-fork-warn
comment: Only check for forks on "open" leaves, otherwise we
cannot do anything about it from here anyway. Thanks to Andy Bradford
for noticing this. (user: jan.nijtmans)
changes: 13 files modified.
"fossil undo" is available to undo changes to the working checkout.

$ fossil update
....
checkout: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10
17:33:18 UTC
leaf: closed
tags: update-fork-warn
comment: Only check for forks on "open" leaves, otherwise we
cannot do anything about it from here anyway. Thanks to Andy Bradford
for noticing this. (user: jan.nijtmans)
changes: None. Already up-to-date

Looks like that statement is not true! "fossil update" will only move
past it if the
branch-name didn't change. I think Andy was right in his statement: the only
three ways a fork can be resolved is:
1) "fossil merge" without any arguments, merging the two tips of the
fork together.
2) "fossil merge --integrate <branchname>": merging to another branch, while
implicitely closing <branchname>.
3) "fossil tag --raw closed <uuid>" (or close it with the UI)

So, a merge which merges the two tips of a fork together indeed closes
the fork. But
for other merges more needs to be done, that's how it functions (as it should).
Sorry ;-)

Regards,
Jan Nijtmans

[Joerg Sonnenberger]

On Fri, Apr 17, 2015 at 01:07:50PM +0200, Jan Nijtmans wrote:
> 2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger <***@britannica.bec.de>:
> > On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
> >> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford <amb-***@bradfords.org>
> ...
> >> I disagree. While it might be the most common case, merging does not
> >> explicitly state any intent beyond the merge itself, even a full merge.
> >> After all, a merge doesn't automatically close a named branch. So why would
> >> a merge automatically make a "fork" not a fork?
> >
> > You can still create commits from it, but update will move past it.
> > That's why it is no longer a fork.
>
> Let's try that with a branch which is recently merged to trunk:

Right, but different. As discussed earlier, a fork means more than one
leaf for the same branch. My point is that a merge of a fork will be
passed over by update. In this case the branches are by definition the
same.

Joerg

[Ron W]

On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger <***@britannica.bec.de
> wrote:

> As discussed earlier, a fork means more than one
> leaf for the same branch.


And merging the leaf of a branch to another branch (maybe trunk) does not
make that leaf not-a-leaf. So why should merging a "fork-leaf" to whatever
make the "fork-leaf" not a "fork"?

[Matt Welland]

On Fri, Apr 17, 2015 at 10:12 AM, Ron W <***@gmail.com> wrote:

> On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger <
> ***@britannica.bec.de> wrote:
>
>> As discussed earlier, a fork means more than one
>> leaf for the same branch.
>
>
> And merging the leaf of a branch to another branch (maybe trunk) does not
> make that leaf not-a-leaf. So why should merging a "fork-leaf" to whatever
> make the "fork-leaf" not a "fork"?
>

Is this a conversation about the pragmatic aspects of a same-named split in
a timeline (the fossil working definition of fork) or about some abstract
philosophical semantics?

For fossil to be a viable long term solution in a intensely busy project I
believe the following is needed:

1. The optimal solution, where possible, don't let forks happen at all. Git
does this at a very slight cost to data safety.
2. Aggressively keep users informed of any open forks in the timeline
3. No false warnings.

#1 won't happen due to fossil emphasis on data safety, I believe it *can*
be done for the common use case of an autosync commit.
#2 is in progress but not aggressive enough to address my concern (thanks
Andy and Jan for your efforts, much appreciated)
#3 was looking problematic, possibly due to philosophy trumping pragmatism?
Might be addressed now?

I have tested the changes from trunk and Andy's fork-warn branch and I'm
not seeing the kind of warnings that would catch the attention of a busy
developer and prompt him or her to merge or close a lingering open fork.

fossil update - yes, good warning if you are on the branch with the fork
fossil co - no warning
fossil status - no warning
fossil update <someotherbranch> - no warning

Emphasis: there is no known valid need for an ongoing, open, same-named
(i.e. "fork") branch. In real-world development I've seen these forks cause
wasted time and effort that does NOT contribute to a feeling of goodwill
toward fossil. Remember: an open fork is potentially orphaned code that the
developer believes is not orphaned!

Here is a recent event that solidified my views on forks. I met a friend
for lunch who had worked on our team and used fossil. He moved to another
team where they were struggling with git. I asked the obvious question
"would you consider fossil?" He asked, "did they fix the fork problem?" to
which of course I had to reply "no". For him the bad taste of dealing with
a fork trumped the pain of ramping up on git which I have to admit made me
re-evaluate my "forks are no big deal" view.

One more time; a busy developer focused on getting out a release is going
to be taken out of the zone and will waste time when a fork happens. The
"situation" is the code and the release, polling the timeline to be sure a
fork didn't happen for "situational awareness" is a dilution of effort
toward the release.


>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Matt Welland]

By the way, the "optimal solution" of preventing forks in the common case
of commit+autosync seems like would be fairly easy to implement:

if doing a commit and autosync
if pull from server and set commit flag
commit
push and unset commit flag
else
inform user that someone else is committing
wait and try again

The "set commit flag" will succeed if a configurable time has passed since
it was set, I think 30 seconds would be a good compromise.

This would serialize all autosync commits and eliminate the most common
source of forks that I'm seeing. Disconnected users would sync in commits
as before, potentially creating forks. The warning on fork detection code
would still be needed.



On Sat, Apr 18, 2015 at 4:14 AM, Matt Welland <***@gmail.com>
wrote:

>
>
> On Fri, Apr 17, 2015 at 10:12 AM, Ron W <***@gmail.com> wrote:
>
>> On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger <
>> ***@britannica.bec.de> wrote:
>>
>>> As discussed earlier, a fork means more than one
>>> leaf for the same branch.
>>
>>
>> And merging the leaf of a branch to another branch (maybe trunk) does not
>> make that leaf not-a-leaf. So why should merging a "fork-leaf" to whatever
>> make the "fork-leaf" not a "fork"?
>>
>
> Is this a conversation about the pragmatic aspects of a same-named split
> in a timeline (the fossil working definition of fork) or about some
> abstract philosophical semantics?
>
> For fossil to be a viable long term solution in a intensely busy project I
> believe the following is needed:
>
> 1. The optimal solution, where possible, don't let forks happen at all.
> Git does this at a very slight cost to data safety.
> 2. Aggressively keep users informed of any open forks in the timeline
> 3. No false warnings.
>
> #1 won't happen due to fossil emphasis on data safety, I believe it *can*
> be done for the common use case of an autosync commit.
> #2 is in progress but not aggressive enough to address my concern (thanks
> Andy and Jan for your efforts, much appreciated)
> #3 was looking problematic, possibly due to philosophy trumping
> pragmatism? Might be addressed now?
>
> I have tested the changes from trunk and Andy's fork-warn branch and I'm
> not seeing the kind of warnings that would catch the attention of a busy
> developer and prompt him or her to merge or close a lingering open fork.
>
> fossil update - yes, good warning if you are on the branch with the fork
> fossil co - no warning
> fossil status - no warning
> fossil update <someotherbranch> - no warning
>
> Emphasis: there is no known valid need for an ongoing, open, same-named
> (i.e. "fork") branch. In real-world development I've seen these forks cause
> wasted time and effort that does NOT contribute to a feeling of goodwill
> toward fossil. Remember: an open fork is potentially orphaned code that the
> developer believes is not orphaned!
>
> Here is a recent event that solidified my views on forks. I met a friend
> for lunch who had worked on our team and used fossil. He moved to another
> team where they were struggling with git. I asked the obvious question
> "would you consider fossil?" He asked, "did they fix the fork problem?" to
> which of course I had to reply "no". For him the bad taste of dealing with
> a fork trumped the pain of ramping up on git which I have to admit made me
> re-evaluate my "forks are no big deal" view.
>
> One more time; a busy developer focused on getting out a release is going
> to be taken out of the zone and will waste time when a fork happens. The
> "situation" is the code and the release, polling the timeline to be sure a
> fork didn't happen for "situational awareness" is a dilution of effort
> toward the release.
>
>
>>
>> _______________________________________________
>> fossil-users mailing list
>> fossil-***@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>

[Richard Hipp]

Fossil has, for many years, detected potential forks prior to commit
and warned about them, or within the past few years has disallowed the
commit completely without the --allow-fork option. If two users are
committing concurrently, the fork detection fails, but even then the
second user gets a message "**** warning: a fork has occurred *****".
The problem arises when the second user does not notice, or chooses to
ignore, this message and the situational awareness within the
organization is such that nobody notices the fork plainly displayed on
the timeline. The check-in on the fork gets overlooked and fails to
make it into the next release.

Proposed solutions include denying the ability to commit or push a
fork. But doesn't that just make the problem worse? We've already
established that users are in the habit of ignoring scary fork
warnings. Wouldn't they also just ignore the fact that the commit or
push failed? With a fork, at least the content is safely on the
server and can be easily recovered by anybody willing to take a moment
to review the timeline. But if the change never gets pushed, the
content is only on the developer's machine, out of view and
unrecoverable by anyone except the original developer. And if it
never gets committed, then the work might be lost even to the original
developer. How is that an improvement?

Other proposed changes include more frequent nagging about forks. The
issue is less clear-cut, but I still worry that it might contribute to
warning fatigue. I go by the motto that you should always distrust
any computer program that thinks it knows more than you do. Constant
nagging about forks seems to move Fossil in the direction of programs
that I would not trust. This is not to say that there shouldn't be
warnings, but there needs to be balance.

The "fossil update|co|checkout BRANCH" command takes you to the most
recent check-in for BRANCH. If BRANCH contains leaves that are not
the most recent check-in, it seems like this would be a good time to
issue a warning. The command might even fail with the message that
BRANCH is ambiguous and then provide a list of all possible SHA1
values that BRANCH could resolve to, enabling the user to retry the
command with an unambiguous SHA1 hash.

Another approach would be to provide commands (such as "fossil forks")
that actually show problems in the tree, for people who are actually
interested - for example the release manager. A web-version of
"fossil forks" with graphical pictures of each fork would be nice to
have.

One other thing: We ought to intentionally preserve several forks
within the Fossil self-hosting repository, so that we always have test
cases for the above mechanisms readily at hand.
--
D. Richard Hipp
***@sqlite.org

[Kees Nuyt]

[Default] On Sat, 18 Apr 2015 09:53:53 -0400, Richard Hipp <***@sqlite.org> wrote:

>Fossil has, for many years, detected potential forks prior to commit
>and warned about them, or within the past few years has disallowed the
>commit completely without the --allow-fork option. If two users are
>committing concurrently, the fork detection fails, but even then the
>second user gets a message "**** warning: a fork has occurred *****".
>The problem arises when the second user does not notice, or chooses to
>ignore, this message and the situational awareness within the
>organization is such that nobody notices the fork plainly displayed on
>the timeline. The check-in on the fork gets overlooked and fails to
>make it into the next release.

+1

>Proposed solutions include denying the ability to commit or push a
>fork. But doesn't that just make the problem worse? We've already
>established that users are in the habit of ignoring scary fork
>warnings. Wouldn't they also just ignore the fact that the commit or
>push failed? With a fork, at least the content is safely on the
>server and can be easily recovered by anybody willing to take a moment
>to review the timeline. But if the change never gets pushed, the
>content is only on the developer's machine, out of view and
>unrecoverable by anyone except the original developer. And if it
>never gets committed, then the work might be lost even to the original
>developer. How is that an improvement?

+1

>Other proposed changes include more frequent nagging about forks. The
>issue is less clear-cut, but I still worry that it might contribute to
>warning fatigue. I go by the motto that you should always distrust
>any computer program that thinks it knows more than you do. Constant
>nagging about forks seems to move Fossil in the direction of programs
>that I would not trust. This is not to say that there shouldn't be
>warnings, but there needs to be balance.

+1

>The "fossil update|co|checkout BRANCH" command takes you to the most
>recent check-in for BRANCH. If BRANCH contains leaves that are not
>the most recent check-in, it seems like this would be a good time to
>issue a warning.

+1

> The command might even fail with the message that
>BRANCH is ambiguous and then provide a list of all possible SHA1
>values that BRANCH could resolve to, enabling the user to retry the
>command with an unambiguous SHA1 hash.

+1

>Another approach would be to provide commands (such as "fossil forks")
>that actually show problems in the tree, for people who are actually
>interested - for example the release manager. A web-version of
>"fossil forks" with graphical pictures of each fork would be nice to
>have.

+1

>One other thing: We ought to intentionally preserve several forks
>within the Fossil self-hosting repository, so that we always have test
>cases for the above mechanisms readily at hand.

+1

SUM: +7

--
Thanks & Regards,

Kees Nuyt

[Sean Woods]

On Sat, Apr 18, 2015, at 09:53 AM, Richard Hipp wrote:
> [...]
> The problem arises when the second user does not notice, or chooses to
> ignore, this message and the situational awareness within the
> organization is such that nobody notices the fork plainly displayed on
> the timeline. The check-in on the fork gets overlooked and fails to
> make it into the next release.
> [...]

I started this particuar thread, and I have been following it although I
must admit it has felt mired in technical detail and various
philosophical discussions. I think Matt Welland's earlier email (right
before your email, Richard) sums up my reaction pretty well -- Fossil's
behavior is not in line with what most "normal" users expect, and these
users aren't able to get around it even when the team's Fossil champion
concentrates on the issue. That's the reality. However I do realize
the technical awkwardness of potential solutions so all this discussion
(confusing to me as it may be) indicates the solution isn't "easy."

Perhaps we could tackle the issue from a workflow perspective rather
than a technical one. I know the SQLite team makes copious use of
checklists in their development process and I wonder if that concept
would be useful here. What are we supposed to do when one of these
forks appears? What human process gets triggered when a fork exists?
At minimum, someone needs to evaluate whether the fork is the desired
state and take appropriate action. It's a human problem before it's a
technical problem and can't necessarily be solved via technical means.

Richard, perhaps you have a suggestion on this?

Also -- I'm not sure the "two forks" state (i.e. the state of the
repository after two forks have been committed) is totally obvious.
Perhaps a template variable to alert you of this state in some way might
be useful, then people could just put it in their TH1 templates.

[j. van den hoff]

On Sat, 18 Apr 2015 15:53:53 +0200, Richard Hipp <***@sqlite.org> wrote:

> Fossil has, for many years, detected potential forks prior to commit
> and warned about them, or within the past few years has disallowed the
> commit completely without the --allow-fork option. If two users are
> committing concurrently, the fork detection fails, but even then the
> second user gets a message "**** warning: a fork has occurred *****".
> The problem arises when the second user does not notice, or chooses to
> ignore, this message and the situational awareness within the
> organization is such that nobody notices the fork plainly displayed on
> the timeline. The check-in on the fork gets overlooked and fails to
> make it into the next release.
>
> Proposed solutions include denying the ability to commit or push a
> fork. But doesn't that just make the problem worse? We've already
> established that users are in the habit of ignoring scary fork
> warnings. Wouldn't they also just ignore the fact that the commit or
> push failed? With a fork, at least the content is safely on the
> server and can be easily recovered by anybody willing to take a moment
> to review the timeline. But if the change never gets pushed, the
> content is only on the developer's machine, out of view and
> unrecoverable by anyone except the original developer. And if it
> never gets committed, then the work might be lost even to the original
> developer. How is that an improvement?
>
> Other proposed changes include more frequent nagging about forks. The
> issue is less clear-cut, but I still worry that it might contribute to
> warning fatigue. I go by the motto that you should always distrust
> any computer program that thinks it knows more than you do. Constant
> nagging about forks seems to move Fossil in the direction of programs
> that I would not trust. This is not to say that there shouldn't be
> warnings, but there needs to be balance.
>
> The "fossil update|co|checkout BRANCH" command takes you to the most
> recent check-in for BRANCH. If BRANCH contains leaves that are not
> the most recent check-in, it seems like this would be a good time to

yes.

> issue a warning. The command might even fail with the message that
> BRANCH is ambiguous and then provide a list of all possible SHA1
> values that BRANCH could resolve to, enabling the user to retry the
> command with an unambiguous SHA1 hash.

no. I believe the checkout should just proceed as it precently does in
this case. it seems clear that the intent of `fossil up BRANCH' is just
that, rather than going to any of the fork-related leaves.

>
> Another approach would be to provide commands (such as "fossil forks")
> that actually show problems in the tree, for people who are actually

that would be very good. as forks are sometimes simply spurious (there
were some never-quite-cleared-up reports in the past of forks suddenly
appearing even in single-developer projects -- I, too, experienced this at
least onece) or due to erroneous checkins. I would argue for restricting
the list by default to "unclosed" fork leaves so that the reported list of
forks is restricted to the forks still not dealt with (either are not just
closed or not yet merged back). maybe this list could additionally be
generated by `fossil branch' like

trunk
dev
experimental
--
unresolved forks:
{sha1} (parent branch: {parent branch} dated {date})

so that it can be noted by the user even if he is not explicitly hunting
for the forks.

> interested - for example the release manager. A web-version of
> "fossil forks" with graphical pictures of each fork would be nice to
> have.

CLI seems rather more important to me, but yes, it would be nice.

>
> One other thing: We ought to intentionally preserve several forks
> within the Fossil self-hosting repository, so that we always have test
> cases for the above mechanisms readily at hand.

I believe somewhere in this thread it was argued that forks can be
intended/beneficial. I feel that such use should be "officially
discouraged" and to proceed from a consensus that (unclosed) fork-leaves
should be taken as indicator of a lurking problem in the project.


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Joerg Sonnenberger]

On Sat, Apr 18, 2015 at 09:53:53AM -0400, Richard Hipp wrote:
> Other proposed changes include more frequent nagging about forks. The
> issue is less clear-cut, but I still worry that it might contribute to
> warning fatigue.

I think the most reasonable approach is to mirror Mercurial. Before a
pull/sync operation, remembering the number of leaves per branch.
Compare this to the number of leaves per branch afterwards and report
changes. If you skip new/closed branches, it would result in something
like:

+1 leaf for trunk
-1 leaf for hot-development

Joerg

[Ron W]

On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland <***@gmail.com>
wrote:

>
> For fossil to be a viable long term solution in a intensely busy project I
> believe the following is needed:
>
> 1. The optimal solution, where possible, don't let forks happen at all.
> Git does this at a very slight cost to data safety.
> 2. Aggressively keep users informed of any open forks in the timeline
> 3. No false warnings.
>
> #1 won't happen due to fossil emphasis on data safety, I believe it *can*
> be done for the common use case of an autosync commit.
>

Fossil tries to prevent forks when auto-sync is on.

I don't know if Git has something like auto-sync, but I am aware that
many/most projects using Git are configured to reject "non-fast-forward"
push/pull. This doesn't actually prevent the fork, only blocks it from
appearing in the main repo. (I don't know what happens in a "multi-layer"
project where a core dev could receive a commit from downstream then later
does a pull from upstream that results in a fork. (This could happen if any
core dev makes/receives a commit from the same parent and pushes it
upstream right after the first core dev does a pull.))


> #2 is in progress but not aggressive enough to address my concern (thanks
> Andy and Jan for your efforts, much appreciated)
>

This is one of the reasons I suggested auto-tagging the fork with a special
tag. Then any command could query the tags table rather than having to do
several queries to find the forks.


> #3 was looking problematic, possibly due to philosophy trumping
> pragmatism? Might be addressed now?
>

This is a definition problem.

To my thinking, any place a parent commit has 2 or more children on the
same branch is a fork. This seems very clear and unambiguous to me. Some
think this is too aggressive, so I will grant that closing fork-leaves is
sufficient to indicate explicit intent to resolve the fork.

As to merging, a "branch-leaf" is not automatically closed by merging it to
anther branch, so why would merging automatically do anything to a
"fork-leaf" to make it not a fork-leaf?

[Scott Robison]

On Sat, Apr 18, 2015 at 12:19 PM, Ron W <***@gmail.com> wrote:

> On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland <***@gmail.com>
> wrote:
>
>>
>>
> #3 was looking problematic, possibly due to philosophy trumping
>> pragmatism? Might be addressed now?
>>
>
> This is a definition problem.
>
> To my thinking, any place a parent commit has 2 or more children on the
> same branch is a fork. This seems very clear and unambiguous to me. Some
> think this is too aggressive, so I will grant that closing fork-leaves is
> sufficient to indicate explicit intent to resolve the fork.
>
> As to merging, a "branch-leaf" is not automatically closed by merging it
> to anther branch, so why would merging automatically do anything to a
> "fork-leaf" to make it not a fork-leaf?
>

There is a --integrate switch to the merge command that closes the merged
branch. Perhaps the addition of an "integrate" command that is essentially
a merge with that option auto specified might be useful to those whose
workflows seem to result in forks?

There is also a leaves command, perhaps the addition of a --forks option
would be useful, and a "forks" command (as has been suggested already) that
is essentially the same as "leaves --forks". "leaves" by default only shows
open leaves, but has --all and --closed options to pick other sets of
leaves that might be useful, as well as --recompute.

--
Scott Robison

[Matt Welland]

Testing of new fork notification:

====================================================
Older fossil, no warning whatsoever on overlapping commits (the mechanism
that causes the silent forks):

***@xena:/mfs/matt/data/fossil-tests$ ./test-forks.sh
project-id: 8fb8e164bea9d46b58a95ac5bf060836832b8904
server-id: e8a14f9abf390df3193afcbe068fd07be0417bda
admin-user: matt (initial password is "a9edb1")
Repository cloned into test-fork.fossil
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: 8fb8e164bea9d46b58a95ac5bf060836832b8904
server-id: e8a14f9abf390df3193afcbe068fd07be0417bda
admin-user: matt (password is "53a99c")
project-name: <unnamed>
repository: /mfs/matt/data/fossil-tests/testdir/a/test-fork.fossil
local-root: /mfs/matt/data/fossil-tests/testdir/a/
config-db: /home/matt/.fossil
project-code: 8fb8e164bea9d46b58a95ac5bf060836832b8904
checkout: c21fae55541a749dbce5467eaacd9d9e44487707 2015-04-19 00:13:39
UTC
leaf: open
tags: trunk
comment: initial empty check-in (user: matt)
check-ins: 1
Repository cloned into test-fork.fossil
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: 8fb8e164bea9d46b58a95ac5bf060836832b8904
server-id: e8a14f9abf390df3193afcbe068fd07be0417bda
admin-user: matt (password is "0d551e")
project-name: <unnamed>
repository: /mfs/matt/data/fossil-tests/testdir/b/test-fork.fossil
local-root: /mfs/matt/data/fossil-tests/testdir/b/
config-db: /home/matt/.fossil
project-code: 8fb8e164bea9d46b58a95ac5bf060836832b8904
checkout: c21fae55541a749dbce5467eaacd9d9e44487707 2015-04-19 00:13:39
UTC
leaf: open
tags: trunk
comment: initial empty check-in (user: matt)
check-ins: 1
ADDED file1
ADDED file2
Pull from file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 285 received: 312 ip:
New_Version: f1573535398c039cb180bd5529682496d164f4e3
Pull from file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 285 received: 311 ip:
New_Version: 085dc764e8b6dabb32e4239e64e9c005b9822550
Push to file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Push done, sent: 492 received: 270 ip:
Push to file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Push done, sent: 490 received: 270 ip:

====================================================
With new checks we get a nice big WARNING:

***@xena:/mfs/matt/data/fossil-tests$ ./test-forks.sh
project-id: f7c3a6aee63331ebc36327c70bfa69c2816cfe23
server-id: 025775feeb37807d09a65b396f991e28b6a11408
admin-user: matt (initial password is "931c07")
Repository cloned into test-fork.fossil
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: f7c3a6aee63331ebc36327c70bfa69c2816cfe23
server-id: 025775feeb37807d09a65b396f991e28b6a11408
admin-user: matt (password is "188cf7")
project-name: <unnamed>
repository: /mfs/matt/data/fossil-tests/testdir/a/test-fork.fossil
local-root: /mfs/matt/data/fossil-tests/testdir/a/
config-db: /home/matt/.fossil
project-code: f7c3a6aee63331ebc36327c70bfa69c2816cfe23
checkout: 49e4abe1e3c2985c7469aa90b4a798542617d2e0 2015-04-19 00:05:33
UTC
leaf: open
tags: trunk
comment: initial empty check-in (user: matt)
check-ins: 1
Repository cloned into test-fork.fossil
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: f7c3a6aee63331ebc36327c70bfa69c2816cfe23
server-id: 025775feeb37807d09a65b396f991e28b6a11408
admin-user: matt (password is "a04435")
project-name: <unnamed>
repository: /mfs/matt/data/fossil-tests/testdir/b/test-fork.fossil
local-root: /mfs/matt/data/fossil-tests/testdir/b/
config-db: /home/matt/.fossil
project-code: f7c3a6aee63331ebc36327c70bfa69c2816cfe23
checkout: 49e4abe1e3c2985c7469aa90b4a798542617d2e0 2015-04-19 00:05:33
UTC
leaf: open
tags: trunk
comment: initial empty check-in (user: matt)
check-ins: 1
ADDED file1
ADDED file2
Pull from file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 283 received: 312 ip:
New_Version: 8d908deab0db68c73dec58d792799fa3ccbb9433
Pull from file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 283 received: 312 ip:
New_Version: f6a29b41cc23f3453a7b1baffe11b8180f173427
Push to file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Push done, sent: 490 received: 270 ip:
Push to file:///mfs/matt/data/fossil-tests/testdir/test-fork.fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Server says: ****** WARNING: a fork has occurred ******
Round-trips: 1 Artifacts sent: 2 received: 0
Push done, sent: 491 received: 319 ip:

====================================================
A simple script to simulate the colliding commits that caused silent forks:

#!/bin/bash

rm -rf testdir

mkdir -p testdir/{a,b}

fossil init testdir/test-fork.fossil

function clone_open () {
area=$1
(cd testdir/$area;
fossil clone file://../test-fork.fossil test-fork.fossil;
fossil open test-fork.fossil;
fossil set autosync 0;
fossil set web firefox)
}

function addfile () {
area=$1
fname=$2
(cd testdir/$area;fossil add $fname)
}

function modfile () {
area=$1
fname=$2
echo $RANDOM|md5sum|awk '{print $1}' > testdir/$area/$fname
}

function pull () {
area=$1
(cd testdir/$area;fossil pull)
}

function commit () {
area=$1
(cd testdir/$area;fossil commit -m "committed from area $a")
}

function push () {
area=$1
(cd testdir/$area;fossil push)
}

# do it

clone_open a
clone_open b

modfile a file1
addfile a file1

modfile b file2
addfile b file2

# commit from a starts
pull a
commit a

# commit from b starts
pull b
commit b

# commit from a completes
push a

# commit from b completes
push b


On Sat, Apr 18, 2015 at 1:16 PM, Scott Robison <***@casaderobison.com>
wrote:

> On Sat, Apr 18, 2015 at 12:19 PM, Ron W <***@gmail.com> wrote:
>
>> On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland <***@gmail.com>
>> wrote:
>>
>>>
>>>
>> #3 was looking problematic, possibly due to philosophy trumping
>>> pragmatism? Might be addressed now?
>>>
>>
>> This is a definition problem.
>>
>> To my thinking, any place a parent commit has 2 or more children on the
>> same branch is a fork. This seems very clear and unambiguous to me. Some
>> think this is too aggressive, so I will grant that closing fork-leaves is
>> sufficient to indicate explicit intent to resolve the fork.
>>
>> As to merging, a "branch-leaf" is not automatically closed by merging it
>> to anther branch, so why would merging automatically do anything to a
>> "fork-leaf" to make it not a fork-leaf?
>>
>
> There is a --integrate switch to the merge command that closes the merged
> branch. Perhaps the addition of an "integrate" command that is essentially
> a merge with that option auto specified might be useful to those whose
> workflows seem to result in forks?
>
> There is also a leaves command, perhaps the addition of a --forks option
> would be useful, and a "forks" command (as has been suggested already) that
> is essentially the same as "leaves --forks". "leaves" by default only shows
> open leaves, but has --all and --closed options to pick other sets of
> leaves that might be useful, as well as --recompute.
>
> --
> Scott Robison
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Andy Bradford]

Thus said Ron W on Thu, 16 Apr 2015 21:04:12 -0400:

> I disagree. While it might be the most common case, merging does not
> explicitly state any intent beyond the merge itself, even a full
> merge.

After one has merged a fork, does ``fossil merge'' report that there are
any more forks to be merged on the branch? If not, then does not Fossil
intend that it is no longer a fork?

> After all, a merge doesn't automatically close a named branch. So why
> would a merge automatically make a "fork" not a fork?

As I tried to point out earlier, ``close'' is a special term in Fossil.
The only time a branch is ``closed'' is if it has a ``closed'' tag on
it. Merging the branch does not ``close'' the branch. It is still a
branch because new commits against its leaf are still allowed. If you
merge a fork, commits against it are no longer allowed, at least not
without another --allow-fork (or an accident).

Neither does merging a fork ``close'' the fork, but it is it no longer a
fork by virtue of the fact that it has been merged into itself. To make
it a fork again, one would have to commit against the node that was
merged.

One can have a fork on a non-trunk branch too:

http://fossil.bradfords.org:8080/timeline


> Closing it or making it the start of a new, named branch explicitly
> indicate an intent to remove "fork" status.

Why does merging not removes ``fork'' status?

If it hasn't changed status, why would ``fossil merge'' cease to to
think that there is a fork to merge. ``fossil help merge'' says:

``If the VERSION argument is omitted, then Fossil attempts to find a
recent fork on the current branch to merge.''

For Fossil to attempt to find a recent fork, must it not have a working
definition of just what a fork is first?

Notice also that Fossil does not label a fork that has been merged a
leaf.

But a branch that has been merged is still considered a leaf (or in
other words an active named fork) because the ``closed'' tag has not
been imposed upon it. Once ``closed'' the branch will be a ``closed
leaf.''

So clearly Fossil does treat a ``fork leaf'' differently from a ``branch
leaf.''

Oddly enough, I'm not sure if this is a bug... but if I update to:

http://fossil.bradfords.org:8080/info/ddbeee499bb3cee9

``fossil update'' does not complaing about there being multiple
descendants. However, ``fossil merge'' actually does merge in the Closed
leaf that is part of the fork. Not sure if this is actually intended
behavior, but it does seem that ``fossil merge'' treats the fork
differently than ``fossil update'' does.

Thanks for the interesting discussion. Definitely good to flesh out the
definitions we're using.

Thanks,

Andy
--
TAI64 timestamp: 4000000055306bbf

[Andy Bradford]

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 milliseconds.

I came to this realization as I was working on the sync-forkwarn branch.
I abandoned the thought of having the server try to detect a fork for
this very reason. It doesn't have all the necessary information to make
such a decision, and indeed, the resolution of the fork may actually
arrive in the next round-trip.

So I removed that functionality.

The only time that fork detection makes sense (if at all) is *after* a
complete sync in the client.

Andy
--
TAI64 timestamp: 400000005532f19c

[Andy Bradford]

Thus said Jan Nijtmans on Fri, 10 Apr 2015 10:01:26 +0200:

> Something like:
> <http://fossil-scm.org/index.html/info/32998a20f90bc6a2>

Yes, I was looking through merge.c to look for gems like this! I also
found path_common_ancestor (in case it's needed) in path.c.

> The branch "dg-misc" has a fork for more than a year now, no-one will
> notice - nor be troubled - until someone starts to work on it. That's
> when I would expect a warning.

Yes, I like this new ability. Very good!

Andy
--
TAI64 timestamp: 400000005527f163

[Ron W]

On Fri, Apr 10, 2015 at 12:48 AM, Matt Welland <***@gmail.com>
wrote:

> I'll test this at work tomorrow but unfortunately I think it will be
> problematic. The issue will be warning fatigue due to the false warnings.
>

One of the advantages of my special "fork" tag idea is that the special tag
can be canceled. Either explicitly with the exiting commands to manage
tags, or implicitly in the event the "fork" commit is used as the root of a
new branch.

[bch]

Would it be sufficient to have a command $fork_detector that iterates over
all of the tips and reports identical names?
On Apr 10, 2015 8:28 AM, "Ron W" <***@gmail.com> wrote:

> On Fri, Apr 10, 2015 at 12:48 AM, Matt Welland <***@gmail.com>
> wrote:
>
>> I'll test this at work tomorrow but unfortunately I think it will be
>> problematic. The issue will be warning fatigue due to the false warnings.
>>
>
> One of the advantages of my special "fork" tag idea is that the special
> tag can be canceled. Either explicitly with the exiting commands to manage
> tags, or implicitly in the event the "fork" commit is used as the root of a
> new branch.
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>

[Ron W]

On Thu, Apr 9, 2015 at 12:07 AM, Matt Welland <***@gmail.com>
wrote:
>
> On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford <amb-***@bradfords.org>
> wrote:
>
>> Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700:
>>
>> > What we are seeing is that forks happen due to simultaneous, partially
>> > overlapping, commits and that neither party involved in the two
>> > commits has any idea that a fork was committed.
>>
>> Perhaps this will help:
>>
>> http://www.fossil-scm.org/index.html/info/6b410f914ef5be53
>>
>> Probably needs a review and possibly some testing, but it does seem to
>> work for me:
>>
>
> Thanks Andy, this looks like a serious move in the right direction (at
> least from my point of view). Here is what I see:
> [...]
>
> Would it be possible to detect and warn on update, status and push?
>

If a special tag were to be auto-set upon detection, this would be easy.

Also, having the special tag would allow users the option of having the
warning be displayed more than once AND for the warning to be propagated
outward, beyond any intermediate Fossil repos/servers.

[Ron W]

On Wed, Apr 8, 2015 at 2:19 AM, Matt Welland <***@gmail.com> wrote:

> A much better solution is to block a push that creates a fork and inform
> the user that they need to fix the fork and push again.
>

I disagree.

Automatic shunning of an incoming commit by the receiving repo is anathema
to Fossil's underlying promise to preserve history. There are real reasons
that the existing shunning mechanism requires human intervention.

Auto-adding a special tag to warn the (core) team will allow any (core)
team member to take action in the even the original committer fails to (for
whatever reason). If the commit is auto-shunned, then only the original
committer's repo (and maybe an intermediate repo) will have the resources
required to take action.

[Ron W]

On Tue, Apr 7, 2015 at 10:14 PM, Andy Bradford <amb-***@bradfords.org>
wrote:

> The software already warns users that a fork is imminent. They have the
> choice to ignore the warning, or not.
>

Even when auto-sync is enabled and the upstream repo can be contacted,
there is still a window where 2 (or more) commits can be made against the
same parent.

Ideally, this should never happen, but real working conditions might
dictate making a commit during non-idea situations.

[Andy Bradford]

Thus said Ron W on Wed, 08 Apr 2015 12:13:29 -0400:

> Ideally, this should never happen, but real working conditions might
> dictate making a commit during non-idea situations.

Right, specifically, offline checkins and situations where autosync is
entirely off.

I think in these cases it makes sense for the server to send a non-fatal
message indicating that it found a fork.

Andy
--
TAI64 timestamp: 400000005525e212

[Andy Bradford]

Thus said Ron W on Mon, 06 Apr 2015 15:18:56 -0400:

> Auto-sync helps to avoid forks. But the best way to avoid forks is
> good communication between contributors. Still, I would like to see
> the ability to generate a warning when a Fossil server receives a
> commit against a parent that already has a child on the same branch as
> the just received commit.

At the moment, Fossil will generate a warning on the client side for the
committer who makes the fork. Who would be the intended audience if the
server produced a warning?

Andy
--
TAI64 timestamp: 4000000055248dac