2017-12-17 11:58 GMT-03:00 John Lawlor <jk.law...@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.alva...@gmail.com> > wrote: >> >> 2017-12-17 2:09 GMT-03:00 John Lawlor <jk.law...@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
