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: 400000005526904a > > > _______________________________________________ > 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
