[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:mergeinfo and repository dumpstream handling

From: Daniel L. Rall <dlr_at_collab.net>
Date: 2007-10-22 19:00:03 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.