Thanks bytevolcano, in a way yes, I was thinking about the user table only at the time. I was going to use fossil for a project I'm working on but it wouldn't strictly be used as a SCM at all, and it would require for me to enable user self registration, which opened more doors about how I would have to respond to GDRP and bots flying pass text captcha and filling the database with all sorts of nonesense. I moved on from fossil now to using nginx + wapp for my project.
On Thu, May 17, 2018 at 2:42 PM, <[email protected]> wrote: > I think Peter is referring to deleting users from the "user" table. > > Fossil keeps the commit history forever, and each manifest has the name > of the user that made the commit. In the database, this is recorded in > the user column of the "event" table as the name of the user that made > the commit. > > The only thing that refers to the UID, that may present an issue, is the > "rcvfrom" table. This can easily be changed to use the user name > rather than the UID. > > There is no reason why users cannot be deleted from the "user" > table, since the user names would still show up in the history even if > users were deleted from this table. > > On Tue, 15 May 2018 15:41:53 +0300 > Victor Wagner <[email protected]> wrote: > > > Fossil keeps history forever. How would it do so, if author of some > > commits or wiki edits disappears from the repository completely. > > > > Disable access, revoke privileges, but keep the user in the DB, > > because it has log of his activity. > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
