[Svnmerge] Test suite functional?
blair at orcaware.com
Wed Jul 13 12:25:11 PDT 2011
On Jul 13, 2011, at 7:46 AM, Michael Haggerty wrote:
> On 07/13/2011 01:58 PM, Blair Zajac wrote:
>> On Jul 13, 2011, at 1:46 AM, Alan Barrett wrote:
>>> On Wed, 13 Jul 2011, Michael Haggerty wrote:
>>>> I am trying to use svnmerge.py as a library to help with a
>>>> conversion of a Subversion project to git. (git-svn understands
>>>> svn:mergeinfo, but it does not understand svnmerge.py metadata,
>>>> so it needs some help.)
>>> Perhaps it would be useful to build a filter that could convert
>>> from svnmerge.py's metadata to svn:mergeinfo during a dump|filter|
>>> load cycle.
>> There are two tools that convert from svnmerge.py to svn:mergeinfo,
>> look in here for svnmerge-migrate*
> Probably you mean that I look at these tools for inspiration, and that
> is a good suggestion. But to avoid that somebody thinks that these
> tools solve the problem, let me explain why it is not the case.
> The svnmerge-migrate* scripts only migrate the metadata at HEAD,
> creating a new commit for each branch that contains the svn:mergeinfo
> equivalent of the svnmerge metadata that was present in HEAD. The
> result is that--to a tool that understands svn:mergeinfo but not
> svnmerge.py metadata--it looks like that new commit includes all of
> merges that were ever done using svnmerge.py.
> A history-aware data migration requires historical merges to be
> represented at the time they were made in the history. That is why we
> definitely need a tool that rewrites the past; either in the form of a
> dump-filter-rewrite of the Subversion repository, or in the form of a
> tool that understands the history while migrating to another VCS.
Good points, thanks for the explanation.
For complicated svn installs, the later is definitely safer. Any bugs
in understanding the history could be managed by re-cloning part of
svn's repository, instead of a dump-filter-rewrite that would require
everyone to do fresh checkouts.
More information about the Svnmerge