"Ph. Marek" <philipp.marek@bmlv.gv.at> writes:
> I've got a feature request for svnadmin.
> I'd like to have another commandline option with dump which tells svnadmin
> *not* to dump the file's contents, but their size, properties and the
> structure of the repository.
>
> I envision changing the current header for files from eg.
> Node-path: trunk/test
> Node-kind: file
> Node-action: add
> Prop-content-length: 50
> Text-content-length: 98
> Text-content-md5: 05632196ed92f9120d5ab80f46366671
> Content-length: 148
> to
> Node-path: trunk/test
> Node-kind: file
> Node-action: add
> Prop-content-length: 50
> Text-content-length: 0
> Real-text-content-length: 98
> Text-content-md5: 05632196ed92f9120d5ab80f46366671
> Content-length: 50
> ie. discard the text-content from the dumped data, and include another telling
> the real size of the file.
>
> I'd like this feature because it's easy to analyse a repository by dumping;
> but for my analyses I wouldn't need the text-contents; they'd just slow me
> down (especially for big files over slow links, eg. ssh).
I like the feature -- 'svnadmin dump --quiet' ? :-)
In your example above, you set the existing
Text-content-length: 0
to zero, and then added a new header with the old length:
Real-text-content-length: 98
What was wrong with 'Text-content-length'?
Is the issue one of compatibility, that is, you don't want to produce
a dumpfile whose headers are those of a normal dumpfile, but whose
contents are missing, because that might cause a load error? It's no
big deal if the loader errors. The effect on the repository will be
the same either way, so it doesn't really matter.
People know what kind of dumpfiles they produced, and probably won't
be loading these. IMHO it would be better to add a new boolean header
indicating that the contents are missing, and possibly up the dumpfile
format version number.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 8 16:29:47 2004