Hi Stefan,
Stefan Sperling writes:
> If these revision properties aren't set on the original repository,
> you should not include them in the dump.
>
> synsync creates these revision properties, but svnrdump should not.
>
> I think you should query the actual revprop values using the RA API
> (if possible), rather than using fixed values passed into this function.
> Though maybe a better fix is to make the replay API replay any revision
> properties that exist on revision 0?
I suspect everyone has different thoughts in their heads. I'll clarify
what I'm thinking as a first step: To answer why does svnsync create
revision 0, we must analyze what revision 0 is; it is created as soon
as `svnsync init` is called and contains the following information:
svn:sync-from-url - it's clear why svnsync needs this. After the
`init`, subsequent calls to `sync` needs this information, but isn't
given it explicitly.
svn:sync-currently-copying and svn:sync-last-merged-rev - `sync` needs
to know how many revisions to copy.
svn:sync-from-uuid - I'm not sure why svnsync NEEDS this, but I
suppose it's just for completeness/ elegance.
svn: date - I'm guessing that this is the date the repository was
created, as opposed to the date of the original checkin. This should
be possible to get via the RA API I think, althought I haven't figured
out how.
I think svnrdump should include all these headers as we might want to
feature "resume" dumping to an existing dumpfile without explicitly
specifying the URL. Besides, there's no harm in including them and we
can just re-use the tests from svnsync.
-- Ram
Received on 2010-07-23 11:40:32 CEST