 |
 |
Dear All, I fully agree with Wayne. W'd need an implementation change first. Using keys for intra-file links would slow the I/O down, and it is slow enough already. A persistent ID could be done at the cost of one more storage slot per object and some more tweaking every time you create an object. Plus, of course, any added work, slowing down, etc to set up the CVS. With our current workload and schedule I am not sure if we will get round to it - it will certainly not be soon. Yours, Rasmus On Mar 29 2007, Wayne Boucher wrote: > Hello, > > Rasmus is the expert on this and the XML format is going to change > slightly in the next major release of the API. But I think diffs would > not work that well in the current implementation because all the objects > internal to a specific package are given an ID in the XML file to make > reading the file quicker, and those IDs are created on the fly afresh each > time. I guess we could have an alternative implementation where the IDs > are remembered at read time and then reused when the file is saved. (Note > that links between files are handled by key, so are less of an issue > funnily enough.) Whether we would want to add the extra functionality to > cater for using the diffs (and backtracking if desired) is another > question! > > Wayne > > On Wed, 28 Mar 2007, Mark Girvin wrote: > > > Would there be any possibility or benefit of using (or integrating) a > > lightweight revision control system for the xml files? My vague > > recollection is that only differences are stored, so total filespace > > would grow (moderately) slowly - and one could go back to multiple > > points in a project. - Mark > > > > > > On Wed, Mar 28, 2007 at 05:49:27PM +0100, Wayne Boucher wrote: > > > I agree (see my email which crossed yours in the post). If people > > > had some alternative big disk for backup (and who does?) that would > > > help. Alternatively possibly we could just gzip everything (XML is > > > over verbose so gzip works well on it). > > > > > > Wayne > > > > > > On Wed, 28 Mar 2007, Johnny Eugene Croy wrote: > > > > > > > Martin, > > > > > > > > In regards to this problem that you described in which backups are > > > > sometimes inconvinent, I suggested to Tim that a good idea would be > > > > to have an option for an incremental backup scheme, where each > > > > backup point is written to a distinct file. For example, backup #1 > > > > would be written to a file called backup_001.xml and backup #2 > > > > would be written to a file called backup_002.xml, etc. > > > > > > > > This was a nice feature that I miss from the ANSIG days, but Tim > > > > brought up a good point that each backup is a big file and people > > > > not aware of this would quickly fill up a hard drive and then run > > > > into more serious problems. Still, I think that it would be good > > > > for people who would like to use the backup feature and have some > > > > sort of way to go back in time after making a mistake or realizing > > > > that something was done wrong. > > >