Potential for loss of history with svn2git

John Lawlor jk.lawlor at gmail.com
Sun Dec 17 05:09:01 UTC 2017


Hi,

I have encountered this problem with svn2git. It may be more to do with
poor repository structure in SVN, but it's worth highlighting all the same.

Let's say we have the following in SVN:

svn/projects/Modules/framework/file-appender/trunk
svn/projects/Modules/framework/file-appender/branches
svn/projects/Modules/framework/file-appender/tags

svn/projects/Modules/framework/file-manager/trunk
svn/projects/Modules/framework/file-manager/branches
svn/projects/Modules/framework/file-manager/tags

This is a pretty standard layout. However, for some reason the SVN
administrator gave developers write access to Modules. Really, I think Modules
should never have existed, it should probably be more like:

svn/projects/file-appender
svn/projects/file-manager

This results in several places for history to be recorded in the SVN tree.
If someone checks out 'Modules', they can make commits above 'trunk' into
say file-appender:

(from svn log)

Changed paths:
A Modules/framework/file-manager/trunk/pom.xml

If you subsequently convert file-appender to git, using a rule like:

match /projects/Modules/framework/file-appender/trunk

the commit recorded at the Modules level will not appear in your converted
repository. This makes sense as the commit wasn't made in 'trunk', it was
made at 'Modules'.

I am just wondering if this is really a problem or not. You might be
missing the commit but I am thinking, should 'pom.xml' be modified later at
'trunk', the contents of the file will still be there from the commit made
in the wrong place.

What can and does happen though is if the file is never modified in 'trunk',
after being created in 'Modules', it will be lost. It has no history in
trunk, hence it doesn't exist.

Ideas/thoughts very welcome

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20171217/af60f165/attachment.html>


More information about the Kde-scm-interest mailing list