On Sat, Mar 5, 2011 at 8:59 PM, Richard Hipp <[email protected]> wrote: > (1) The synchronization module has no understanding of checkins, branches, > forks, and whatnot. Giving it that knowledge would be an undesirable > mingling of what is now completely separate functionality.
Maybe have a call from the sync module to the other module that handles this? That would eliminate the knowledge sharing. > (2) Who's to say that fork wasn't intentional. Maybe a user deliberately > forked. Should this cause a warning? The documentation for commit states that using the --force (or -f) option is required to create a fork. That implies that creating a fork requires a deliberate action. True, a distributed VCS unavoidably creates unplanned forks. Seems to me (and my coworkers) that an unplanned fork should be treated as conflict. > (3) The difference between a fork and a branch is all in the tags, which > might arrive at a later time. Should the warning be retracted if the tag > arrives late? "Opps - that fork I warned you about earlier - it was really > a branch - Sorry!" What if a tag gets cancelled. "Hey! That branch over > there just turned into a fork!" Probably sufficiant to only warn when created. > (4) Forks are plainly evident on the timeline. If you have any interest in > the project, you should already be looking at the timeline on a regular > basis. You'll see any forks then. Isn't that sufficient notification. In a project with a lot of activity, a fork could still be overlooked. And while we all know that daily change control meetings should be held, the pressures of "it's just software, why wasn't it done yesterday?" all too often mean that software team internal meetings get skipped. (The worst part is that the question is usually followed by "After all, we did have a meeting on it yesterday.") _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
