Announcement

Collapse
No announcement yet.

forgotten prehistory when using git svn clone?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • forgotten prehistory when using git svn clone?

    Hi,

    I triy to migrate an (ancient) svn repos to git. One of the first steps is

    git svn clone .....


    Doing that gives some initial clone. Now, inspecting the revision history in the new cloned repository shows a history

    dating back till 2010,

    while doing svn log on the checked out svn work directory shows a history

    dating back to the last century

    (yes, it's an ancient repos).


    Anyhow: I checked the git "history" via gitk and via commands like

    git log --before="2009-01-01"

    but I don't find a trace of the "pre-history",

    Now, inspecting the svn history, I observe the following facts:

    - while doing the git svn clone, all svn revisions "r1" till "r50000" are reported to be
    part of the clone, nothing seems to be forgotten (there's some warnings though).

    - Now: the crucial observation: r1 (the ``first'' revision'') is not the "oldest one". It's from
    2010, which is when the git history seems to start.


    I suspect the latter observation causes the fact that after conversion, the
    history dates back just to 2010, but not earlier.

    I should say that the svn repos is a ``merge'' of different reposes
    (each with their own revision history) That may account for the
    fact that revision r1 is not temporally the oldest revision.

    Anyway: is the older history still preserved in the migrated GIT repos?
    I am worried it's truncated, especially since the "git log --before "2009-01-01"
    is empty which it should not be.

    If the reason for the missing history is the anomaly that revision r1 is not the oldest,
    what can I do to change that, can one ``recalculate'' the revision numbers to reflect the temporal ordering?

    Thanks, Martin

  • #2
    By loading different repositories into a single repository in Subversion you can, indeed, end up with time sequences flowing forward and then jumping back, flowing forward and then jumping back, etc. It's a know issue in Subversion that having out-of-normal-time-sequence revisions can make certain Subversion constructs fail (be unusable). That's not normally an issue.

    If Git has the same monotonically increasing time requirement then converting such a repo from Subversion will likely cause it to similarly have unusable features. For instance, the "--since", "--after", "--until", "--before" are likely to resolve the first time sequence that matches the criteria instead of searching all of history. I can't blame it for that at all. Again, the vast majority of those features should be fine.

    I would do a "git log --all > all.log", wait for it to complete, and then look for those dates manually using an editor/grep/etc. I expect you'll find them there!

    Comment


    • #3
      Thanks, yes, git log --all shows commit with dates earlier than that of revision r1.


      Additional info: Some further inspection however shows: not all revisions are there. Secondly: my statement
      in the original posting that
      when doing the
      git svn clone
      all revisions seem to be there is also incorrect, already when doing the clone quite some are actually missing
      (I did not see the first time, I only found
      one that the clone contained material older than revision r1 and simply assumed it implied all older material was there. I have not figured out if
      there is a systematic interpretation on which ones are left out.
      Last edited by Martin Steffen; 02-18-2017, 02:47 PM. Reason: further observations/corrections added

      Comment

      Working...
      X