[Svnmerge] [PATCH] Bidirectional patch take 2

[Blair Zajac]

Alan Barrett wrote:
> On Fri, 24 Feb 2006, Giovanni Bajo wrote:
> 
>>["svn log" is] the one command that weights most in the "svnmerge
>>avail" time. I don't consider making "svnmerge avail" twice as slow in
>>a repository without reflected revisions a good tradeoff for having an
>>improved correctness.
> 
> 
> Could we pay the penalty only for "svnmerge merge", and not for
> "svnmerge avail"?  If a reflected revision is marked as available and
> then the user tries to merge it, that could be detected and refused.

I think for consistency, merge and avail should work over the same revision 
ranges.  That may get confusing for users.

> It would also be possible to cache the list of available revisions in a
> property.  Then "svnmerge avail" would have to do the slow checking only
> for revisions newer than the data in th cache.

I think all of us have tried to think of ways to save this data in the 
repository or some external location and haven't come up with a satisfactory way 
of doing so.

I'm getting to thinking that svnmerge.py can use a pickled data file in 
~/.subversion to save any known data from the repository that can never be 
changed.  For example, the revisions that were modified in a particular 
directory, or the list of files changed for a revision.  This would prevent us 
having to do expensive svn logs over large revision ranges, just svn logs over 
short revision ranges since svnmerge.py svn log was last run.

I'm not talking about updating any .dot files or svn properties during the 'svn 
commit' phase.  This is just caching data that cannot be changed in the 
subversion repository.  So we should not cache the svn:log property when the svn 
commit message is generated.

Regards,
Blair