[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn2cvsgraph, how to best handle merges?

From: Henrik Carlqvist <hc528_at_poolhem.se>
Date: Thu, 27 Mar 2014 07:47:12 +0100

On Wed, 26 Mar 2014 15:45:31 -0400
Mark Phippard <markphip_at_gmail.com> wrote:
> We came to the same conclusion when we built the revision graph in
> Subclipse back in 1.5:
>
> http://subclipse.tigris.org/graph.html

On Wed, 26 Mar 2014 19:41:38 +0000
Philip Martin <philip.martin_at_wandisco.com> wrote:
 That's a topic for the dev list and there was some discussion last
> month:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C52FDD315.7030808@syntevo.com%3E
> http://svn.haxx.se/dev/archive-2014-02/0140.shtml

Thanks for the information that others writing simular tools have seen the
same problem, I wasn't aware of the discussion on the dev list as I don't
subscribe to it. Right now I will not do any release of svn2cvsgraph which
querys every revision, instead I will wait and hope for the best.

My guess is that SmartSVN and subclipse also find much of the output from
"svn log -g" rather redundant. This kind of tools usually only displays
merge points, not considering if those merges are more or less complete. I
can understand if other users need some kind of tool to display what
merges really contain, but for this kind of graphs only the merge points
without the recursive previous merges are interesting.

If it would help to write some kind of merge log functionality that does
not display recursive older merges that kind of log would probably useful
for our tools. However, it is better to have too much information in the
logs than to have missing information.

regards Henrik
Received on 2014-03-27 07:47:52 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.