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:
and the result is a new model identical to aMooseModel but without
any pointer to any entity into aMooseModel?
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
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
> complete models. In this case, it probably is easier to just go for
> Solution A.
> 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
>> a class A from package P1 to P2, without changing the source code
>> may be been able to undo the change
>> Solution A:
>> We could copy the complete model, modify it. (and keep somewhere an
>> 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
>> Any thoughts on that.
>> I have the impression that solution B is easier.
>> Moose-dev mailing list
> "Obvious things are difficult to teach."
> Moose-dev mailing list
Moose-dev mailing list