Potential for loss of history with svn2git

[John Lawlor]

Hi Nicolás,

Here is the output of the parent commit:

------------------------------------------------------------------------
r428595 | gkumar | 2016-03-16 04:19:05 -0400 (Wed, 16 Mar 2016) | 2 lines
Changed paths:
   A /Modules/bdpe/parser-api
   A /Modules/bdpe/parser-api/.project
   A /Modules/bdpe/parser-api/.settings
   A /Modules/bdpe/parser-api/.settings/edu.umd.cs.findbugs.core.prefs
   A /Modules/bdpe/parser-api/osgi.bnd
   A /Modules/bdpe/parser-api/pom.xml
   A /Modules/bdpe/parser-api/src
   A /Modules/bdpe/parser-api/src/main
   A /Modules/bdpe/parser-api/src/main/java
   A /Modules/bdpe/parser-api/src/main/java/com
   A /Modules/bdpe/parser-api/src/main/java/com/openet
   A /Modules/bdpe/parser-api/src/main/java/com/openet/modules
   A /Modules/bdpe/parser-api/src/main/java/com/openet/modules/bdpe
   A
/Modules/bdpe/parser-api/src/main/java/com/openet/modules/bdpe/parserapi
   A
/Modules/bdpe/parser-api/src/main/java/com/openet/modules/bdpe/parserapi/Parser.java
   A /Modules/bdpe/parser-api/src/main/resources
   A /Modules/bdpe/parser-api/src/test
   A /Modules/bdpe/parser-api/src/test/java
   A /Modules/bdpe/parser-api/src/test/resources
Parser API added to the Modules/bdpe as an independent osgi module.


Regards,
John



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

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-scm-interest/attachments/20171218/ebbd0a12/attachment-0001.html>