Potential for loss of history with svn2git

[Nicolás Alvarez]

2017-12-17 11:58 GMT-03:00 John Lawlor <jk.lawlor at gmail.com>:
> 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 for when the parent *is* converted into the git repository,
just not marked as a parent. Usually when a branch is merged into
another.

> 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?

Please find the previous commit where pom.xml was modified (or added,
if "add scm/developerConnection" was the second modification) and show
me its svn log -v.

> 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
>
>



-- 
Nicolás