[Kde-scm-interest] Kopete git migration

[Nicolás Alvarez]

2013/5/18, Torgny Nyblom <nyblom at kde.org>:
> On Saturday 18 May 2013 15.36.44 you wrote:
>> 2013/5/18, Torgny Nyblom <nyblom at kde.org>:
>> > On Friday 17 May 2013 17.30.30 Pali Rohár wrote:
>> >> On Friday 17 May 2013 17:22:24 Urs Wolfer wrote:
>> >> > Ok, I have mailed all maintainers. Once we get their approval,
>> >> > we can start the final migration :)
>> >> >
>> >> > Should I request Git repos for every project from KDE
>> >> > sysadmins?
>> >> >
>> >> > @Pali: What do you think about Kopete? Is it also ready?
>> >>
>> >> Yes, now Kopete is ready. I fixed all problems and now all tags
>> >> are annotated. All kopete plugins which do not have common
>> >> history with kopete master was moved into separate rule files and
>> >> will be in separate git repositories.
>> >>
>> >> There could be one problem: Only on dewey server is conversion OK
>> >> due to non deterministic behaviour of svn2git on files...
>> >
>> > Just out of curiosity what do you mean by this? Do you have an example?
>>
>> APR hashtables use randomized hashing, so the changes within a commit,
>> or files in a directory when recursing, are iterated in a random
>> order, which is even different between runs.
>>
>> svn2git takes the path of the first rule that matches to put in the
>> commit message metadata. If, for a certain commit, svn2git gets
>> /trunk/KDE/kdenetwork/doc/kopete/index.docbook as the first change,
>> the commit message will have "svn
>> path=/trunk/KDE/kdenetwork/doc/kopete". Since it's random, the next
>> time you convert it may get a source code file first instead, and the
>> commit message will have "svn path=/trunk/KDE/kdenetwork/kopete"
>> instead, changing the git hash of the commit and every commit that
>> follows.
>
> This is just a message and hash, not an issue as long as the same files are
>
> treated in the same manner each time.

We have post-processing scripts that alter the list of parents of some
commits. The input file uses SVN revision numbers, and the script
searches for the corresponding Git commit.

When the conversion rules put different changes of the same commit
into different branches, a single SVN commit is converted into
multiple Git commits, which means multiple Git commits have the same
SVN revision number in the metadata. In that situation, the
post-processing scripts rely on the 'svn path=' line to disambiguate
between them. That breaks if the path is different on every run...

-- 
Nicolás