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
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
On Fri, Apr 17, 2015 at 10:12 AM, Ron W ronw.m...@gmail.com 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
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
[Default] On Sat, 18 Apr 2015 09:53:53 -0400, Richard Hipp d...@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
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 Fri, Apr 17, 2015 at 6:41 PM, to...@acm.org 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
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
On Sat, 18 Apr 2015 15:53:53 +0200, Richard Hipp d...@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
Hello All,
I don't think this is intentional:
http://www.fossil-scm.org/index.html/info/1efdfe1ad3f322c96f22b4ed8c918f557bf1e0ee?txt=1ln=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 12:19 PM, Ron W ronw.m...@gmail.com wrote:
On Sat, Apr 18, 2015 at 7:14 AM, Matt Welland mattrwell...@gmail.com
wrote:
#3 was looking problematic, possibly due to philosophy trumping
pragmatism? Might be addressed now?
This is a definition problem.
To my
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
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:
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
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
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
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
17 matches
Mail list logo
