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