Let me rephrase - maybe I was a bit ambiguous what I meant. On pull/update, when fork happens locally, the code would automatically do what currently happens when someone edits the check-in and puts it on a new branch.
So on a local repo/check-out, developer sees he's now on (latest leaf of) fork-trunk branch, instead of thinking he's on a trunk while in reality he's on a fork of the trunk which is named the same. Dev merges back to trunk and commits, or edits the beginning of the fork (if he has a sequence of check-ins) to a branch name he likes in case he wants to keep it as a branch, and pushes. So what would end up on the server that is strange or mysterious on such push apart from an extra tag, fork-trunk? What am I missing? Original Message From: Richard Hipp Sent: Saturday, 18 April 2015 21:50 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?) On 4/18/15, Steve Stefanovich <s...@stef.rs> wrote: > How about if the fork happens, simply change the tag automatically to > 'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or > just tag it as 'fork', on commit? > When the artifacts that comprise a fork are received, the server 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 d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
