Mechanical designers are usually not familiar with software engineering. Learning Git commands and managing them by typing them in every time will be a pain. When working on branches, if team members don’t honor their commitments to each other, the final merge may not go well because the data will be twisted. This is why it’s important to have a team leader with good teamwork and design data management skills. Since design data is mostly binary, Git’s powerful diff feature, which is great for managing text data, may not be as useful. As a result, there is a risk that the size of the data will increase significantly with each version update. Frequent updates can consume a lot of space. You’ll need to partition your repositories for each project. The concept of mixing and matching into one big repository, as in a traditional PDM, can make it difficult to “distribute” to local PCs. (because the overall capacity becomes too large).

https://md.opensourceecology.de/lXMIhqj5QDWxgKJax3GYCw?view#

Robert pointed me toward's Opulo's approach: https://github.com/opulo-inc/lumenpnp/wiki/Contributing

• LFS can be the locking mechanism (though is it a good idea to use LFS for files that don't require it?)
• Acquiring a lock as an outside contributor seems a bit awkward, maybe a "Git PDM" intermediary service could still help.

Timm is working on this file on another branch and renaming it. Click on Timm's branch in the history view to see their version (or really just click anywhere on the history view to toggle the states -- done like that since it's just a mock).

Working title, press the gear icon in the bottom right of the page to change it (visible when this annotation is closed).

• Maybe: "Open Project".

• Create new -> new local project / (new synced project) -> then login!

• "Retrieve synced project" (maybe alt text: clone repository)

Synced to a local folder which is watched for any files added / removed / changed.

• This concept is of a multi-platform desktop app that sits alongside FreeCAD / Solidworrks
• Tauri could be an interesting candidate for implementation (more performant, lighter alternative to Electron)
• Another required piece is a synchronization service to communicate locking/editing info between apps.

The concept is a simpler view of Git:

• All branches on the remote are mirrored locally and kept in sync
• Users own their branches completely, you cannot commit to someone else's branch.
• Maybe a unified branch naming scheme ,e.g. {username}/{n} i.e. jstirling/1, jstirling/2 etc. would make sense

Open questions:

• Is locking a manual operation or something that happens automatically?
• Should it be called "locking" or maybe just "someone is editing".
• Should locking prevent edits (how?) or just warn about them?
• How does the user lock and unlock? Could it happen automatically?
• Does an assembly that includes a locked part automatically get updated, should it be locked too? (Would CAD software integration be required for this?)
• The user is working on a branch, how should they contribute their work? (Should we be able to open merge requests from Git PDM?)
• What happens to local files as the user navigates the git history?

• Files view seems easier to implement than assembly view, maybe start there.

Jstirling is working on this file in another branch.

Continually synced to a git remote.