Potential for loss of history with svn2git

[John Lawlor]

Hi Nicolás,

It is discussed on the KDE svn2git page. They talk about how to fix missing
parents:
https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git#Post-processing

This is exactly what I am describing in the previous email.

You can see it in the history of the git repository. Here is an example
from one I converted.

The commit message was:
*refactor parser-api structure to be a module; add scm/developerConnection
tags to pom*

Now the developer was 'updating' the pom.xml, that is clear from the commit
message.
But, from gits perspective this is a new file, and pom.xml is recorded as
being *added* to version control.

The parent commit is missing from the history.

The commit has no parents according to git. But the commit has a parent in
svn, and I can find the revision for it.
If I convert the 'Modules' directory to git using 'svn2git':

match /projects/Modules/

I can find the commit of the parent recorded in the history for the
'Modules' directory. Does this not point to
history being recorded in different places depending on how you do your
checkout in SVN?

Regards,
John




On 17 December 2017 at 05:32, Nicolás Alvarez <nicolas.alvarez at gmail.com>
wrote:

> 2017-12-17 2:09 GMT-03:00 John Lawlor <jk.lawlor at gmail.com>:
> > 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.
>
> I have no idea what you mean with "several places for history to be
> recorded in the SVN tree" or "at the Modules level" etc...
>
> If someone modifies
> /projects/Modules/framework/file-appender/trunk/pom.xml, then "match
> /projects/Modules/framework/file-appender/trunk/" will obviously match
> it, since it's a prefix of the full path being modified. It doesn't
> matter what you checked out when making the commit. Checking out /a/b
> and making a change to c/d.txt and checking out /a and making a change
> to b/c/d.txt gives exactly the same result: a commit that changes
> /a/b/c/d.txt. The two cases aren't distinguishable in the resulting
> SVN repository, and svn2git will work the same.
>
> I see in your example you mention a change is done in file-manager,
> and then you convert file-appender. I assume that's just a mistake in
> your email? :)
>
> --
> Nicolás
> Award-winning git repo surgeon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20171217/2fb7cb9d/attachment.html>