Enhancement request for the merging API: "Commit message suggestion"

Hi devs,

I have a enhancement request for the merging API.

Problem 1:
Whenever a revision is merged TortoiseSVN 1.5.0-dev suggests
a commit 
message based on the revisions which have been merged and
their author and 
commit message ("Commit message suggestions").
Unfortunately it cannot tell 
if a revision specified by the user was really merged. For
example a 
revision could have been blocked by an existing
svn:mergeinfo entry. 
Therefore the created log message sometimes contains too
many entries. 

Problem 2:
A further problem is that every SVN client might generate
this commit 
message in a slightly different way.

The solution to both problems:
Could the callback of svn_client_merge_peg4 (notify_func of

svn_client_ctx_t) please provide a suggested commit message
at the end of 
the merge. All SVN clients will then be able to present this
to the user so 
that he can use it.
This log message should be formated similar to the one
svnmerge.py creates, 
maybe even exactly the same format.

Thanks,
Tobias

-- 
       ___
  oo  // \      "De Chelonian Mobile"
 (_,/ _/      TortoiseSVN
    _/__/>    The coolest Interface to (Sub)Version
Control
   /_/   _     http://tortoisesvn.net

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 11/5/07, Tobias Schäfer <tobiasschaefergmx.de> wrote:
> Hi devs,
>
> I have a enhancement request for the merging API.
>
> Problem 1:
> Whenever a revision is merged TortoiseSVN 1.5.0-dev
suggests a commit
> message based on the revisions which have been merged
and their author and
> commit message ("Commit message
suggestions"). Unfortunately it cannot tell
> if a revision specified by the user was really merged.
For example a
> revision could have been blocked by an existing
svn:mergeinfo entry.
> Therefore the created log message sometimes contains
too many entries.
>
> Problem 2:
> A further problem is that every SVN client might
generate this commit
> message in a slightly different way.
>
> The solution to both problems:
> Could the callback of svn_client_merge_peg4
(notify_func of
> svn_client_ctx_t) please provide a suggested commit
message at the end of
> the merge. All SVN clients will then be able to present
this to the user so
> that he can use it.
> This log message should be formated similar to the one
svnmerge.py creates,
> maybe even exactly the same format.

Given the existence of 'svn log -g', should we really be
encouraging
log messages that include the logs of the merged revisions? 
(The
header summary line is very useful of course.)

--dave

-- 
David Glasser | glasserdavidglasser.net | http://www.davidglasser.
net/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 11/5/07, David Glasser <glasserdavidglasser.net>
wrote:
> On 11/5/07, Tobias Schäfer <tobiasschaefergmx.de> wrote:
> > Hi devs,
> >
> > I have a enhancement request for the merging API.
> >
> > Problem 1:
> > Whenever a revision is merged TortoiseSVN
1.5.0-dev suggests a commit
> > message based on the revisions which have been
merged and their author and
> > commit message ("Commit message
suggestions"). Unfortunately it cannot tell
> > if a revision specified by the user was really
merged. For example a
> > revision could have been blocked by an existing
svn:mergeinfo entry.
> > Therefore the created log message sometimes
contains too many entries.
> >
> > Problem 2:
> > A further problem is that every SVN client might
generate this commit
> > message in a slightly different way.
> >
> > The solution to both problems:
> > Could the callback of svn_client_merge_peg4
(notify_func of
> > svn_client_ctx_t) please provide a suggested
commit message at the end of
> > the merge. All SVN clients will then be able to
present this to the user so
> > that he can use it.
> > This log message should be formated similar to the
one svnmerge.py creates,
> > maybe even exactly the same format.
>
> Given the existence of 'svn log -g', should we really
be encouraging
> log messages that include the logs of the merged
revisions?  (The
> header summary line is very useful of course.)

I agree with you David.  The solution is to discourage
people from
using the commit message in this manner. The svn log -g
support is
superior and it just reinforces that you do not need to use
the log
message for this sort of book keeping any more.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Monday 05 November 2007 19:39:44 David Glasser wrote:

> Given the existence of 'svn log -g', should we really
be encouraging
> log messages that include the logs of the merged
revisions?  (The
> header summary line is very useful of course.)

IIRC 'svn log -g' is only supported by a svn 1.5 server, so
we cannot rely 
solely on 'svn -g'.

Tobias

-- 
       ___
  oo  // \      "De Chelonian Mobile"
 (_,/ _/      TortoiseSVN
    _/__/>    The coolest Interface to (Sub)Version
Control
   /_/   _     http://tortoisesvn.net

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 11/5/07, Tobias Schäfer <tobiasschaefergmx.de> wrote:
> On Monday 05 November 2007 19:39:44 David Glasser
wrote:
>
> > Given the existence of 'svn log -g', should we
really be encouraging
> > log messages that include the logs of the merged
revisions?  (The
> > header summary line is very useful of course.)
>
> IIRC 'svn log -g' is only supported by a svn 1.5
server, so we cannot rely
> solely on 'svn -g'.

We should not promote using these sort of log messages
forever either though.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 11/5/07, Tobias Schäfer <tobiasschaefergmx.de> wrote:
> On Monday 05 November 2007 19:39:44 David Glasser
wrote:
>
> > Given the existence of 'svn log -g', should we
really be encouraging
> > log messages that include the logs of the merged
revisions?  (The
> > header summary line is very useful of course.)
>
> IIRC 'svn log -g' is only supported by a svn 1.5
server, so we cannot rely
> solely on 'svn -g'.

While backwards compatibility is generally a good idea, I
don't see
why we should actively add a feature that we instantly
deprecate
against current servers.  There's a difference between
preserving old
behaviors and adding new ones.

--dave

-- 
David Glasser | glasserdavidglasser.net | http://www.davidglasser.
net/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Tuesday 06 November 2007 20:26:38 David Glasser wrote:

> While backwards compatibility is generally a good idea,
I don't see
> why we should actively add a feature that we instantly
deprecate
> against current servers.  There's a difference between
preserving old
> behaviors and adding new ones.

Thanks for your comments.

OK, you convinced me not implementing "Commit message
suggestion " is the 
better solution in the long term. Until all clients and
servers have both 
updated to 1.5 phrasing good log messages is going to be
cumbersome though.

In a perfect world (SVN 1.5 Client, SVN 1.5 Server) what
would a good log 
message look like when merging? The log message could stay
empty in most 
cases since the information provided there can be optained
bei 'svn -g'.

'svn -g' currently doesn't show the original parameters of
the merge: was 
accestory ignored, were line endings ignored, were
whitespace changes 
ignored, which conflicts occured, which targets were skipped
during the 
merge, (possibly more...).
This could be part of the suggested log message, although it
could also be 
stored as metadata somewhere else.

IMHO, a sensible suggestion (summary) would ease merging
with the 
combination SVN 1.5 client/1.4.x or 1.3.x server. It's going
to take a while 
for all servers to update to 1.5.
http:/
/tortoisesvn.tigris.org/svn/tortoisesvn/ ist currently
still using 
1.3.1 :-(

Tobias

-- 
       ___
  oo  // \      "De Chelonian Mobile"
 (_,/ _/      TortoiseSVN
    _/__/>    The coolest Interface to (Sub)Version
Control
   /_/   _     http://tortoisesvn.net

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org