Skip to content

Tags: lineCode/svn2git

Tags

1.0.11

Toggle 1.0.11's commit message
Allow compiling against SVN 1.8. (svn-all-fast-export#22)

1.0.10

Toggle 1.0.10's commit message
Stop unintended re-encoding of author names from UTF-8 to ASCII

To see the bug in action, use an author map with umlauts, e.g.

nickname = Hällo Wörld from UTF-8 <[email protected]>

and check "git log" after the conversion.

What is happening?
QByteArray "author" is first decoded as UTF-8 into a QString.
That QString is passed to QByteArray::append(const QString &)
which internally encodes the QString to ASCII byte data using
QString::toAscii().  "git fast-import" expects UTF-8 input
from us, so the original QByteArray with UTF-8 content is just
what we need.

1.0.9

Toggle 1.0.9's commit message
Stop unintended re-encoding of author names from UTF-8 to ASCII

To see the bug in action, use an author map with umlauts, e.g.

  nickname = Hällo Wörld from UTF-8 <[email protected]>

and check "git log" after the conversion.

What is happening?
QByteArray "author" is first decoded as UTF-8 into a QString.
That QString is passed to QByteArray::append(const QString &)
which internally encodes the QString to ASCII byte data using
QString::toAscii().  "git fast-import" expects UTF-8 input
from us, so the original QByteArray with UTF-8 content is just
what we need.

1.0.8

Toggle 1.0.8's commit message
Use fastimport.write for the actual commit objects too, so we get

logging when --debug-rules is turned on.

1.0.7

Toggle 1.0.7's commit message
Make conversion runs deterministic by sorting what's returned via has…

…h from the SVN API.

An SVN commit spanning multiple paths that shall be turned into
multiple branches in git would result in the git commits to be fed into
git fast-import in arbitrary order. This is problematic for merge
commits, as it means the list of parent commits for the merge commit
will have an arbitrary order. Fix this by always handling the paths in
an SVN commit in order. This makes svn2git conversion runs reproducible.

Unfortunately, commits where paths have been removed and added again,
might no longer be handled correctly. I haven't found such a case in the
FreeBSD repository however.

This is IHMO a bug in git, but it all hinges on semantics like list of
parents vs. set of parents and how you define a hash on a set of objects
that have no natural order.

1.0.6

Toggle 1.0.6's commit message
Merge commit 'refs/merge-requests/17' of gitorious.org:svn2git/svn2gi…

…t into mr/17

1.0.4

Toggle 1.0.4's commit message
Save deleted branches in a visible namespace

 - The branch is first created properly and then deleted
   (line "progress SVN r77 branch config-header = :0 # delete")

 - Jehan's post-1.0.3 commit 584005f
   writes a backup of the branches latest ref to refs/backup/
   on deletion.  Many thanks for that commit!

However, in my opinion the problem with the current code is that it
makes it much too easy to lose history during the conversion to Git.
Without a tag or branch pointing to it the commits will fall off easily,
especially if people use "git clone" on the bare Git repository created
by svn2git.

It would be safer and useful to create visible tags for this, e.g.
refs/tags/branch-bugfix17-deleted.

My attached patch changes Jehan's code to do just that.
Please consider application - this patch really matters to me.
If you'd rather have both a ref in refs/backup/ and in refs/tags/ or
require a command line option for it I can adjust the patch for you.

Thanks for listening,

1.0.3

Toggle 1.0.3's commit message
Commit branch creation when requested and not on next transaction commit

Branches was created by adding the command to a list, this list was then
written to git when the next transaction was committed. This had the
side effect that if the branch creation was the last thing the branch
was never created.

1.0.2

Toggle 1.0.2's commit message
Add option for using the real content of an SVN branch when creating a

new branch instead of using the contents of the git "from" branch.