How to keep this repo in sync with the original development line?

Foadsf commented 4 years ago

Sadly the original developer of the software does not comply with the common programming best practices. He used to publish binaries and zip files on SourceForge, then he switched to his blog. and right now he only publishes source code as zip files plus binaries (only for Windows?) on his Patreon. I have tried to collect whatever code I could find on the internet and then convert the svn structure, to git. we now have several repositories:

This repo, which I hope to become the main line of development in the future
The SimulIDE03 repo, which is what I have been working on trying to make the latest version at the time of the fork to a stable cross-platform software.
there are the SimulIDE_0.3.12-SR8_Sources and and SimulIDE_0.4.13-Final_Sources, which are the duplicates of what the original developer published on his Pateron.
The SimulIDE_SF which is a duplicate of what I could find on SourceForge.

As you may see it is a mess. I'm looking forward to seeing your ideas that how we can clean up things and merge everything in or two repositories.

ghost commented 4 years ago

IMHO, there are two different tasks:

First, merge all the projects, and try to keep the history (SimulIDE_SF seems to have a lot of commits, I would keep them), and use tags or release branches as a starting point.

Once you have your standard branches clearly defined (i.e. develop, release/0.3.12, etc.), use a "vendor branch" for the code that comes from Patreon.

pratikpc commented 4 years ago

Also are there benefits of keeping https://github.com/SimulIDE/SimulIDE/tree/master/src/simavr up-to-date with https://github.com/buserror/simavr?

Mihaylov93 commented 4 years ago

There should be but there also could bring unexpected issues, I would say instead of having it inside the repo (Usually bad practice) we should use git submodules.

pratikpc commented 4 years ago

@Mihaylov93 agree with you

But Git Submodules do not support adding only a subdirectory right?

Mihaylov93 commented 4 years ago

Yes, there is ways to set the subfolder as a submodule but I agree with this answer here https://stackoverflow.com/a/5303850 I would live with having the whole repo as submodule

Another possibility is to have a fork and use it in this project, that way we also have some form of versioning.

Minetrain2002 commented 1 year ago

what about this https://launchpad.net/simulide was linked to on the blog here https://www.simulide.com/p/home.html

ppenguin commented 1 year ago

Using this and this I could download the most recent source tree with one curl command:

curl -SLo simulide.tgz "https://bazaar.launchpad.net/~arcachofo/simulide/1.0.1/tarball/1425"

I guess it should in theory be possible to make a github action that does this automatically (possibly would need timed execution and some scraping to find the most recent revision), and then automatically merge the changes into the chosen branch of this repo, along the lines of (executed e.g. every week via GHA cron functionality)

create and checkout in this repo the branch upstream-copy

download and unpack the source tree according to the above, e.g. sth like

curl -sL "https://bazaar.launchpad.net/~arcachofo/simulide/1.0.1/tarball/1425" | tar -zxv -C $(pwd) --strip-components=3 -f -

commit and push
checkout our tracking branch, e.g. upstream
merge upstream-copy into upstream
delete upstream-copy

Of course if one is willing to occasionally perform these steps manually (the number of commits seems to be between 0 and about 10 / month) these steps aren't so time consuming...

One could then have an own main which often merges changes from upstream but contains additional improvements...

(I couldn't make these instructions work for me to directly clone the repo with git, might also be related to restrictions that are on the repo only download with password?)

ppenguin commented 1 year ago

As a test and PoC I made a nix flake that can build and run almost directly (it needed some minor fixes) from the current upstream trunk, can be tested like so:

nix run "github:/ppenguin/SimulIDE/?ref=from-scratch-upstream-trunk-1723&dir=.nix#simulide"

This is mainly to prove that upstream can be built declaratively, which means virtually no maintenance overhead. It may as well be possible to use brz in the nix derivation, thereby making it act on a "live-pulled" revision from launchpad. While it would arguably be "better" if upstream would use git, this is (for nix users at least) a feasible way do do spin-offs that have relatively minor modifications (any that can be added by patching).

SimulIDE / SimulIDE

How to keep this repo in sync with the original development line? #9