What does a patch that merges two parent versions look like? about braid-spec HOT 15 CLOSED

This should be clear in the Versioning section—we probably need to edit it!

To merge, you create a version that has multiple parents. Each version contains a set of parents, and a set of patches. The set of patches may be empty. However, servers/clients usually do not send versions over the network that have no patches, because they can be reconstructed by any other client or server just by doing the merge with the same synchronization type.

from braid-spec.

OK, so if I understand correctly, each branch is first made with patches belonging to that particular branch to be in sync (content-wise) with another branch. And then another version is made which has multiple parents, but no patch really (because content-wise branches are in sync).

I have my own thoughts about the fact that merge version is not really present, but I will do that in some other issue.

from braid-spec.

A server/client MAY send a version with no patches. This can be useful to create a single versionid with which all servers/clients can refer to a set of patches, as a way to establish a shared name for that version, and collapse the memory required to refer to it.

from braid-spec.

I think we should require that. For reasons in #34 and also because it is useful that everyone has the same version-ID for that merge version to build upon. Or that everyone gets to know about other branches which just got synced and merged.

from braid-spec.

(I feel this implicit merges are premature optimization which will bite us down the road sometime.)

from braid-spec.

Ok, well let's clarify what you mean by "branch".

The current spec does not give any way for peers to refer to different branches, in the sense of a Git branch. A Git branch is basically a version -- a Tip. And whenever a new version is added to a Tip, it also becomes a branch. I think if multiple versions are added to a Tip, but not merged, they are all the Tip of that branch. And thus I think that a Branch is actually a set of versions. That's how we are thinking of referring to a Branch in Braid: a set of versions.

But perhaps when you say "branch" you are referring just to a single leaf node in the dag. If there are multiple leaves, then maybe you are thinking of each leaf as a branch. Because they look like a branch in the DAG. But they might also reference a single conceptual "line of development", which is like a "branch" in the git sense.

from braid-spec.

(I feel this implicit merges are premature optimization which will bite us down the road sometime.)

Ok, well be aware that @dglittle and I have implemented this multiple times in real systems, and it was better to not include the merge versions by default in every system. So forcing us to send those versions would have felt really draconian and bad.

I see the premature optimization as giving everyone the same version ID to work from in the cases where people stop editing. If someone keeps editing, you resolve to the same version ID anyway.

from braid-spec.

and it was better to not include the merge versions by default in every system

Can you elaborate a bit in which way it was better?

from braid-spec.

Sure. OTOH:

1. When should you send out the "joiner" version? If you receive 5 versions in parallel, then do you send out a joiner for each one?
2. Do all peers send out this joiner? If they each receive N versions in parallel, in different orders, and then each send out N joiners, and then when they receive joiners from each other, they send out a new joiner, then you could get like N^2 joiners getting sent around, to represent all combinations of mergers... and none of them actually matter!

from braid-spec.

3. If peers generate a joiner with a random ID, then each peer will send a different joiner ID that actually represents the same two versions. And then these two joiners will need to be merged. And then they would send out a new joiner based on those. And so on...

from braid-spec.

4. In the meantime, you're bloating up the DAG with a bunch of joiner versions that add no new information, but everyone has to hold onto, in case someone else sends a version based on one of them. Every version that you send out into the public version-space bloats up the amount of history you're required to store as a peer, because it means someone else might send back a version based on that one.

from braid-spec.

Now, it can be useful to orchestrate all peers together to send a joiner in a specific way that doesn't have these problems, and allows peers to settle down on a single version, in the case where a number of outstanding parallel versions have been hanging out in existence for a while, like for 10 or 20 seconds. And this is a fine feature to add, and makes the system super elegant. But it took us a while to implement it. We only bothered a few weeks ago. We had to think it through, and be quite specific in a couple places. And we can specify this later. But the nice thing about it is that it's optional -- if you don't require everyone to send joiners all the time, you don't have to specify the right way to do it and how to solve these problems. And then people can come up with their own specific solutions to the problems, without impacting the core braid spec.

from braid-spec.

But perhaps when you say "branch" you are referring just to a single leaf node in the dag. If there are multiple leaves, then maybe you are thinking of each leaf as a branch. Because they look like a branch in the DAG

This is my understanding of a branch. So multiple concurrent tips. And you want to merge multiple tips into one tip.

from braid-spec.

Do all peers send out this joiner? If they each receive N versions in parallel, in different orders, and then each send out N joiners, and then when they receive joiners from each other, they send out a new joiner, then you could get like N^2 joiners getting sent around, to represent all combinations of mergers... and none of them actually matter!

So those are all good points.

But a side question here: I would assume that if I am getting those other versions AND I have not yet send out my versions out that then I rebase my changes on top of other versions. Then merging is not necessary. But if I have already send out my versions, then yes, I should announce how things got merged.

But maybe here is the difference. Merge commits in git are not just resolving branches, but also record how conflicts got resolved. In Braid you simply resolve those conflicts by (in git language) adding a commit to your branch first and then there are no conflicts anymore. So recording that there is a merge is not necessary, this is what you are saying?

from braid-spec.

Thanks for all those explanations. They make a lot of sense. I will be closing this question for now.

from braid-spec.