Re: Proposal to implement get_commit_and_merge_ranges from FS

On Jan 26, 2008 10:08 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
>
> > If we changed our mergeinfo handling to not merge changes to the
> > mergeinfo property and instead just record direct mergeinfo, then we
> > could get the information you need by doing a property diff for that
> > revision. Right? Code we already have somewhere.
> >
>
> No impact. What I try to implement is equivalent of 'mergeinfo_changed'
> table in issue-2897 branch.
>
> This information is retrievable by doing a prop diff with earlier revs.
> But would be very complicated and performance intensive.
>
>
> > What impact would it have on our code if we did not carry around the
> > indirect mergeinfo? Do we currently rely on this information as a
> > form of cache ... or rather to save us from crawling the fs?
> >
> >
>
> I don't rely on direct/indirect mergeinfo, I just bother about what is
> new merge in this commit.

Yes, but the only reason that is hard today is that the change in the
mergeinfo when you do a commit contains the information on what was
merged, but also typically also includes changes to the indirect
mergeinfo. If it did not contain the latter, then a simple diff of
the property would tell you what was merged.

Of course elision would probably make that not entirely true.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org