Description of problem:
I hit the following issue when testing the jcr2vfs migration tool. Versions records (e.g. commits in case of git) are sorted by the commit date instead of how they actually happened (the order in which they were committed). See the example.

Following is returned by 'git log' (the number in parentheses is just for reference, not part of the actual output):
(1)
commit 558c4b05ed4f6ab241e2c8bab17fb0940dd0871a
Author: Petr Siroky <psiroky>
Date:   Thu Aug 15 10:08:45 2013 +0200

    Underage.rdrl - salience updated to 11

(2)
commit 1b9e2799199bf032815f18f169f1264b68d3f657
Author: mic <null>
Date:   Wed Oct 1 04:54:34 2008 +0200

(3)
commit 23f53aaf7ef00df10119f20f18fbe77eecfe752d
Author: Petr Siroky <psiroky>
Date:   Fri Jul 26 17:59:37 2013 +0200


Following is the code used to get version records using VFS API:
    VersionAttributeView<Path> versionAttributeView = ioService.getFileAttributeView(path, VersionAttributeView.class);
    VersionHistory history = versionAttributeView.readAttributes().history();
    return history.records();

However this code returns the records in order: 2, 3, 1 - sorting them by date. 

It should instead return them in order 1, 2, 3 (or maybe 3, 2, 1 - not sure if its better to return latest as first or oldest as first)


Version-Release number of selected component (if applicable):
Uberfire in 6.0.0-ER5 (and most probably also in 0.3.0-SNAPSHOT and 0.4.0-SNAPSHOT)

Additional info:
This should not be an issue when the repository is accessed only through UI (kie-wb) as it commits the changes in correct order. However if we allow also remote access this could bring some issues when displaying the asset history. Also this pops up when using the jcr2vfs migration tool as it uses the dates from past to align the history with the JCR repo.