[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-papyrus.dev] Specification of the single file management
|
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
>
>
