For reference, a **rough** comparison (diff't repo) -- this repository
does *NOT* have the blob index (suggested by drh) that I manually
applied to NetBSD-src:
kamloops$ time fossil pull
Pull from http://pkgsrc.sonnenberger.org
Round-trips: 4 Artifacts sent: 0 received: 177
Pull done, sent:
On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said bch on Mon, 27 Apr 2015 18:33:28 -0700:
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 338 received: 1368 ip: 135.28.13.11
1.43
On 4/28/15, bch brad.har...@gmail.com wrote:
For reference, a **rough** comparison (diff't repo) -- this repository
does *NOT* have the blob index (suggested by drh) that I manually
applied to NetBSD-src:
kamloops$ time fossil pull
Pull from http://pkgsrc.sonnenberger.org
Round-trips: 4
kamloops$ fossil version
This is fossil version 1.32 [440ed5da09] 2015-04-27 23:54:38 UTC
And to be clear -- I'm not complaining about that latest pull -- this
set of metrics we're collecting and this testing is incredibly
low-tech, so it's hard to infer very much from them. I mention that
the
2015-04-27 23:27 GMT+02:00 bch brad.har...@gmail.com:
Apparently the automatic fork check is in trunk.
Which commit caused the regression? Two possibilities:
a)
https://www.fossil-scm.org/index.html/info/560483f50436c9f7
b)
https://www.fossil-scm.org/index.html/info/f78cba5c9994222f
Thus said bch on Mon, 27 Apr 2015 14:27:41 -0700:
1) On a large repo, this takes an inordinate amount of time. On a sync
(with no updates necessary), the runtime is ~45s (on the first
attempt, I stopped it after ~10 mins of running in order to re-run it
with a time(1) command to
Thus said Richard Hipp on Sun, 26 Apr 2015 18:34:23 -0400:
The forks query parameter to the /timeline page now shows recent
forks in the check-in DAG. For this page, a fork means a check-in
with two or more children in the same branch. No attempt is made to
distinguish between forks
Apparently the automatic fork check is in trunk.
1) On a large repo, this takes an inordinate amount of time. On a
sync (with no updates necessary), the runtime is ~45s (on the first
attempt, I stopped it after ~10 mins of running in order to re-run it
with a time(1) command to collect info) on
Thus said Richard Hipp on Mon, 27 Apr 2015 19:37:09 -0400:
Is that coded needed at all?
That's a fair question, and one that we've been debating over the past
couple of weeks. Some feel that Fossil should warn about a fork, even
those which were created ``silently'' during a sync.
On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said Jan Nijtmans on Mon, 27 Apr 2015 23:41:22 +0200:
a)
https://www.fossil-scm.org/index.html/info/560483f50436c9f7
I would guess this is the problem, but I could be wrong.
Is that coded needed at all?
If user X pushes a
On 4/27/15, Richard Hipp d...@sqlite.org wrote:
(5112 is a valid rcvid value in my local copy of the SQLite
repository). The first version is consistently faster than the
second.
57482
Run Time: real 0.014 user 0.006962 sys 0.007262
---
57482
Run Time: real 0.027
On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
Regarding the query:
http://www.fossil-scm.org/index.html/info/d323fe8c0930a5e850eabf3eb8991d717defe784?txt=1ln=114,116
Would that be better as:
SELECT pid FROM plink JOIN blob ON blob.rid=plink.cid
WHERE pid0 AND isprim AND
Thus said Richard Hipp on Mon, 27 Apr 2015 20:51:51 -0400:
FWIW, I created that index on Joerg's net-bsd repo and it made a Big
Improvement in performance there.
That's good to know. I'm currently downloading the repository, but it's
big and will be a while before I can test anything. I
Thus said Jan Nijtmans on Mon, 27 Apr 2015 23:41:22 +0200:
a)
https://www.fossil-scm.org/index.html/info/560483f50436c9f7
I would guess this is the problem, but I could be wrong. If no content
is synced, rcvid will be 0, which normally won't be a problem because
the only content that
Thus said Richard Hipp on Mon, 27 Apr 2015 20:28:26 -0400:
.timer on
That's excellent! I was wondering if sqlite's command line tool had a
profiling tool (having thought of Tcl's time as a useful profiling
feature).
I'll play around with this some to see what various results I get.
Creating index now...
1) This demonstrates (yet again) what a good choice sql was as the
high-level language to implement fossil
I think enough churn has happened that this isn't necessarily
conclusive (if i'd known of the fallout, I'd have had a pre-problem
snapshot of the repo set aside so I
Thus said bch on Mon, 27 Apr 2015 14:27:41 -0700:
1) On a large repo, this takes an inordinate amount of time. On a sync
(with no updates necessary), the runtime is ~45s (on the first
attempt, I stopped it after ~10 mins of running in order to re-run it
with a time(1) command to
On Sat, Apr 25, 2015 at 01:33:09PM -0700, Matt Welland wrote:
If a fork happens, merge it, change it into a branch or close it. There is
no need for a forks page. All that is needed is to keep developers
informed so the fork doesn't lie undetected and cause confusion.
I fully agree and I
On 4/25/15, Ron W ronw.m...@gmail.com wrote:
As for the usefulness of a /forks page (in addition to a fossil forks
command), Project Managers will find it a lot more useful than the CLI
command, just as they find the /timeline page a lot more useful than the
command.
Also, as a lead dev,
On 4/25/15, Matt Welland mattrwell...@gmail.com wrote:
There is no need for a forks page. All that is needed is to keep developers
informed ...
To my ears, those two sentences directly contradict one another.
The purpose of the web interface (at least the purpose for which it
was originally
On 25 April 2015 at 09:18, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said jungle Boogie on Fri, 24 Apr 2015 23:11:54 -0700:
Is there a /forks page on webUI?
Not yet, however, I have been meaning to add one which will show only
forks, similar to how the ``fossil leaves'' command
2015-04-25 18:38 GMT+02:00 Andy Bradford:
Yes, I would like this to be in ``testing'' sufficiently long to
actually encounter a fork through the normal course of activity. I
analyzed the historical fork count and it seems like there are 6 forks
per year on average in Fossil. We
If a fork happens, merge it, change it into a branch or close it. There is
no need for a forks page. All that is needed is to keep developers
informed so the fork doesn't lie undetected and cause confusion.
On Apr 25, 2015 11:35 AM, jungle Boogie jungleboog...@gmail.com wrote:
On 25 April 2015
On Sat, Apr 25, 2015 at 1:48 PM, Richard Hipp d...@sqlite.org wrote:
On 4/25/15, Matt Welland mattrwell...@gmail.com wrote:
There is no need for a forks page. All that is needed is to keep
developers
informed ...
To my ears, those two sentences directly contradict one another.
The
On Sat, Apr 25, 2015 at 9:50 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
Thus said Matt Welland on Sat, 25 Apr 2015 15:05:54 -0700:
Our preferred work style is to get feedback from the command line
where possible. If notified of a fork during update, sync or commit a
developer
On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland mattrwell...@gmail.com
wrote:
The expectation is that if a commit succeeds *it is a part of the series
of commits on that branch*. This expectation is valid in git, it is valid
in subversion, it is valid in DesignSync. It is not valid in Fossil.
Thus said Matt Welland on Sat, 25 Apr 2015 15:05:54 -0700:
Our preferred work style is to get feedback from the command line
where possible. If notified of a fork during update, sync or commit a
developer may resort to the UI to determine what happened but the fix
is done at the
On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland mattrwell...@gmail.com
wrote:
A fork is seen as a failure of fossil to handle a commit that requires
tiresome manual intervention to fix.
But, doesn't a blocked merge due to a pull that results in a fork require
significant manual intervention to
On Sat, Apr 25, 2015 at 10:20 PM, Ron W ronw.m...@gmail.com wrote:
On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland mattrwell...@gmail.com
wrote:
A fork is seen as a failure of fossil to handle a commit that requires
tiresome manual intervention to fix.
But, doesn't a blocked merge due to a
On Apr 25, 2015 8:57 PM, Ron W ronw.m...@gmail.com wrote:
On Sat, Apr 25, 2015 at 6:05 PM, Matt Welland mattrwell...@gmail.com
wrote:
The expectation is that if a commit succeeds *it is a part of the series
of commits on that branch*. This expectation is valid in git, it is valid
in
On 24 April 2015 at 22:35, j. van den hoff veedeeh...@googlemail.com wrote:
another idea: maybe `fossil info' could also include a warning line if there
are any forks at present?
Or /stat on webUI
But we already have `fossil forks' command, too. But perhaps exposing
it in more places is
Thus said jungle Boogie on Fri, 24 Apr 2015 23:11:54 -0700:
Is there a /forks page on webUI?
Not yet, however, I have been meaning to add one which will show only
forks, similar to how the ``fossil leaves'' command was extended to show
forks. Should this be a separate /forks URI or just a
Thus said j. van den hoff on Sat, 25 Apr 2015 07:35:01 +0200:
I believe having these warnings would be good and would opt for making
a field test whether it is well accepted or not in the fossil users
community.
Yes, I would like this to be in ``testing'' sufficiently long to
Thus said Ron W on Sat, 18 Apr 2015 14:19:16 -0400:
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?
Because a fork is only a fork if the branching happens
Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400:
Proposed solutions include denying the ability to commit or push a
fork. But doesn't that just make the problem worse?
Yes, I think it does make it worse; this is not a practical approach in
my opinion. I think it better to have
On Sat, 25 Apr 2015 03:03:50 +0200, Andy Bradford
amb-fos...@bradfords.org wrote:
Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400:
Proposed solutions include denying the ability to commit or push a
fork. But doesn't that just make the problem worse?
Yes, I think it does make
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 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 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
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
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:
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
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-fos...@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
2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger jo...@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-fos...@bradfords.org
...
I disagree. While it might be the most common case, merging does not
explicitly state any
On Fri, Apr 17, 2015 at 01:07:50PM +0200, Jan Nijtmans wrote:
2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger jo...@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-fos...@bradfords.org
...
I disagree. While it might
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 not
make that leaf not-a-leaf. So why should merging a fork-leaf
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
On Thu, Apr 16, 2015 at 1:38 AM, Jan Nijtmans jan.nijtm...@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.
2015-04-16 13:44 GMT+02:00 Matt Welland mattrwell...@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
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland mattrwell...@gmail.com
wrote:
On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2015-04-16 13:44 GMT+02:00 Matt Welland mattrwell...@gmail.com:
I'm confused by this. If the fork was merged to trunk it is no longer a
On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2015-04-16 13:44 GMT+02:00 Matt Welland mattrwell...@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
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
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland mattrwell...@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
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
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@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,
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,
On Thu, Apr 16, 2015 at 1:22 PM, Ron W ronw.m...@gmail.com wrote:
On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland mattrwell...@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
2015-04-14 5:46 GMT+02:00 Andy Bradford amb-fos...@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
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
On Tue, Apr 14, 2015 at 3:11 PM, Andy Bradford amb-fos...@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
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
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
On Mon, Apr 13, 2015 at 1:59 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2015-04-13 6:31 GMT+02:00 Andy Bradford amb-fos...@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
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
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).
2015-04-13 6:31 GMT+02:00 Andy Bradford amb-fos...@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
On Fri, Apr 10, 2015 at 2:16 PM, Matt Welland mattrwell...@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.
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
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
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-fos...@bradfords.org
wrote:
Thus said Matt Welland on Wed, 08 Apr 2015 22:39:36 -0700:
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: 40005526904a
On Thu, Apr 9, 2015 at 12:07 AM, Matt Welland mattrwell...@gmail.com
wrote:
On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford amb-fos...@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
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
On Thu, Apr 9, 2015 at 7:43 AM, Andy Bradford amb-fos...@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
Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:
matt@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
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
On Wed, Apr 8, 2015 at 9:39 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:
matt@xena:/tmp/testing$ fossil sync
Sync with file:///home/matt/fossils/blah.fossil
Round-trips: 1 Artifacts sent: 4 received: 0
Server says:
On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford amb-fos...@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
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:
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
On Wed, Apr 8, 2015 at 8:57 PM, Andy Bradford amb-fos...@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
On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford amb-fos...@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
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-fos...@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
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
On Tue, Apr 7, 2015 at 10:14 PM, Andy Bradford amb-fos...@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
On Wed, Apr 8, 2015 at 2:19 AM, Matt Welland mattrwell...@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
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
On 4/8/15, Matt Welland mattrwell...@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
On Wed, Apr 8, 2015 at 6:16 AM, Richard Hipp d...@sqlite.org wrote:
On 4/8/15, Matt Welland mattrwell...@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
On Wed, Apr 8, 2015 at 6:55 AM, Martin Gagnon eme...@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
On Mon, Apr 6, 2015 at 3:48 PM, Matt Welland mattrwell...@gmail.com wrote:
On Mon, Apr 6, 2015 at 10:05 AM, James Moger james.mo...@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
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
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
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
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
On Mon, Apr 6, 2015 at 12:27 PM, Matt Welland mattrwell...@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
1 - 100 of 116 matches
Mail list logo
