On 01/29/2016 09:02 AM, Bernhard Pieber wrote:
Hi Dale,
I am trying to understand this a little better. If a package containing
metadata would be changed using a dialect which cannot interpret the metadata,
wouldn’t or at least couldn’t it be broken or lost afterwards for a dialect
which tries to interpret the metadata? At least if my assumption is correct
that the metadata is related to the code in some way?
Bernhard,
Very good question.
You are absolutely correct, the act of writing a new version of a
package using a different dialect would indeed destroy the
platform-specific meta data.
However, it is NOT expected that two different dialects (with different
disk formats) share the same commit.
If dialect A has committed a package, then dialect B is expected to be
able to read the package written by dialect A. Being able to read the
package means that all of the information that is common between the two
dialects will be preserved ... in FileTree, this means that:
- all of the class and instance method source is readable and shared
- the method category is readable and shared
- the name, superclass, instance variables, class instance variables,
pools, class category, and class vars for classes is readable and
shared
This is an awful lot common data .... things like traits or namespaces
are dialect specific and are ignored by dialects that don't have them
when reading the package ...
When dialect B has read, loaded/compiled and tested the code in the
package, the developer has a couple of choices to be made when writing
out a new package with her changes:
- use the current branch
- use a new branch
I think that using a new branch is the cleanest option. When I port a
project like Zinc[1] to GemStone[2], the master branch is preserved for
the Pharo-specific code. I create a gs_master branch where the GemStone
code goes. When Sven commits new code in his repo, I merge the changes
from the his new master branch into my gs_master and resolve conflicts
if any, run tests and I'm done.
The vast mjority of the code base is shared between GemStone and Pharo
and only the places where I made changes in porting Zinc to GemStone
have the potential for conflicts. Running the tests should highlight
any impacts not covered by direct conflicts and if there were some
Pharo-specific meta data that I deleted on my branch that causes a test
to fail then that is up to me to research and fix.
When I have changes to feed back to Sven, I make those changes on a
separate "topic branch"[3] that is merged into gs_master for my use. I
then cherry-pick[4] the topic branch commit into a separate topic branch
off of the master branch (this picks up only the changes I made on the
topic branch) and open a pull request[5] against Svens repository ... if
Sven were using travis-ci, tests would be run automatically against a
merge of my changes into his master branch ... if the tests are green
and the code passes Sven's scrutiny in a code review he merges my
proposed changes into his master branch...
GemStone and Pharo share a common disk format (not 100% common), but
since git only merges the deltas for a commit, it is relatively easy to
keep the meta data differences isolated while still sharing the vast
bulk of the code and classes ....
Dale
[1] https://github.com/svenvc/zinc
[2] https://github.com/GsDevKit/zinc
[3] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[4]
http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html
[5] https://help.github.com/articles/using-pull-requests/
