I think we should have a Papyrus project concept.
-----Message d'origine-----
De : Thibault LANDRE [mailto:
thibault.landre@xxxxxxxxxxxxxx]
Envoyé : mardi 20 octobre 2009 10:44
À : GERARD Sebastien 166342
Cc : Papyrus Project list; Kenn Hussey; SZADEL Thomas
Objet : Re: [mdt-papyrus.dev] Specification of the single file management
The Eclipse project concept doesn't suit your needs ?
GERARD Sebastien 166342 a écrit :
> One advantage of zip is its ability to be able to embed other information in any kind of format.
>
> -----Message d'origine-----
> De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:
mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Thibault LANDRE
> Envoyé : lundi 19 octobre 2009 17:07
> À : Kenn Hussey
> Cc : Papyrus Project list; SZADEL Thomas
> Objet : Re: [mdt-papyrus.dev] Specification of the single file management
>
> Kenn,
>
> thanks for your comments.
>
> Kenn Hussey a écrit :
>> Thibault,
>>
>> This is a great starting point. A couple of comments/observations:
>>
>> - we should get into the habit of using the term "resource" rather than
>> "file" because, ultimately, it shouldn't matter (to the tool) where/how
>> the content of a model/diagram is stored
> You are right. I'll fix it
>> - I think the requirement to support containment proxies
>> (control/uncontrol actions) necessarily means that more than one
>> physical resource will make up a model
> I agree. Each controlled model corresponds to a physical resource.
>> - just because compare/merge tooling doesn't support comparison of
>> binary resources out of the box doesn't mean we should exclude it as a
>> native serialization format, at least in my mind
>
> In fact, it is possible to compare zip file. See
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273229
> I have run a quick test on my environment and it seems to working fine
> (Text Compare, EMF Compare...).
>
> However it is not possible to do any merge.
> But maybe we shouldn't allow user to merge their models. The *.emf,
> *.notation, *.di are dependants. I think, merging will lead to more
> issues than it solves. Advanced users could still unzip/zip their binary
> resources to merge them.
>
>> - if we want to support arbitrary repositories (e.g. CVS vs. CDO, etc.)
>> transparently, we may need an "internal" storage structure/format that
>> is different from the source/storage format
> I don't really get this point. Does this mean we should have a
> (de)serialization mechanism before store our model in repositories ?
>
>> - we should also consider "backup" resources, e.g. so that we can
>> support things like autosave
> Is the Local History not suited here ?
> However we could add a mechanism to perform an autosave that user can
> configure through preferences.
>
>
> We propose to regroup all the content in a single file (EMF also deals
> with it really well). We prototyped both solutions, and it ends up that
> the single file seems to be the best solution. We certainly missed some
> impacts / functionnalities.
> Can you give us some arguments why having all the content in a single
> file is not a good solution ?
>
> To be clear, we are not "pro single file" or "pro zip". We would like to
> find the best solution to implement this key functionnality as it will
> be very difficult to modify our choice in the future.
> We have not commited (we could have to) the patch for this reason.
>
> By the way, has anyone tested the patch proposed ?
>
> Regards,
>
> Thibault
>> Cheers,
>>
>> Kenn
>>
>>
>> 2009/10/19 Thibault LANDRE <
thibault.landre@xxxxxxxxxxxxxx
>> <mailto:
thibault.landre@xxxxxxxxxxxxxx>>
>>
>> Hi all,
>>
>> You will find attached a proposed specification for the management
>> of resources in Papyrus.
>>
>> Any remarks / comments is welcomed.
>>
>> Regards,
>>
>> Thibault
>>
>> _______________________________________________
>> mdt-papyrus.dev mailing list
>>
mdt-papyrus.dev@xxxxxxxxxxx <mailto:
mdt-papyrus.dev@xxxxxxxxxxx>
>>
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
>>
>>
>
>
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
