Re: [Monotone-devel] Change-Version Duality

[Tobias Oberstein]

Hi,

> What we did was "line based pinning". We introduced a new pin
> for every new line inserted. One can imagine other pinning

Attached are figures illustrating 3 examples for line based
pinning. On page 1 you see the track of the HEADs of each
Repository I, II and III - that is a version based view of the
repositories restricted to the latest version: HEAD.
there's only one linear line space ("file") since we looked
at the simplified problem.

When repository I is created, the red pin is created. Each time a
new pin is created, an arbitrary color (e.g. random) is taken, however
the color must be new to the repository (no pin must yet exist with
the new color).

Now, after the user editing the local working copy and committing
his changes with the option "--with-line-pins", a standard diff is run
against HEAD, one inserted chunk containing three lines is identified
and for each new line a new pin is inserted (pins yellow, green, blue).

Next, a repository II is created from branching off HEAD from
repository I. The user of repository II edits his local working copy
and commits .. this time without the "--with-line-pins" option.
The working copy is diff'ed against the HEAD version of repository II
(branched off I:HEAD). The result is one removed chunk containing
one line and one inserted chunk containing two lines. Since
"--with-line-pins" was not given, no new pins are created and the
complete block between green and blue pin is replaced.

Similar things happen to the repositories I and III. Then, the
modifications made to II and III are be merged into I. The merging
takes place using pins as switching points and for safely detecting
conflicts. Since pins don't depend on line numbers, this turns to
work out straightforward and the process can be easily envisioned by
following the pins through versions.

I'll heavily cut;) The moral of the two remaining pages is: you can
create merge conflicts by either having stuff in between existing (at
point of branch) pins modified more than once in one merge or by adding
a new pin above an existing pin more than once in one merge.

> methods:
>   - diff hunk pinning

the three examples above used either no pinning or line based
pinning, when the option "--with-line-pins" was given during
a commit. With line pinning, a new pin is created for each
line in every inserted hunk identified during the diff done
at commit time between the HEAD version and the working copy.
With diff hunk pinning, only one new pin is created for
each inserted hunk regardless of how many lines the hunk
contains.

>   - block structured pinning
pinning stuff like
11 void foo () {
12 ..
..
29 }
from line 11 to 29 in one block.
>      - auto block pinning
above automagic: requires a knowledgable diff flavor;)
>      - user block pinning
above with editor support: press "insert new versioned block"
>   - character pinning
character based diffs combined with one pin per character per
inserted hunk

Cheers,
Tobias

pin-based-branching-merging.pdf
Description: Adobe PDF document