[Svnmerge] Getting svnmerge.py into 1.3
Giovanni Bajo
rasky at develer.com
Fri Oct 14 17:20:13 PDT 2005
Blair Zajac <blair at orcaware.com> wrote:
> It looks like svn 1.3 is getting ready to be rolled and I'd like the
> svnmerge.py in that release.
Thanks. I believe it's been lightly tested until now, though. Maybe getting it
out of the door is a good way of testing it though :)
> The outstanding issue that I recall is how to mark and separate
> individual svn log messages in a svn merge, with the issue that a
> running of 'svn merge' may take the result from a previous 'svn
> merge'.
>
> The thinking off the top of my head is to use a unique marker, say
> ........ (.*8), which are less visible then subversion's default
> -*70, and when a new merge is done, to hunt through the existing log
> messages, and to use a new separator that is one more set of .*8's
> longer than the existing set.
>
> So visibly, the longest set of n*(.*8) is contains smaller sets of
> commits. This makes more sense to me than seeing a single .*8 be a
> single separator for smaller svn merges, which would have n+1*(.*8).
> It would also give you a sense of looking at the log in how many deep
> svn mege's you have.
>
> What do people think?
Looks fine to me, +1. I'll wait for more comments before implementing it.
I still got in my TODO list a few more items. I would like to split the
commands in separate help page, recalcing svn's idiom:
- "svnmerge help" or "svnmerge -h/--help": shows list of commands
- "svnmerge help cmd" or "svnmerge cmd --help": shows specific help page.
I would like also to introduce --long-format variants to command line options.
And Archie asked for a "svnmerge avail -R" to show logs in reverse order, which
makes sense. I can take care of these things in a couple of days.
Are people ok with these changes?
Giovanni Bajo
More information about the Svnmerge
mailing list