On Sun, 21 Oct 2007, C. Michael Pilato wrote:
> While at SubConf last week listening to a talk, a thought crossed my mind.
> I scribbled the following onto a notepad:
>
> Realization: svndumpfilter will not filter out svn:mergeinfo that
> points to filtered locations. Problem?
>
> I then handed the pad to Karl, who (with all the glory and power of the
> written word) replied:
>
> Maybe, yes
This sounds like a "nice to have". We're already leaking authz-blocked
merge source paths via svn:mergeinfo. While the filtered paths are indeed
extraneous, they shouldn't cause any actual problem (even if such a path is
added down the road in a subssequent revision).
> Before I forget about this exchange or lose this little scrap of paper, I
> wanted to share it with the list. I think svndumpfilter needs to learn to
> modify the svn:mergeinfo property. And it's not just about removing
> references to now-missing paths -- it's also about touching up mergeinfo in
> light of now-dropped revisions.
This is a borderline blocker. If a dumpfilter removes revision numbers, we
absolutely have to adjust the mergeinfo accordingly.
> Oh, and what about the load process? We've talked in the past about whether
> or not 'svnadmin load' should create mergeinfo where none exists for copy
> operations. But should it also fudge mergeinfo revisions to deal with
> offsets caused by loading into a non-empty repository? Should it fudge
> mergeinfo sources that are different due to loading with --parent-dir?
Yes and yes.
Each of these items needs a corresponding issue in the tracker.
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Mon Oct 22 19:00:24 2007