Issue running git-svn-mirror script on code

Geert Janssens janssens-geert at
Wed Jan 23 10:44:57 EST 2013

On 23-01-13 16:15, Derek Atkins wrote:
> John Ralls <jralls at> writes:
>>> I realised this morning that the choice of (svn) URL is no longer
>>> important. The main concern to keep the original URL was to preserve
>>> the commit hashes.  But due to the updates to the authors file, the
>>> svn import into git will result in new hashes starting with the first
>>> commit which has a corrected author, so preserving hashes is no
>>> longer an option.
>>> So if you think it would be more efficient, we can do the import from
>>> another url, like your original file:/// or using
>>> (depending on which string you would like to see appear in the commit
>>> messages).
>>> I saw the import was completed by now, so I'm not sure if it will
>>> gain us much still by starting over once again.
>>> The only reason I could really think of is that once we really drop
>>> svn, the usr has little meaning left, while
>>> is more generic and will remain. So at some point in
>>> time, the imported commits will display a non-existent url. On the
>>> other hand, even with in the url, the svn paths will
>>> eventually 404, so there always will be some inconsistency left.
>>> That is just a small inconsistency though, perhaps not worth redoing
>>> the migration for.
>> Geert,
>> Not so fast. When you git-svn-dcommit, you'll use the svn+ssh URL, and
>> your local commit will be hashed with the resulting svn id. The mirror
>> git, regardless of where it's running, needs to create a commit with
>> the same hash so that when it makes the loop back to your machine, git
>> can recognize it as the same commit and fast-forward your repo.
> Moreover, in my trials I have not noticed a significant speed difference
> between the svn+ssh// vs. file:// URLs.  This is probably because in all
> cases the limit is not on the transfer of data but on I/O and CPU
> processing.  If I ran 'time' I suspect I might see a slight difference
> on the initial import, but I think John's point of the dcommit
> fastforward is more important.
Yes, agreed.


More information about the gnucash-devel mailing list