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)
Hi,
I'm using fossil as usual, for my personal projects. This week I've been
working on a Unity game. I set up the fossil database as WAL using fossil
rebuild command. Now I get this every time I cancel a commit of a file that
includes binary data:
$ fossil ci -m "improving icon"
./scenes/mainSc
For what it's worth, I agree with this. Loading the protocol and/or
"in-band" processing sounds like a horrible error to me. I'd suggest some
"offline" local processing, if anything. Something like:
$ fossil show-forks
That (if this doesn't exist already) will report potential forks that one
can
Hi Richard and fellow email community,
thank you for your very nice SCM tool, Fossil, and your email list.
Could you possibly have information about how many people use Fossil to
track analysis and design and the changes to analysis and design?
Basically, the stuff that might precede writing c
Testing of new fork notification:
Older fossil, no warning whatsoever on overlapping commits (the mechanism
that causes the silent forks):
matt@xena:/mfs/matt/data/fossil-tests$ ./test-forks.sh
project-id: 8fb8e164bea9d46b58a95ac5bf060836832b89
Thus said Richard Hipp on Sat, 18 Apr 2015 07:50:42 -0400:
> When the artifacts that comprise a fork are received, the server has
> no way of knowing that new artifacts that resolve the fork (either by
> merging or by moving it onto a branch) will not be received within the
> next few milliseco
On Sat, Apr 18, 2015 at 12:19 PM, Ron W wrote:
> On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland
> 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 com
Hello All,
I don't think this is intentional:
http://www.fossil-scm.org/index.html/info/1efdfe1ad3f322c96f22b4ed8c918f557bf1e0ee?txt=1&ln=14,15
Both fossil update and fossil status direct to:
http://www.fossil-scm.org/index.html/help?cmd=import
In fact, is the import the correct help page based
On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland
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.
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
p
On Fri, Apr 17, 2015 at 6:41 PM, wrote:
> Thank you but I wanted this for a Win7 machine, not Linux.
> (I have MINGW installed but its 'patch' is a bit unstable as it crashes
> most of the time besides not being available on most Win7 machines.)
>
> Thanks, anyway. I guess I need to look for a r
On Sat, 18 Apr 2015 15:53:53 +0200, Richard Hipp 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 f
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
[Default] On Sat, 18 Apr 2015 09:53:53 -0400, Richard Hipp
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 concur
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 me
On 4/18/15, Steve Stefanovich wrote:
> How about if the fork happens, simply change the tag automatically to
> 'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or
> just tag it as 'fork', on commit?
>
When the artifacts that comprise a fork are received, the server has
no way
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
inf
On Fri, Apr 17, 2015 at 10:12 AM, Ron W wrote:
> On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger <
> jo...@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 n
18 matches
Mail list logo
