Thus said Charles Curtit on Sat, 16 Aug 2014 20:56:48 -0000: > If I do it this way, do all modifications done by users of a satellite > office get to be seen as modifications of only the one user defined in > the central office for that satellite ?
The username that is used when the checkin is made is recorded in the manifest of the change being committed: http://www.fossil-scm.org/index.html/doc/tip/www/fileformat.wiki#manifest This username is the current username on in the local clone, not the sync user that is used when communicating to the remote site (by default they are the same, but nothing prevents it from being different). Once committed, it is not alterable, but it can be superceded with a special tag, but the original user will still be present in the manifest of the artifact. This user actually does not even need to be a Fossil user per se (in the database). For example, I could have a Fossil username of jack, but in my local clone of Fossil I configure the checkin user to be jill. All commits would have jill in them. The server to which I synchronize will record in it's database which Fossil user was used to sync the content and this can be seen in the checkin through the Fossil ui. So in your satellite/centrol repo model, your central server would record changes as coming from all the satellite sync users. And each satellite server would record changes as coming from the actual satellite users that are in their databases. However, all checkins would have the actual user in their manifest, and it is unalterable. > The purpose of satellite servers is for speeding up access for > satellite users, and reducing satellite to central office bandwidth. Ok, so it's more about bandwidth control than it is about keeping users from committing to places that they shouldn't. Seems like your approach should work. > It would be a pain in the arse if one was to do that [huge commits], > but I can advise people not to do that, and have a backup procedure in > place to simply revert everything to a date prior to the repo > bombarding, if it ever happens. Fossil was designed to keep history of all commits forever. Even if you were to replace the central repository and all satellite repositories with a backup, all the clients who have committed those changes would eventually push them back into the satellites the next time they sync. So, not only would you have to revert all the core repositories, you would have to revert all clones, everywhere, that might potentially have that huge commit. The only way to completely wipe out content from Fossil is via shunning: http://www.fossil-scm.org/index.html/doc/tip/www/shunning.wiki Even that may not actually wipe it out from all clones, however, as long as you leave the shun in place on the central repos, those clones will not be able to push the content again to the central repos. Andy -- TAI64 timestamp: 4000000053efca15 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
