subject:"Re\: \[fossil\-users\] Two trunks\?"

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  collect info) on  a network run  that took
 ~1s.

What is a ``large repo?'' And why  would a sync that had no changes even
trigger a check for forks?

If you  are talking about  [560483f5], if  there was no  content synced,
then there should be nothing to  be checked because g.rcvid should be...
0? (unless perhaps  there is a bug). Maybe g.rcvid  is being initialized
to some strange value that just happens to cause problems.

Also, I tested [560483f5] with sync  agains every artifact in Fossil and
it  added no  significant overhead,  though,  perhaps the  SQL could  be
improved, it seemed fine to me.

Thanks for the report.

Andy
--
TAI64 timestamp: 4000553eb196
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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 that have  been resolved and those that have
 not.

I like it.  Works great here.

Thanks,

Andy
-- 
TAI64 timestamp: 4000553e91f0


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

Re: [fossil-users] Two trunks?

2015-04-27 Thread bch

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 a network run that took
~1s.

2) Do we not have a policy yet about dumping unratified code in
[trunk] ? If not, I vote please do not do this



On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
 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 that have  been resolved and those that have
 not.

 I like it.  Works great here.

 Thanks,

 Andy
 --
 TAI64 timestamp: 4000553e91f0


 ___
 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

Re: [fossil-users] Two trunks?

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. This code was
introduced to address that particular scenario. The goal was to continue
to allow forks (because there really are no good arguments for
disallowing forks), but provide advanced notification.

If user X pushes a fork they will get a warning at
(https://www.fossil-scm.org/fossil/info/0ab1e3f36?ln=2124).

Unless I'm mistaken, this warning does not happen on push, it happens on
commit. And sometimes that is not sufficient. For example, if they have
been working offline, the code above will not help. Or if they have
infrastructure in place (like Fossil has) where there are multiple
servers syncing content and subsets of developers commit against
different servers and the sync window allows enough time that autosync
does not help, this will warn them.

And if a fork somehow gets past that, it will be quickly detected by
(https://www.fossil-scm.org/fossil/artifact/df47f8f52ed?ln=225) which
is called from (https://www.fossil-scm.org/fossil/info/139cb78d7be?ln=547)
on every fossil update or fossil checkout.

This code will certainly help in the case where an update was done, but
if one uses ``fossil sync'', or is working on a branch, no warning is
given until later when someone decides to actually update to that
particular branch where the fork exists.

Cannot the code linked at (a) above simply be deleted?

If it is deemed too intrusive, or otherwise obsolete by other features,
certainly it should be. I still think there is some value to it,
especially for those who encounter forks quite frequently. If it is
kept, it definitely should not be a performance hit to the rest of us
who have forks less frequently.

Whether or not the code is kept, I have a question regarding the SQL...

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 rcvid=:rcvid

Or is that not necessarily a performance improvement?

Thanks,

Andy
--
TAI64 timestamp: 4000553ed011

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

Re: [fossil-users] Two trunks?

2015-04-27 Thread Richard Hipp

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 fork they will get a warning at
(https://www.fossil-scm.org/fossil/info/0ab1e3f36?ln=2124).  And if a
fork somehow gets past that, it will be quickly detected by
(https://www.fossil-scm.org/fossil/artifact/df47f8f52ed?ln=225) which
is called from (https://www.fossil-scm.org/fossil/info/139cb78d7be?ln=547)
on every fossil update or fossil checkout.

Cannot the code linked at (a) above simply be deleted?
-- 
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

Re: [fossil-users] Two trunks?

2015-04-27 Thread Richard Hipp

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 user 0.021606 sys 0.004903

On the other hand, if I create a new index:

CREATE INDEX blob_rcvid ON blob(rcvid);

Then the second is consistently faster than the first:

57482
Run Time: real 0.000 user 0.93 sys 0.30
---
57482
Run Time: real 0.000 user 0.38 sys 0.12

Creating that index might solve Brad's performance problem.  bch: can
you create the index shown above in your repo and see if the
performance becomes acceptable?


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

Re: [fossil-users] Two trunks?

2015-04-27 Thread Richard Hipp

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 rcvid=:rcvid

 Or is that not necessarily a performance improvement?


I ran the following test script:

.timer on
SELECT pid FROM plink WHERE pid0 AND isprim
   AND cid IN (SELECT blob.rid FROM blob
 WHERE rcvid=5112);
.print ---
SELECT pid FROM plink JOIN blob ON blob.rid=plink.cid
 WHERE pid0 AND isprim AND rcvid=5112;

(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 user 0.021606 sys 0.004903


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

Re: [fossil-users] Two trunks?

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  wonder how many
other queries  on large repositories  might be  improved by an  index. I
wonder what the tradeoff in size will be. Guess I'll find out once I get
this repository cloned.

I also think it  isn't even necessary to make such  checks if no content
was received. I  suspect that if rcvid=0 (e.g sync  had no content), and
if there are a lot of phantoms currently, the result of the subquery for
the IN() could result in a lot  of unnecessary churning on the CPU for a
result which we know will ultimately never have any rows:

https://www.fossil-scm.org/fossil/info/440ed5da095da581

Thanks,

Andy
-- 
TAI64 timestamp: 4000553edc8c


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

Re: [fossil-users] Two trunks?

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 has a rcvid  of 0 are phantoms and  they will not
show up in  plink, however, perhaps his repository has  a huge number of
phantoms and IN()  is expensive? In any  case, if rcvid is  0, the check
should just return 0 (or not be called at all).

Thanks,

Andy
--
TAI64 timestamp: 4000553eb64a
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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.

Thanks,

Andy
-- 
TAI64 timestamp: 4000553ed865


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

Re: [fossil-users] Two trunks?

2015-04-27 Thread bch

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 could faithfully recreate all
steps at whim), but anyway, here are my results after running the
index build on the backing netbsd_src.fsl.


kamloops$ fossil version
This is fossil version 1.32 [fc3d9f52ee] 2015-04-27 19:27:59 UTC
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 338  received: 1367  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
5.90 real 4.01 user 0.28 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
6.20 real 3.91 user 0.38 sys
kamloops$



Then I closed and re-opened the repo into my working dir (both those
(untimed) took quite a while), and re-running the pull:

kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
   19.96 real 3.93 user 0.49 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 338  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
6.95 real 3.95 user 0.28 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 336  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
5.69 real 3.89 user 0.32 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 338  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
5.92 real 3.95 user 0.26 sys
kamloops$


I think an interesting test will be tomorrow w/ the update to the
fossil mirror of the inevitable work that will happen in the canonical
CVS repo.

-bch

On 4/27/15, Richard Hipp d...@sqlite.org wrote:
 On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
 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.


 FWIW, I created that index on Joerg's net-bsd repo and it made a Big
 Improvement in performance there.

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

Re: [fossil-users] Two trunks?

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  collect info) on  a network run  that took
 ~1s.

Ok,  I  do see  a  potential  problem...  and  a potentially  easy  fix.
Basically,  if rcvid  is 0,  the  check should  just return  immediately
because there is nothing received to check.

Also, I wonder if IN() is the best query that can be made here:

https://www.fossil-scm.org/index.html/info/5b81c58a73eb36babedbc544e28e9ce75b354c1d?txt=1ln=113,115

How expensive is IN()?

Thanks,

Andy
--
TAI64 timestamp: 4000553eb599
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-26 Thread Joerg Sonnenberger

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 don't see how the leaves page with maybe a filter
option isn't already good enough for this purpose.

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

Re: [fossil-users] Two trunks?

2015-04-26 Thread Richard Hipp

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, myself,  there are times when it is easier to look at
 the timeline graph. This is usually when I need to make a quick summary of
 the state of the project.


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 that have been resolved and those that have
not.

https://www.fossil-scm.org/fossil/timeline?forks
https://www.sqlite.org/src/timeline?forks
http://core.tcl.tk/tcl/timeline?forks

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

Re: [fossil-users] Two trunks?

2015-04-25 Thread Richard Hipp

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 created) is to promote situational awareness.  The idea
is that a developer (or project manager or BDFL) can quickly glance at
a few pages and gain a good understanding of what is going on with the
whole project, on all its various branches.  Links are provided to dig
down into details as desired.  The intent is to help all participates
maintain an accurate mental model of the project and avoid tunnel
vision wherein they only see their little piece and miss the big
picture.

It seems to me that a page showing forks might well maintain
situational awareness.

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

Re: [fossil-users] Two trunks?

2015-04-25 Thread jungle Boogie

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 was extended to show
 forks. Should  this be a separate  /forks URI or just  a query parameter
 like /leaves?forks, or both?


I think it would be ideal to see a link for leaves and forks at /stat,
like we can for activity reports and sha1 collisions.

Separate pages may be better but probably a good idea to look to one another.
/leaves can have link to /forks and /forks links to /leaves

Only because some may not be aware of either page.

Although, /forks may not show anything for many projects, and if
that's the case, what would be shown on the page? no forks found?

 Andy
 --
 TAI64 timestamp: 4000553bbe81



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-25 Thread Jan Nijtmans

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 have had only 1 so far this year.

So, let's start testing:
 https://www.fossil-scm.org/index.html/info/560483f50436c9f7
Keep good comments coming .!

Thanks!
  Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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 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 was extended to show
  forks. Should  this be a separate  /forks URI or just  a query parameter
  like /leaves?forks, or both?
 

 I think it would be ideal to see a link for leaves and forks at /stat,
 like we can for activity reports and sha1 collisions.

 Separate pages may be better but probably a good idea to look to one
 another.
 /leaves can have link to /forks and /forks links to /leaves

 Only because some may not be aware of either page.

 Although, /forks may not show anything for many projects, and if
 that's the case, what would be shown on the page? no forks found?

  Andy
  --
  TAI64 timestamp: 4000553bbe81



 --
 ---
 inum: 883510009027723
 sip: jungleboo...@sip2sip.info
 xmpp: jungle-boo...@jit.si
 ___
 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

Re: [fossil-users] Two trunks?

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 purpose of the web interface (at least the purpose for which it
 was originally created) is to promote situational awareness.  The idea
 is that a developer (or project manager or BDFL) can quickly glance at
 a few pages and gain a good understanding of what is going on with the
 whole project, on all its various branches.  Links are provided to dig
 down into details as desired.  The intent is to help all participates
 maintain an accurate mental model of the project and avoid tunnel
 vision wherein they only see their little piece and miss the big
 picture.


That is a fine vision and indeed the fossil UI is much appreciated however
for many folks having to take the focus off the command line and the work
at hand to go explore the UI is an in-the-zone killer. 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 command line.

From reading the posts it seems quite a few people on this list either
perceive or experience forks differently that myself and others on my team.
A fork is seen as a failure of fossil to handle a commit that requires
tiresome manual intervention to fix. If I have to ask the team to poll the
UI to see if there was a fork my credibility and enthusiasm for fossil will
take another hit.

This is the scenario as the developers experience it, happening just often
enough in our very busy repositories to irritate people:

Developer A makes a commit. Excellent, all done with the task at hand.
Time passes.
Developer B runs update and does some work with the expectation that
Developer A's commit is there.
   Thinks don't work, confusion ensues, developer A is called in and asked
did you do the task?, he replies yes, committed yesterday
   they dig through the timeline and see the fork, merge it and we are back
to normal. But precious time was WASTED.

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.

By all means add a forks page to fossil. Perhaps it will be useful to some
but I merely responded to this thread to ensure that anyone putting effort
into this was aware that adding that feature adds zero value to solving my
problem.

To be redundantly clear. If I have to poll the timeline or some /forks page
to determine that I've borked up my repo (yes, a fork is that bad) then
fossil is not a viable tool for a corporate environment where developers
time is $$.

There is NO valid reason for a fork to persist in a repo. Fixing a fork is
TRIVIAL, merge it, close it or rename it to a new branch name. At issue
here is that forks are often NOT apparent. Make them adequately apparent
and in your face and this limitation of fossil is tolerable.


 It seems to me that a page showing forks might well maintain
 situational awareness.

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

Re: [fossil-users] Two trunks?

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 may resort to the UI  to determine what happened but the fix
  is done at the command line.

 While the change is  not yet in an official release  (it's now merged to
 trunk, but  definitely in ``testing''  mode), would you mind  trying the
 latest to see how it works in your environment:

 http://www.fossil-scm.org/index.html/info/560483f50436c9f7


Yes, we'll test this early next week. Thanks.



  From reading the posts it seems quite a few people on this list either
  perceive or experience forks differently  that myself and others on my
  team.

 Perhaps because we  have not experienced the large number  of forks that
 you are  encountering. The last  time I checked,  there were not  yet 80
 forks in Fossil  in it's entire not  yet 8 years of  existence. Not very
 many to be sure. How many do you have in 1 day? 1 week? 1 month?


Several a week in one repository, close to one a day until we restructured
the repo to reduce the incidence (among other reasons). Ironically that is
less problematic (time consuming and annoying perhaps, but not troublesome)
than some of the other repos where it might be a few a year. If they happen
regularly then the developers get sensitized to the problem and are on the
look out for it. Where it is rare, when one happens it can be a serious
problem if no one catches it.

 A fork is seen as a failure of fossil to handle a commit that requires
  tiresome manual intervention to fix.

 Perhaps because the  person who committed the fork was  not aware of it,
 nor was anyone else? If someone had  been alerted to the presence of the
 fork, would it have  been dealt with when it happened?


Yes, and this is precisely why I feel so strongly that fossil should be
quite aggressive about warning users about forks. Most forks take under 30
seconds to fix. They really are a major problem only when they happen
silently. In another post I provided a script that I believe replicates the
scenario where forks are being silently created (inserted below). As I
recall neither party gets notified when a fork happens due to this scenario.

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


Thanks,

 Andy
 --
 TAI64 timestamp: 4000553c6ec8


 ___
 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

Re: [fossil-users] Two trunks?

2015-04-25 Thread Ron W

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.


Regarding Git, if core dev 1 pulls changes from contributor A while core
dev 2 is pulling changes from contributor B, any fork caused by the
combined activities of A and B won't be detected until 1 or 2 tries to sync
with the other. Granted, that sync will fail, but from the perspective of A
and B, their commits already succeeded.


 If I have to poll the timeline or some /forks page to determine that I've
 borked up my repo (yes, a fork is that bad) then fossil is not a viable
 tool for a corporate environment where developers time is $$.


Nobody is suggesting that it's an either-or--not-both choice,

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, myself,  there are times when it is easier to look at
the timeline graph. This is usually when I need to make a quick summary of
the state of the project.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-25 Thread Andy Bradford

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 command line.

While the change is  not yet in an official release  (it's now merged to
trunk, but  definitely in ``testing''  mode), would you mind  trying the
latest to see how it works in your environment:

http://www.fossil-scm.org/index.html/info/560483f50436c9f7

 From reading the posts it seems quite a few people on this list either
 perceive or experience forks differently  that myself and others on my
 team.

Perhaps because we  have not experienced the large number  of forks that
you are  encountering. The last  time I checked,  there were not  yet 80
forks in Fossil  in it's entire not  yet 8 years of  existence. Not very
many to be sure. How many do you have in 1 day? 1 week? 1 month?

 A fork is seen as a failure of fossil to handle a commit that requires
 tiresome manual intervention to fix.

Perhaps because the  person who committed the fork was  not aware of it,
nor was anyone else? If someone had  been alerted to the presence of the
fork, would it have  been dealt with when it happened?

Thanks,

Andy
-- 
TAI64 timestamp: 4000553c6ec8


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

Re: [fossil-users] Two trunks?

2015-04-25 Thread Ron W

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 resolve?

It's all well and good to say that it is the responsibility of the
contributor to re-base and submit again. But the core dev who initially
accepted the contribution has to somehow un-merge that contribution from
her local repo.

Adding to what Andy pointed out, I would say that the problem was more that
there was not sufficient notification of the fork than that the fork
occurred.

I suspect that if the fork had been noticed immediately, the effort to
resolve would not have been as significant as when discovered later.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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 pull that results in a fork require
 significant manual intervention to resolve?

 It's all well and good to say that it is the responsibility of the
 contributor to re-base and submit again. But the core dev who initially
 accepted the contribution has to somehow un-merge that contribution from
 her local repo.

 Adding to what Andy pointed out, I would say that the problem was more
 that there was not sufficient notification of the fork than that the fork
 occurred.

 I suspect that if the fork had been noticed immediately, the effort to
 resolve would not have been as significant as when discovered later.


By tiresome here I mean only that it is tedious due to being work that
adds no value per se. Almost all forks are trivially corrected with fossil
merge;fossil commit -m fixed-fork.

In fact it is so mechanical that 99/100 forks could be fixed by something
like:

for b in $(fossil branch|tr '*' ' ');do
  fossil up $b
  fossil merge
  fossil commit -m fixed-fork
done

:)




 ___
 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

Re: [fossil-users] Two trunks?

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 subversion, it is valid in DesignSync. It is not valid in Fossil.


 Regarding Git, if core dev 1 pulls changes from contributor A while core
dev 2 is pulling changes from contributor B, any fork caused by the
combined activities of A and B won't be detected until 1 or 2 tries to sync
with the other. Granted, that sync will fail, but from the perspective of A
and B, their commits already succeeded.

True. My context is in terms of a star centralized topology. With git,
developers cannot create forks in central. I still believe this is a
superior methodology choice to what fossil is doing. I have no concerns
about developers dealing locally with forks or if they sync to each other
and create forks. I think the grief comes from forks in central
repositories.



 If I have to poll the timeline or some /forks page to determine that
I've borked up my repo (yes, a fork is that bad) then fossil is not a
viable tool for a corporate environment where developers time is $$.


 Nobody is suggesting that it's an either-or--not-both choice,

 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, myself,  there are times when it is easier to look
at the timeline graph. This is usually when I need to make a quick summary
of the state of the project.

Yes, I agree with both these points.



 ___
 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

Re: [fossil-users] Two trunks?

2015-04-25 Thread jungle Boogie

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 better than more likely-to-be ignored
warnings...or is it the same thing? ;)

Is there a /forks page on webUI?

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-25 Thread Andy Bradford

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 query parameter
like /leaves?forks, or both?

Andy
--
TAI64 timestamp: 4000553bbe81
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-25 Thread Andy Bradford

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
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 have had only 1 so far this year.

 at a few places  there might be a suboptimal signal  to noise ratio in
 the  default output  and the  relevant ones  like failure  to sync  or
 detected forks should stand out sufficiently.

I can  certainly see how  the 8 lines  of output that  ``fossil update''
produces on a  no-change update could be considered  overly verbose. I'm
not sure what others would  think about changing the output. Personally,
I don't mind  the additional information that it  currently displays and
find it useful.

 another idea: maybe `fossil info' could also include a warning line if
 there are any forks at present?

Hard  to say  if this  would tip  the balance.  It seems  to me  that if
someone  wants  to  know  about  forks, they  can  already  obtain  this
information via ``fossil forks.''

Thanks,

Andy
--
TAI64 timestamp: 4000553bc31b
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-24 Thread Andy Bradford

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 in  the same
branch.

Merging from a branch to a  different branch does not cancel the branch,
nor does  it create  a fork,  and there is  still a  leaf on  the branch
against which checkins  are allowed without any constraints,  and a leaf
in the other branch.

With a fork,  however, after you have  merged it, there are  no longer 2
leaves and attempts to checkin changes  against either of the nodes that
were merged will  result in failure as it will  create yet another fork.
Only if --allow-fork is included will  it be possible to checkin against
a merged fork,  but then, you have  a new fork, not a  continuation of a
previous fork.

Thanks,

Andy
-- 
TAI64 timestamp: 4000553adcf3


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

Re: [fossil-users] Two trunks?

2015-04-24 Thread Andy Bradford

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 the  fork and receive  a warning
about it, or see it in the timeline than deny it.

 We've  already established  that users  are in  the habit  of ignoring
 scary fork warnings.

If they've seen them. They may not be seeing them due to infrastructure.
E.g. User1 syncs to site1.dom and  User2 syncs to site2.dom, where there
is a 10 minute synchronization delay between site1.dom and site2.dom. If
User1 and  User2 checkin  against the  same leaf  within that  10 minute
window, currently neither will get a warning about forks.


 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.

I too  was worried about  warning fatigue. It  should warn as  little as
possible.  How  to achieve  that,  while  also providing  more  advanced
warning to those who want it is a difficult challenge.

I also am not fond of computer programs that behave as if they know more
than I do; this is one of the reasons why I prefer Fossil over Git. :-)

Regarding the balance for fork warnings,  where there seems to be a high
volume of  forks, will additional  notification help prevent  the forks?
Probably not because a fork is  something that has already occurred, but
it might  help them be  resolved more quickly  as they will  be detected
sooner. Specifically,  I'm talking about  the kind of fork  that happens
silently that goes  undetected for whatever reason. For  a project where
fork volume is low, will more notifications be a hindrance?

I've sought to create a balance  in the sync-forkwarn branch between the
frequency of the nag and when to nag.  For example, it will not nag on a
clone---what's the point? It also won't  nag if the artifact received is
part of a fork  previously existing in the clone (again,  no need to nag
continuously  about a  checkin against  a  fork that  should already  be
known). But it will nag if you receive an artifact that has caused a new
fork in your clone. The first person  to generate a fork will be the one
to get the  first notification, and if they address  it, no other people
will be notified.

Are  these  changes reasonable?  Does  it  fit the  parsimoniousness  of
Fossil? Or is it too much?

How  many   forks  in   Fossil  were   done  intentionally   (e.g.  with
--allow-fork)? How many were unintentional  and would have been resolved
more  quickly  had a  warning  been  issued at  the  time  the fork  was
synchronized?

Thanks,

Andy
-- 
TAI64 timestamp: 4000553ae819


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

Re: [fossil-users] Two trunks?

2015-04-24 Thread j. van den hoff

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 it  worse; this is not a practical approach in
my opinion.  I think it  better to have the  fork and receive  a warning
about it, or see it in the timeline than deny it.


We've  already established  that users  are in  the habit  of ignoring
scary fork warnings.


If they've seen them. They may not be seeing them due to infrastructure.
E.g. User1 syncs to site1.dom and  User2 syncs to site2.dom, where there
is a 10 minute synchronization delay between site1.dom and site2.dom. If
User1 and  User2 checkin  against the  same leaf  within that  10 minute
window, currently neither will get a warning about forks.



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.


I too  was worried about  warning fatigue. It  should warn as  little as
possible.  How  to achieve  that,  while  also providing  more  advanced
warning to those who want it is a difficult challenge.

I also am not fond of computer programs that behave as if they know more
than I do; this is one of the reasons why I prefer Fossil over Git. :-)

Regarding the balance for fork warnings,  where there seems to be a high
volume of  forks, will additional  notification help prevent  the forks?
Probably not because a fork is  something that has already occurred, but
it might  help them be  resolved more quickly  as they will  be detected
sooner. Specifically,  I'm talking about  the kind of fork  that happens
silently that goes  undetected for whatever reason. For  a project where
fork volume is low, will more notifications be a hindrance?

I've sought to create a balance  in the sync-forkwarn branch between the
frequency of the nag and when to nag.  For example, it will not nag on a
clone---what's the point? It also won't  nag if the artifact received is
part of a fork  previously existing in the clone (again,  no need to nag
continuously  about a  checkin against  a  fork that  should already  be
known). But it will nag if you receive an artifact that has caused a new
fork in your clone. The first person  to generate a fork will be the one
to get the  first notification, and if they address  it, no other people
will be notified.

Are  these  changes reasonable?  Does  it  fit the  parsimoniousness  of
Fossil? Or is it too much?

How  many   forks  in   Fossil  were   done  intentionally   (e.g.  with
--allow-fork)? How many were unintentional  and would have been resolved
more  quickly  had a  warning  been  issued at  the  time  the fork  was
synchronized?


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. regarding 'notification overload'. I always found and still  
find part of the regular fossil output to verbose.
e.g. doing a `fossil up' when already in sync with the server (with  
autosync on) one gets 8 lines of output the only two being really relevant  
being the one confirming that pulling is under way and the 'changes' linen  
stating that nothing has changed.


and probably the average user will not care how many artifacts have been  
sent or received but only would like to see some sort of progress feedback  
I presume. what I mean is: at a few places there might be a suboptimal  
signal to noise ratio in the default output and the relevant ones like  
failure to sync or detected forks should stand out sufficiently.


another idea: maybe `fossil info' could also include a warning line if  
there are any forks at present?


thx/j



Thanks,

Andy



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-18 Thread 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 mattrwell...@gmail.com
wrote:



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

Re: [fossil-users] Two trunks?

2015-04-18 Thread Matt Welland

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

Re: [fossil-users] Two trunks?

2015-04-18 Thread 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
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

Re: [fossil-users] Two trunks?

2015-04-18 Thread Kees Nuyt

[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
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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-18 Thread 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-18 Thread 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-18 Thread j. van den hoff


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 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/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-18 Thread Scott Robison

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 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-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-18 Thread Matt Welland

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: 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:

matt@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:

Re: [fossil-users] Two trunks?

2015-04-18 Thread bch

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 investigate and resolve by the existing abilities we already have. I
think fossil has done a reasonable(ish) job staying simple, and I think
that will be the key to it's continued success.
On Apr 18, 2015 6:53 AM, 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 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
 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

Re: [fossil-users] Two trunks?

2015-04-17 Thread 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-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, 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-17 Thread Jan Nijtmans

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 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-17 Thread 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 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 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-17 Thread Ron W

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 to whatever
make the fork-leaf not a fork?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-16 Thread 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-16 Thread Matt Welland

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

Re: [fossil-users] Two trunks?

2015-04-16 Thread Jan Nijtmans

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 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=100r=dg-misc
https://fossil-scm.org/index.html/timeline?n=100r=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-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-16 Thread Ron W

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
 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=100r=dg-misc
 https://fossil-scm.org/index.html/timeline?n=100r=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-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


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

Re: [fossil-users] Two trunks?

2015-04-16 Thread Matt Welland

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 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=100r=dg-misc
 https://fossil-scm.org/index.html/timeline?n=100r=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-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

Re: [fossil-users] Two trunks?

2015-04-16 Thread 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 tagtype0)   AND 
(SELECT value FROM tagxref   WHERE tagid=8 AND rid=1 AND tagtype0) = (SELECT 
value FROM tagxref   WHERE tagid=8 AND rid=leaf.rid AND tagtype0) 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: 400055300619
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-16 Thread Ron W

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 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-16 Thread 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: 400055306bbf


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

Re: [fossil-users] Two trunks?

2015-04-16 Thread Ron W

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, 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-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-16 Thread 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: 400055305312


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

Re: [fossil-users] Two trunks?

2015-04-16 Thread Matt Welland

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

Re: [fossil-users] Two trunks?

2015-04-14 Thread Jan Nijtmans

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

real27m21.480s
user1m18.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 *

real25m49.494s
user1m18.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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-14 Thread 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: 4000552d667a
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-14 Thread Ron W

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  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-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-14 Thread 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 ronw.m...@gmail.com wrote:

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

Re: [fossil-users] Two trunks?

2015-04-13 Thread 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-fos...@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: 4000552bdff7
 ___
 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

Re: [fossil-users] Two trunks?

2015-04-13 Thread Matt Welland

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

Re: [fossil-users] Two trunks?

2015-04-13 Thread 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: 4000552c8dca


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

Re: [fossil-users] Two trunks?

2015-04-13 Thread 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=25y=allv=0c=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: 4000552c8ccd


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

Re: [fossil-users] Two trunks?

2015-04-13 Thread Jan Nijtmans

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 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-13 Thread Ron W

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.


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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-13 Thread 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: 4000552bdff7
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-12 Thread 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: 4000552b46a9


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

Re: [fossil-users] Two trunks?

2015-04-09 Thread 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-fos...@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: 4000552615c3


 ___
 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

Re: [fossil-users] Two trunks?

2015-04-09 Thread 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: 40005526904a


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

Re: [fossil-users] Two trunks?

2015-04-09 Thread Ron W

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
  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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-09 Thread 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: 4000552615c3


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

Re: [fossil-users] Two trunks?

2015-04-09 Thread Matt Welland

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 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: 40005526904a


 ___
 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

Re: [fossil-users] Two trunks?

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 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: 4000552602a5


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

Re: [fossil-users] Two trunks?

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: 40005525f727


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

Re: [fossil-users] Two trunks?

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: ** 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
#
matt@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
#
matt@xena:/tmp/testing$ fossil co 0c74
Blahfoo
matt@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: 4000552602a5


 ___
 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

Re: [fossil-users] Two trunks?

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 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!
#
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 occurred **
Round-trips: 1   Artifacts sent: 4  received: 0
Sync done, sent: 618  received: 467  ip:

# No messages on update
#
matt@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
#
matt@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)
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://amb@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: 40005525ceb8


 ___
 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

Re: [fossil-users] Two trunks?

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://amb@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: 40005525ceb8


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

Re: [fossil-users] Two trunks?

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: 40005525e212


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

Re: [fossil-users] Two trunks?

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 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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
  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: 400055248f46


 ___
 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

Re: [fossil-users] Two trunks?

2015-04-08 Thread 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-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
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=1ln=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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-08 Thread 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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 (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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

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
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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-08 Thread 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

2015-04-08 Thread Richard Hipp

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

Re: [fossil-users] Two trunks?

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

Re: [fossil-users] Two trunks?