[Svnmerge] [PATCH] Cache svn output

[Rich Williams]

On 9/20/06, Giovanni Bajo <rasky at develer.com> wrote:
> Daniel Rall wrote:
> >> - somewhere to store some defaults (we always use -b, but if you forget,
> >> you can sometimes get confusing results).
>
> > +1.  I like the idea of a ~/.subversion/svnmerge-config file.
>
> Yes, +1 from me too.

Ok, well I'll give it a go then - should be a chance to brush up
on my Python skills - I don't suppose you'd accept a re-write
in Perl would you? :-)

I wasn't sure if the config should be in an [svnmerge] section of
~/.subversion/config, or in it's own file - sounds like you think it
should be a separate file? What kind of format - INI style like
the existing config files?

> >> - 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)
>
> > Is this a common use case?
>
> Yes. In my case, for instance, it happens that I know some people are doing a
> work on the trunk which will never need to be merged into a branch, while
> others might produce patches which could be merged. By grepping by the author
> name, I would be able to reduce much of the work. See also my next mail about
> the GUI wrapper.

For us, it's a very common use case. We have a dozen or so
developers who will typically work on their own branches, then
merge to trunk, and then cherry pick their changes to merge to
a release branch (we don't do 'formal' releases, we're pushing
changes out to a big website which gets regularly 'built' from the
release branch).

I didn't see any mail about a GUI wrapper, but that sounds like
a good idea - one of the developers here actually wrote an
interactive command line script which runs 'avail', filters out
changes from other developers, then steps through each
revision letting you decide between - yes: merge it now,
no: skip it this time and diff: show me the diff. It works really
well for our way of working. If you think it would be useful,
I'll ask him if he's willing to share it.

Would you consider adding something like that being built
into svnmerge as an 'interactive' merge, or would it be better
kept as an extra step?

Have fun,

Rich