12

I have the idea to host, plan and maintain a LEGO project (building a MOC in several steps with different functionalities) like a software in GitHub. The project should have forks, pull requests and version tracking.

  1. Is there a possibility to do this with existing software? LDD, Leocad, Stud.io in combination with GitHub or similar?
  2. How to realize a crowd/community project that builds on a LEGO model? What functionality might be needed?
Improve this question
2
  • github.com/chicks-net/lego-business-card-holder is my example of what you're talking about. I wasn't expecting much collaboration, but I like github for publishing things and showing the history of the project.
    – chicks
    Dec 10, 2019 at 18:45
  • Can you export it to a data plan like JSON or XML? Those are versionable, with a bit of work.
    – Mast
    Dec 10, 2019 at 20:23

2 Answers 2

Reset to default
9

While you could indeed manage the project with a tool like GitHub (using the Issues feature), you might be better off initially managing the tasks through a tool like Trello which allows you to create tasks and move them through various status (i.e. Planned, In Progress, Review, Complete) in a fairly simple, intuitive user interface.

An issue with managing the actual project files within source control is around the format of them - some file types work better than others when it comes to source control, and some formats of those types work better than others as well.

Git is a "Distributed Version Control System", which means that anyone can work on any file in the repository on their local machine - this is usually fine when working with text based files, but is not so good when you have binary files, because understanding the differences between two versions is often not easy. If the tool you choose stores projects in binary files, Git is probably not the best option.

I would strongly recommend that you consider a Centralised Version Control System such as Subversion (SVN) or Team Foundation Version Control (TFVC or TFS) as this allows your collaborators to "checkout" or "lock" a specific file to say they are working on it, and then when they've updated it, "check-in" their changes - this will (hopefully) get around the main pain points of trying to merge changes in these files, albeit with the caveat that you might still have people check-out a file and then "go dark" and forget to check it back in for a long time.

Sadly for you, most developers have moved to Git based source control, as it's very good at dealing with code files, and generally much quicker when working locally, allows for "offline" working, etc. and solves the problem of people working on different parts of the same file or project simultaneously, so most of the free options (GitHub, GitLab, etc.) focus on that. You might be able to use the free options within Azure DevOps to create a TFS based project, or find another SVN host for your project. Most of these also offer "Work Item" tracking for task planning and management.

In terms of the current software for building your MoC, the likely contenders are:

  1. Stud.io - uses a binary (.zip) format. This doesn't play well in Git. Furthermore it's a password protected archive, so you can't easily extract the underlying .ldr files.
  2. LDraw - uses a text based format. Potentially a better fit for Git, however the format itself would be very easy to mess up in merges if two people work on the same model files at the same time.
  3. LEGO Digital Designer - uses a text (XML) based format. Potentially a good fit for Git. While XML can get messed up in merges, it's usually easier to see in merge tools where the changes should belong, and so easier to correct/adjust if two people work on the same model file. However, this is likely end-of-life now, especially with the announced purchase of BrickLink by The LEGO Group.

    What about Studio and LEGO Digital Designer – what will happen with the two digital building experiences since they’re quite similar?
    The LEGO Group is planning to support and evolve Studio and will review opportunities for both services following the closing of the deal.

Improve this answer
2
  • 1
    I would say that regardless of the file format, text merges do not make sense for a Lego model and even a human readable format should be treated as a black box. Sure a merge might handle a color change correctly, but even if one piece is swapped out I bet any idea of a "merge" would be impossible.
    – JPhi1618
    Dec 10, 2019 at 21:22
  • @JPhi1618 agreed - it would be unpleasant to say the least, which further reinforces my recommendation for a centralised system.
    – Zhaph - Ben Duguid ♦
    Dec 11, 2019 at 10:25
7

I'll address some points from Zhaph - Ben Duguid's answer:

While you could indeed manage the project with a tool like GitHub (using the Issues feature), you might be better off initially managing the tasks through a tool like Trello which allows you to create tasks and move them through various status (i.e. Planned, In Progress, Review, Complete) in a fairly simple, intuitive user interface.

Github actually has this as well in the form of Project Boards. They integrate with the rest of the GitHub ecosystem, so you can reference issues, pull requests, assign milestones and labels, etc.

project-board

Git is a "Distributed Version Control System", which means that anyone can work on any file in the repository on their local machine - this is usually fine when working with text based files, but is not so good when you have binary files, because understanding the differences between two versions is often not easy.

This was a painful point for a long while. However, git now supports Large File Storage. It stores references to the files, so checking changes between commits would show that a file was updated and not waste space trying to calculate diffs. I have used this for images and other binary files and it works well, though it does add a small extra step to upload or download the files when pushing or pulling.

You could easily use LFS for the various binary files the programs use for creating.

Edit: File locking

I would strongly recommend that you consider a Centralised Version Control System such as Subversion (SVN) or Team Foundation Version Control (TFVC or TFS) as this allows your collaborators to "checkout" or "lock" a specific file to say they are working on it, and then when they've updated it, "check-in" their changes - this will (hopefully) get around the main pain points of trying to merge changes in these files, albeit with the caveat that you might still have people check-out a file and then "go dark" and forget to check it back in for a long time.

Git LFS also has file locking (Since 2.0, March 2017). I do agree that it is more complicated than SVN. I do not know if the web platforms or desktop apps (GitHub Desktop) show locks, but I do know that you can lock and manage locks via the command line:

git lfs lock file.ext    # lock file
git lfs locks            # show locked files
git lfs unlock file.ext  # unlock file

You can enable locking for an extension across a repo by adding *.[extension] lockable to your .gitattributes file, and if a user has locked a file and disappeared someone with the proper permissions can unlock the file with git lfs unlock file.ext --force.

Improve this answer
4
  • 1
    Good point on the GitHub's boards and integrations, however that might still be overkill for the project, and more confusing, especially if most of the contributors aren't used to all that ceremony. I also agree that LFS is a possible option, but that's more to work around the file size limits (100MB) and performance impact of working with those files. You'll still be unable to review any changes to binary files in any meaningful way. Hence my suggestion of a centralised system that allows users to lock the file centrally to say "I'm working on this" and (generally) avoid these issues.
    – Zhaph - Ben Duguid ♦
    Dec 11, 2019 at 10:24
  • @Zhaph-BenDuguid I'm not sure how GitHub's projects would be confusing, since you can use it exactly like Trello if you want. I do agree that locking is the better method for editing binary files, git LFS even supports locking files!
    – GammaGames
    Dec 11, 2019 at 15:24
  • 1
    I meant that throwing in references to pull requests and milestones might be confusing ;). Good to know about locking in LFS - feel free to update your answer with the steps required to enable that for .io files across all instances of the repo and the on going use, it's more complicated than SVN or TFS if you've got to fetch and then lock, and remember to unlock after a push... As is the nature of open-source, who knows if the 2.5 year old documentation is out of date, or whether LFS 2.9.1 has a less "early release" version of locking?
    – Zhaph - Ben Duguid ♦
    Dec 11, 2019 at 17:55
  • 2
    @Zhaph-BenDuguid Good point about updating my answer, done! It does seem more complicated than SVN and I haven't been able to find if it is supported in the various web interfaces, but it seems like a handful of the most popular git platforms do support the feature. I also haven't found anything else about updates to the locking, so it might have been "good enough" in 2017 and hasn't needed any more attention since then.
    – GammaGames
    Dec 11, 2019 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.