let us imagine that we would like to see what would happen if we would move a class A from package P1 to P2, without changing the source code and may be been able to undo the change
Solution A: We could copy the complete model, modify it. (and keep somewhere an history)
Solution B: We could change the model and keep an history of the changes (move A P1 P2).
Solution C: I could cache in each model a timestamp similar to what frederic pluquet did and know at which version modification we are. then for a given changes I could get the model by getting entity at the same level or lower.
Any thoughts on that. I have the impression that solution B is easier.
stef
I would suggest to use Hismo :).
The default behavior for Hismo is Solution A, because typically we have the versions and we need to extract histories. That is why we have duplicated models.
But, for example in the case of YellowSubmarine - the SVN client, we do not duplicate that information. The trick there was to not use the default EntityVersion which requires a corresponding entity for each version. Instead, he subclassed AbstractVersion to just hold the diff and then recompute the content of the entity.
However, you also have to consider what the end goal is. If you want to perform computations on each version, you might end up needing both complete models. In this case, it probably is easier to just go for Solution A.
Doru
On Jun 27, 2008, at 6:57 PM, Stéphane Ducasse wrote:
let us imagine that we would like to see what would happen if we would move a class A from package P1 to P2, without changing the source code and may be been able to undo the change
Solution A: We could copy the complete model, modify it. (and keep somewhere an history)
Solution B: We could change the model and keep an history of the changes (move A P1 P2).
Solution C: I could cache in each model a timestamp similar to what frederic pluquet did and know at which version modification we are. then for a given changes I could get the model by getting entity at the same level or lower.
Any thoughts on that. I have the impression that solution B is easier.
stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Obvious things are difficult to teach."
indeed I do not really know. I think that we will go for version B in our case
stef
On Jun 27, 2008, at 11:54 PM, Tudor Girba wrote:
I would suggest to use Hismo :).
The default behavior for Hismo is Solution A, because typically we have the versions and we need to extract histories. That is why we have duplicated models.
But, for example in the case of YellowSubmarine - the SVN client, we do not duplicate that information. The trick there was to not use the default EntityVersion which requires a corresponding entity for each version. Instead, he subclassed AbstractVersion to just hold the diff and then recompute the content of the entity.
However, you also have to consider what the end goal is. If you want to perform computations on each version, you might end up needing both complete models. In this case, it probably is easier to just go for Solution A.
Doru
On Jun 27, 2008, at 6:57 PM, Stéphane Ducasse wrote:
let us imagine that we would like to see what would happen if we would move a class A from package P1 to P2, without changing the source code and may be been able to undo the change
Solution A: We could copy the complete model, modify it. (and keep somewhere an history)
Solution B: We could change the model and keep an history of the changes (move A P1 P2).
Solution C: I could cache in each model a timestamp similar to what frederic pluquet did and know at which version modification we are. then for a given changes I could get the model by getting entity at the same level or lower.
Any thoughts on that. I have the impression that solution B is easier.
stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Actually I do the solution B but I do not use any thing for changes history (for the moment I do not need the changes history).
Doru, When you say that the default behavior for Hismo is Solution A you wont to say that in hismo we can do something like this: aMooseModel deepCopy and the result is a new model identical to aMooseModel but without any pointer to any entity into aMooseModel?
hani
On 28 juin 08, at 07:52, Stéphane Ducasse wrote:
indeed I do not really know. I think that we will go for version B in our case
stef
On Jun 27, 2008, at 11:54 PM, Tudor Girba wrote:
I would suggest to use Hismo :).
The default behavior for Hismo is Solution A, because typically we have the versions and we need to extract histories. That is why we have duplicated models.
But, for example in the case of YellowSubmarine - the SVN client, we do not duplicate that information. The trick there was to not use the default EntityVersion which requires a corresponding entity for each version. Instead, he subclassed AbstractVersion to just hold the diff and then recompute the content of the entity.
However, you also have to consider what the end goal is. If you want to perform computations on each version, you might end up needing both complete models. In this case, it probably is easier to just go for Solution A.
Doru
On Jun 27, 2008, at 6:57 PM, Stéphane Ducasse wrote:
let us imagine that we would like to see what would happen if we would move a class A from package P1 to P2, without changing the source code and may be been able to undo the change
Solution A: We could copy the complete model, modify it. (and keep somewhere an history)
Solution B: We could change the model and keep an history of the changes (move A P1 P2).
Solution C: I could cache in each model a timestamp similar to what frederic pluquet did and know at which version modification we are. then for a given changes I could get the model by getting entity at the same level or lower.
Any thoughts on that. I have the impression that solution B is easier.
stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Stéphane Ducasse -
Stéphane Ducasse -
Tudor Girba -
Univ-SAVOIE