On 9/19/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > > the patch is very interesting, and I have been pondering something similar for > quite of some time. I believe the correct way of doing this is by caching > specific bits of information extracted from the SVN output, instead of being > just a "dumb" mapping cmdline -> output. For instance, any "svn log" issued by > svnmerge is different in its arguments (different ranges) but could still be > cached properly (per-rev) and reused (modulo revprop edits, for which a > rebuild-cache command could be devised).
I did consider the over-lapping case briefly, but didn't really find much call for it in the kind of usage we're seeing. Looking at the command output I currently have cached after running avail/merge between a number of branches - only 3 of the 96 cached commands have the potential for overlap, and those commands are typical the 'one per run' ones (e.g. log --verbose --quiet -rREV:REV) the big saving here is on all the smaller, shorter commands (e.g. 'log --incremental -v -r REV:REV' and 'svn propget -r REV') which get repeated between runs, because the same revisions are queried in many different cases. > Thanks for proposing it. I should have some time to work on svnmerge next > month, and I will see if I can come up with a more comprehensive patch. Feel > free to ping me again :) Thanks for considering it. There are a few other things we'd like to add ... - somewhere to store some defaults (we always use -b, but if you forget, you can sometimes get confusing results). - a way to limit the considered revisions to a single author (i.e. show me which of my changes are on trunk, but not on the release branch) - a way of suppressing the revisions which are just setting up branches (i.e. Initialized merge tracking via svnmerge). Do any/all of these things sound like things you'd consider adding? Have fun, Rich _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
