[Kde-scm-interest] Kopete git migration

[Torgny Nyblom]

On Saturday 18 May 2013 16.51.31 Nicolás Alvarez wrote:
> 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...

Ah now I get it, sine I consider 99% of all post processing scripts to be a 
nessesity resulting from incomplete rule files I do not think this is an issue.

In my view it is the post processing scripts that are broken since they rely 
on something that is not there and never has been.

/Regards
Torgny