Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
Gerhard Fiedler wrote: > To me, it would only be confusing if the order got lost, e.g. if you ended > up with 1.12, 1.332, 1.47. We use steadily increasing identifiers for everything. Even on a 32bit database there's 4 billion of them before you wrap - you'd run out of disk space long before you ran out of identifiers. > OTOH, currently the (missing) numbers reveal that someone has deleted > revisions. This wouldn't be obvious anymore, so there should be some record > of deleted revisions left. The vfs doesn't support revision deletion at all at the moment ('delete' merely marks an object as deleted from that moment - no data is lost, and there's no option to change historical revisions at all) and I'm not entirely sure it should - tends to go against the use of version control. Of course there's nothing to stop someone writing an SQL script to do it provided they didn't break the integrity of the data. Since different schemes can be used for the deltas (it's pluggable) for the large file problem you could write one that stored them somewhere else rather than the database, if it was needed. Tony