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
