Re: Trimming old diffs to save space
Ed Avis <[email protected]>
| Newsgroups | gmane.comp.version-control.rcs.bugs,gmane.comp.version-control.cvs.bugs,gmane.comp.gnu.rcs |
|---|---|
| Message-ID | <[email protected]> |
I am writing a tool to strip out old revisions from an RCS file while leaving the log messages. This is purely to save disk space. I have been wondering what to write in the 'text' section that normally holds the deltas between revisions. Ideally I'd like something that looks plausible enough to make 'rlog' and 'cvs log' work, but causes an error when someone tries to check out a version that has been removed in this way. I'm crossposting this to the RCS and CVS lists because whatever I choose ought to work with both. As far as I know there is no standard description of the RCS file format, only the implementations of tools that use it. My first try was to make the diff empty, as text @ @ But neither rlog nor cvs log agree with this. Next I tried making an empty diff - delete zero lines: text @d1 0 @ But while CVS seems happy with this, rlog objects. Eventually I settled on a diff removing a huge number of lines: text @d1 999999 @ This seems to have the desired behaviour. I can do 'rlog' and 'co file', but trying to check out an older version gives an error such as co: aaa,v:8232: edit script refers to line past end of file Similarly with CVS I am able to log and get the latest version but not older versions. Checking in new revisions seems to be okay. So unless someone spots a flaw in this approach I will use it. I plan to make the tool do 'rlog', 'co', 'cvs log' and 'cvs update' on the trimmed file and check that the results are the same as the original, as a safeguard against losing data. So while the tool may have bugs, it should be safe to use if you're sure the current version and the log messages are all you need. I will post a separate announcement to the two lists when I have something ready to release. (ccing help-rcs to conclude the thread - please follow up to 'bug' lists since I think this is technical discussion rather than usage.) -- Ed Avis <[email protected]>