What is the best workflow?

[hdavatz]

How do we work in parallel on this family tree?

I created a fork and added e.g. Thomas 2 tree as a branch. I plan to merge the changes in to master branch. This may cause problems when merging into origin (after a pull request).

Any ideas how to handle or prevent conflicts with IDs etc. ?

[bcat-eu]

Hey @hdavatz thanks for contributing! If you based your changes on existing exported file https://github.com/bcat-eu/davaz/blob/master/davaz.gramps - just make sure you export the changed DB as described here https://github.com/bcat-eu/davaz#davaz-family-tree then you can send the PR and we will merge it, after that when we get to adding people, we will load the .gramps database that includes your changes.

In case we have conflicts (if someone pushes something while you make changes) - it's XML and we don't use compression, so it should be possible to solve these without breaking anything.

[hdavatz]

One more question: Is it ok when I put/merge my changes to 'master' branch? (Currenty I added them to a separate branch)

[bcat-eu]

@hdavatz you will only be able to send a pool request - a request to merge changes from the branch that you created in your forked project (I guess it's thomas2 branch). It's fine send a request a merge into master :+1:

[bcat-eu]

A bit more info after looking at https://github.com/bcat-eu/davaz/pull/5

There is one quirk which has more to do with Gramps, but affects our workflow - importing a family tree into existing one merges it instead of replacing. So if I import the updated tree after merging external changes in github, it will create duplicates of all existing people and add new ones. To import actual XML from the repository one would need to start an empty family tree (Family Trees > Manage Family Trees > New). We could also use that as a feature if we ever had conflicts that we can't solve.

I gave closer look at the diff and our potential workflow, there are only few of us so it's not that we'd have too many conflicts, but if we do, it's better to have a plan on how to go about them.

Here we work with XML that is generated automatically and not written per hand, so mostly it's about knowing what parts might have conflicts and how we can them.

First we use different versions of gramps, but only slightly: ours is 5.1.2 and yours is GrampsAIO64-5.1.3-2m though it doesn't seem to make much of a difference as to generated XML (it's still http://gramps-project.org/xml/1.7.1/). We use the version that Ubuntu LTS repository has https://packages.ubuntu.com/search?keywords=gramps which is more or less fixed and will be updated from time to time, so if you decide to upgrade your version then we'll have to make sure it still generates the same XML.

The XML itself seems to be about generating <person>, <family> and <event> nodes (we also have <places>, but there's only one and it uses similar logic). Each such node has few properties - handle (UUID-like hash which is used as an actuall identifier to connect different nodes to eachother), change (looks like int timestamp of the last change) and id - this one looks like a string of a letter identifying the node ("I" for person, "F" for family, "E" for event) and a sequential integer. I am not sure as to why it exists, but it will cause problems if we do changes in parallel, as you already mentioned here https://github.com/bcat-eu/davaz/issues/4#issue-740201782. Since these IDs seem to be sequential, we will get conflicts if we add data in parallel, to fix these, the branch that needs to be merged would have to find the latest node of each type in master (they are generated top to bottom so the one with the last number would be the last one in the XML file), take its number, add 1 and adjust its own nodes so that they start with that number and go from there.

Example for persons: Master has I0127 as ID of the last person and my branch has few entries that are below 127 so the IDs are duplicated. I'd have to change the ID of the first new person in my XML to I0128 and then go down the list and make them I0129, I0130 etc. Then do the same with events etc, that should suffice. As a side note - the more changes one has, the more work it is to adjust these IDs, so it's better to merge often.

I also checked what happens if we don't do that and could see no actual problems: I have created a duplicate ID (I0022) which was shared by 2 person nodes and imported the resulting XML, I could see this ID in the UI but other then that it didn't seem to affect anything. So it seems these IDs are mostly cosmetic and the steps to make them unique as described above are actually optional.

If we ever had a conflict on handle property, that would be tricky cause the nodes are linked using values of that property, but they look like UUIDs so I assume it conflicts are so unlikely that we can consider them impossible.

There is also priv property that appears on some person nodes and seems to always have a value of "1", I assume it's some boolean set in the UI which is of no consequence as to possible conflicts.

[bcat-eu]

@hdavatz I've also added info to the readme, feel free to give feedback or we can close this ticket

[hdavatz]

@bcat-eu Thanks for this useful information Yuriy!

After synchronizing with your repository I will import the gramps xml file (as a new database) and continue with adding some more persons and families to the Thomas tree. (For now I continue with the Windows Version, but if better, I can also change to a Linux version (e.g. Ubuntu Mint)). Let me know if anybody else wants to add stuff, so I can issue a pull request and pause adding. For me it is ok to close issue #4.

[bcat-eu]

@hdavatz

I can also change to a Linux version (e.g. Ubuntu Mint))

You absolutely don't have to change your OS for that reason :)

Let me know if anybody else wants to add stuff, so I can issue a pull request and pause adding.

Will do, thanks for your help!