On 12/10/2012 10:53 AM, C. Michael Pilato wrote:
> What if we revved the svn_ra_replay_range() API in such a way that it could
> now handle this "initial revision" scenario? We might add an 'incremental'
> flag that parallels what 'svnadmin dump' and 'svnrdump dump' do. This would
> get us to a single RA API used for revision replays (replay_range, instead
> of a combination of do_update + replay_range), which simplifies how replays
> are done from an API perspective. Of course, under the hood, the RA
> implementations of the new replay_range2() would probably just use the same
> update mechanics to handle that initial revision when not in incremental
> mode, but ra_serf's particular implementation would be free to choose
> "send-all" mode in this one scenario to do exactly that.
Well, this turns out to be a little more sticky than I'd hoped.
It's easy enough to add a "send_complete_start_revision" flag to
svn_ra_replay_range() which causes the first transmitted revision to be a
full dump of the tree as of that revision. But the svn_ra_replay_range()
API also allows folks to specific whether they want *real* content change
information, or just placeholder notifications for modified file content and
node properties. Seems kinda yucky to transmit a full tree snapshot when
the caller has asked not to get any real content mods; and we don't have a
readily available way to send a full tree snapshot sans real content.
Those technical challenges aside, I've since started to doubt the wisdom of
adding special treatment of the starting revision to this API anyway. I'll
continue pondering other options.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-12-11 21:30:35 CET