Issue with version numbers while working on new diff interface
While working on the new diff interface I've hit this bug http://jira.xwiki.org/jira/browse/XWIKI-1468 with the numbering on versions in the RCS file which does not correspond to the version of the real documents. There are different ways to fix this, but maybe it's not worth to do the "perfrect fix" with Artem's work on versioning storage that coult not make use of RCS. So the problem is that in the RCS file you have 1.3 -> $doc.version = 1.4 1.2 -> $doc.version = 1.3 1.1 -> $doc.version = 1.2 This actually is visible in the UI when you request the version list of the document that is in version 1.4 you will be shown version 1.3,1.2,1.1 but no 1.4. If you click on 1.3 then you will see document in the latest version. If you make a diff between 1.3 and 1.2 then you will see in the UI "From 1.4 to 1.3". I found that this problem depends on the initial version of the document when it is first saved. This means that we should be able to detect the issue for fixing the view as well as migrate the version file on save when we see the problem. Fix 1: change the UI to acknowledge this mistake (make only changes in vm files) but no fix to saving Fix 2: change $xwiki.getDocument(doc, version) and $doc.getRevisions (and related) to send back the right data but no fix to saving Fix 3: fix the problem in saving (move all versions by one if we detect the problem), detect the issue (last RCS version not equal to current doc version) to apply fix1 and fix2 for the display (probably easier to do with fix 2) I'm more favorable to fix 3 combined with fix 2. WDYT ? Ludovic -- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
On 7/29/07, Ludovic Dubost <[email protected]> wrote:
[snip...]
So the problem is that in the RCS file you have
1.3 -> $doc.version = 1.4 1.2 -> $doc.version = 1.3 1.1 -> $doc.version = 1.2
[snip...]
I found that this problem depends on the initial version of the document when it is first saved. This means that we should be able to detect the issue for fixing the view as well as migrate the version file on save when we see the problem.
Fix 1: change the UI to acknowledge this mistake (make only changes in vm files) but no fix to saving Fix 2: change $xwiki.getDocument(doc, version) and $doc.getRevisions (and related) to send back the right data but no fix to saving Fix 3: fix the problem in saving (move all versions by one if we detect the problem), detect the issue (last RCS version not equal to current doc version) to apply fix1 and fix2 for the display (probably easier to do with fix 2)
I'm more favorable to fix 3 combined with fix 2. WDYT ?
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off... I don't see a huge issue with revision numbers being different than version numbers, though it is an issue w/ matching the display.. There is a way to tell RCS to start with a different version: "The initial version number for a newly registered file is 1.1, by default. You can specify a different default by setting the variable vc-default-init-version, or you can give C-x v i a numeric argument; then it reads the initial version number for this particular file using the minibuffer." -- seems like including some way to start at an arbitrary number != 1.1 in the RCS record itself might be the best way to solve the problem (when the diffs are RCS backed). I haven't checked out the javadoc, but a cursory investigation of the constructors seems to imply that JCRS supports this too (passing a version in w/ the constructor)... Erin -- 'Waste of a good apple' -Samwise Gamgee
Erin Schnabel a écrit : [snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called. The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document.. I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468 Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not. Ludovic
I don't see a huge issue with revision numbers being different than version numbers, though it is an issue w/ matching the display..
There is a way to tell RCS to start with a different version: "The initial version number for a newly registered file is 1.1, by default. You can specify a different default by setting the variable vc-default-init-version, or you can give C-x v i a numeric argument; then it reads the initial version number for this particular file using the minibuffer." -- seems like including some way to start at an arbitrary number != 1.1 in the RCS record itself might be the best way to solve the problem (when the diffs are RCS backed). I haven't checked out the javadoc, but a cursory investigation of the constructors seems to imply that JCRS supports this too (passing a version in w/ the constructor)...
Erin
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
Hi. I'm sorry for hasn't replied early. I had problems with spam filters :/. I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet. My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion) So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any. Ludovic Dubost wrote:
Erin Schnabel a écrit :
[snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called.
The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document..
I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468
Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not. New option "reset versions" in Import interface?
-- Artem Melentyev
On 7/30/07, Artem Melentyev <[email protected]> wrote:
Hi.
I'm sorry for hasn't replied early. I had problems with spam filters :/.
I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet.
My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion)
So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any.
Ludovic Dubost wrote:
Erin Schnabel a écrit :
[snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called.
The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document..
I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468
Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not. New option "reset versions" in Import interface?
The preserving of versions in import/export is already done (at least as far as the Packager is concerned): [XWIKI-1544]. The default is to reset the version of an imported document to 1.1, which is the current behavior. A new get/set property was added to indicate that the version of the imported document should be retained. http://jira.xwiki.org/jira/browse/XWIKI-1544 I was more interested in how the preserved version from an import would translate into the RCS Acrhive, and if it would happen automagically, etc. -- 'Waste of a good apple' -Samwise Gamgee
Hi Artem, But what for the latest version of the document.. It could still be wrong compared to the last RCS version Ludovic Artem Melentyev a écrit :
Hi.
I'm sorry for hasn't replied early. I had problems with spam filters :/.
I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet.
My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion)
So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any.
Ludovic Dubost wrote:
Erin Schnabel a écrit :
[snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called.
The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document..
I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468
Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not. New option "reset versions" in Import interface?
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
Hi. Ludovic Dubost wrote:
But what for the latest version of the document.. It could still be wrong compared to the last RCS version
It will be sync on next save. I think this is not too important. IMHO any bug-specific migrations(as XWIKI-1468-B) in xwiki-platform-core is bad. Because: it is decrease performance fast to obsolete pollution core code If we really need migration maybe we need create migration system. Something like: store data version in db, xwiki will execute migrations at boot. Migrations will be like patches from one data version to another. (XWIKI-883 also need migration) WDYT?
Artem Melentyev a écrit :
Hi.
I'm sorry for hasn't replied early. I had problems with spam filters :/.
I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet.
My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion)
So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any.
Ludovic Dubost wrote:
Erin Schnabel a écrit :
[snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called.
The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document..
I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468
Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not.
-- Artem Melentyev
Artem Melentyev wrote:
Hi.
Ludovic Dubost wrote:
But what for the latest version of the document.. It could still be wrong compared to the last RCS version
It will be sync on next save. I think this is not too important.
IMHO any bug-specific migrations(as XWIKI-1468-B) in xwiki-platform-core is bad. Because: it is decrease performance fast to obsolete pollution core code
If we really need migration maybe we need create migration system. Something like: store data version in db, xwiki will execute migrations at boot. Migrations will be like patches from one data version to another. (XWIKI-883 also need migration)
WDYT?
Indeed, any migration should be performed only once, when the platform starts. And to speed things up even more, we can even put a version identifier in the database, equal to the svn version or the build number, and only if the stored version differs from the current version we perform the update.
Artem Melentyev a écrit :
Hi.
I'm sorry for hasn't replied early. I had problems with spam filters :/.
I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet.
My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion)
So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any.
Ludovic Dubost wrote:
Erin Schnabel a écrit :
[snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called.
The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document..
I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468
Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not.
I have some Diff code that requires the data to be correct in the Database. I agree that code polution is not great. So I suggest we write some code to "fix and resave" without changing the document version number. For this we need a "resave" api that does not change anything in the document. What I don't like too much in Artem's proposed approach is the the version inside the XML is different than the version in the RCS file. I think it is still better to have them in sync. I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior. Ludovic Artem Melentyev a écrit :
Hi.
Ludovic Dubost wrote:
But what for the latest version of the document.. It could still be wrong compared to the last RCS version
It will be sync on next save. I think this is not too important.
IMHO any bug-specific migrations(as XWIKI-1468-B) in xwiki-platform-core is bad. Because: it is decrease performance fast to obsolete pollution core code
If we really need migration maybe we need create migration system. Something like: store data version in db, xwiki will execute migrations at boot. Migrations will be like patches from one data version to another. (XWIKI-883 also need migration)
WDYT?
Artem Melentyev a écrit :
Hi.
I'm sorry for hasn't replied early. I had problems with spam filters :/.
I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet.
My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion)
So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any.
Ludovic Dubost wrote:
Erin Schnabel a écrit :
[snip]
I prefer to allow document versions to start at an arbitrary number (i.e. if I've imported the document from another wiki, I like to preserve the version of the document from the original wiki in the target wiki). This means that the first version of the document may be 1.9, and that's certainly a lot more than one version off...
That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called.
The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document..
I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468
Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not.
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
Hi. Ludovic Dubost wrote:
I have some Diff code that requires the data to be correct in the Database. I agree that code polution is not great. So I suggest we write some code to "fix and resave" without changing the document version number. For this we need a "resave" api that does not change anything in the document.
Do you mean we need reconstruct only XWikiDocumentArchive without to set XWikiDocument.version?
What I don't like too much in Artem's proposed approach is the the version inside the XML is different than the version in the RCS file. I think it is still better to have them in sync.
I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior.
This is good solution. But we have another major problem with versions: XWIKI-1582. While xwiki is importing, packager plugin do not reset doc.version when history is not in xar. So we get doc.version>1.1 and archive.latestVersion=1.1. This bug is old. Catalin reproduces it on xwiki-1.1M1. There are many problems because we assume that archive is always begins at 1.1 in many places of core. All these problems can't be fixed for 1.1M4, so I think we need to set document.version to archive.latestVersion for sync versions. Ludovic: your patch is simple make -1 to all versions. This is not adapt to migration for XWIKI-1582. We need more. We need reconstruct history from scratch and set doc.versions according to document archive. I attached XWIKI-1468-resaveapi-amelentev.patch and fixrcs.groovy as sample. But these patches modify document.version and save document as new version with comment "fixrcs". WDYT? -- Artem Melentyev
Again (and maybe this is covered and I missed it..)-- I want to be able to import documents that have no history and PRESERVE the inbound version numbers. I added a patch that was committed a few weeks ago to do precisely this. I don't think the right answer is "revert the document version to 1.1 always". On 8/11/07, Artem Melentyev <[email protected]> wrote:
Hi.
Ludovic Dubost wrote:
I have some Diff code that requires the data to be correct in the Database. I agree that code polution is not great. So I suggest we write some code to "fix and resave" without changing the document version number. For this we need a "resave" api that does not change anything in the document.
Do you mean we need reconstruct only XWikiDocumentArchive without to set XWikiDocument.version?
What I don't like too much in Artem's proposed approach is the the version inside the XML is different than the version in the RCS file. I think it is still better to have them in sync.
I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior.
This is good solution.
But we have another major problem with versions: XWIKI-1582. While xwiki is importing, packager plugin do not reset doc.version when history is not in xar. So we get doc.version>1.1 and archive.latestVersion=1.1. This bug is old. Catalin reproduces it on xwiki-1.1M1. There are many problems because we assume that archive is always begins at 1.1 in many places of core. All these problems can't be fixed for 1.1M4, so I think we need to set document.version to archive.latestVersion for sync versions.
Ludovic: your patch is simple make -1 to all versions. This is not adapt to migration for XWIKI-1582. We need more. We need reconstruct history from scratch and set doc.versions according to document archive.
I attached XWIKI-1468-resaveapi-amelentev.patch and fixrcs.groovy as sample. But these patches modify document.version and save document as new version with comment "fixrcs".
WDYT?
-- Artem Melentyev
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- 'Waste of a good apple' -Samwise Gamgee
Hi, Erin. Don't worry. :) All known rcs bugs are fixed in 1.1M4 without reverting doc.version to 1.1. (XWIKI-1468 and XWIKI-1582, see issues history) So your patch is working in xwiki-1.1 (and 1.2 too). And my prev mail is obsolete. I could not write about it here because mail list did not work. Erin Schnabel wrote:
Again (and maybe this is covered and I missed it..)-- I want to be able to import documents that have no history and PRESERVE the inbound version numbers. I added a patch that was committed a few weeks ago to do precisely this.
I don't think the right answer is "revert the document version to 1.1 always".
On 8/11/07, Artem Melentyev <[email protected]> wrote:
Hi.
Ludovic Dubost wrote:
I have some Diff code that requires the data to be correct in the Database. I agree that code polution is not great. So I suggest we write some code to "fix and resave" without changing the document version number. For this we need a "resave" api that does not change anything in the document. Do you mean we need reconstruct only XWikiDocumentArchive without to set XWikiDocument.version?
What I don't like too much in Artem's proposed approach is the the version inside the XML is different than the version in the RCS file. I think it is still better to have them in sync.
I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior. This is good solution.
But we have another major problem with versions: XWIKI-1582. While xwiki is importing, packager plugin do not reset doc.version when history is not in xar. So we get doc.version>1.1 and archive.latestVersion=1.1. This bug is old. Catalin reproduces it on xwiki-1.1M1. There are many problems because we assume that archive is always begins at 1.1 in many places of core. All these problems can't be fixed for 1.1M4, so I think we need to set document.version to archive.latestVersion for sync versions.
Ludovic: your patch is simple make -1 to all versions. This is not adapt to migration for XWIKI-1582. We need more. We need reconstruct history from scratch and set doc.versions according to document archive.
I attached XWIKI-1468-resaveapi-amelentev.patch and fixrcs.groovy as sample. But these patches modify document.version and save document as new version with comment "fixrcs".
-- Artem Melentyev
On 8/11/07, Artem Melentyev <[email protected]> wrote:
Hi.
Ludovic Dubost wrote:
I have some Diff code that requires the data to be correct in the Database. I agree that code polution is not great. So I suggest we write some code to "fix and resave" without changing the document version number. For this we need a "resave" api that does not change anything in the document.
Do you mean we need reconstruct only XWikiDocumentArchive without to set XWikiDocument.version?
What I don't like too much in Artem's proposed approach is the the version inside the XML is different than the version in the RCS file. I think it is still better to have them in sync.
I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior.
This is good solution.
But we have another major problem with versions: XWIKI-1582. While xwiki is importing, packager plugin do not reset doc.version when history is not in xar. So we get doc.version>1.1 and archive.latestVersion=1.1. This bug is old. Catalin reproduces it on xwiki-1.1M1. There are many problems because we assume that archive is always begins at 1.1 in many places of core. All these problems can't be fixed for 1.1M4, so I think we need to set document.version to archive.latestVersion for sync versions.
Ludovic: your patch is simple make -1 to all versions. This is not adapt to migration for XWIKI-1582. We need more. We need reconstruct history from scratch and set doc.versions according to document archive.
I attached XWIKI-1468-resaveapi-amelentev.patch and fixrcs.groovy as sample. But these patches modify document.version and save document as new version with comment "fixrcs".
WDYT?
http://jira.xwiki.org/jira/browse/XWIKI-1582 I added a remark to this issue, which has already been committed: I created the preserveVersion option so that the version would be preserved *whether or not* the history was attached to the document (http://jira.xwiki.org/jira/browse/XWIKI-1544). The patch for XWIKI-1582 effectively reverses that behavior. There has to be some other way to make RCS happy-- perhaps by making the version of the document an attribute that doesn't have to directly match the RCS version (where the value returned by getVersion is is the content of the version field, rather than the value maintained by RCS). I want to be able to install an application (say a panels app, or a package containing many documents) on multiple wikis, and be able to tell, based on the document versions, what version of the app I'm running (which also implies the ability to ascertain whether or not the documents have been customized). Maybe the rest of you think it's an edge case, but it's something that I think has value, and is why I opened the XWIKI-1544 and submitted the patch introducing "preserveVersion" to begin with. Erin -- 'Waste of a good apple' -Samwise Gamgee
Implemented. @see Main.fixrcs-r1.xwikipage or fixrcs.xar in XWIKI-1468 Ludovic Dubost wrote:
... I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior.
-- Artem Melentyev
participants (4)
-
Artem Melentyev -
Erin Schnabel -
Ludovic Dubost -
Sergiu Dumitriu