On Thu, May 19, 2011 at 3:08 AM, Stephan Beal <sgb...@googlemail.com> wrote: > On Thu, May 19, 2011 at 7:03 AM, Nico Williams <n...@cryptonector.com>wrote: >> How does one remove changesets? How does one collapse deltas? > > Fossil doesn't allow one to remove changesets (and i'm not sure what > collapsing deltas means, unless it means to compound multiple changes into > one delta, in which case fossil can't do that). Once its in a fossil db, its > "fossilized" - there forever. Fossil offers a "shun" feature to "disable" > unwanted artifacts, but has (by design) no way to remove them.
Back when I worked for Sun Microsystems (then acquired by Oracle) we used to collapse deltas _prior_ to pushing them from personal repositories to project or product repositories. The reason for this is that one might commit N deltas during development that are of no interest to anyone else. Obviously no deltas were deleted or collapsed in the trunk. I think that's a very good policy. We did that with Teamware, Mercurial, and git (and probably other VCSs, but those are the three I used most at Sun). > Regarding the autosync feature Richard mentioned: if you work on more than > one machine on the same repo then i highly recommend leaving autosync on (at > least most of the time). If it is turned off and you forget to manually > push/pull from one of your machines, it can easily lead to an unintentional > fork (been there, done that many times). I agree that it seems useful, but since I was cloning the SQLite3 tree and since I don't have committer access, it seemed odd that Fossil would attempt to push my commits. Thanks, Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
