Add older releases to the repository

[Gabr-F]

First of all, let me thank you for bringing this project to GitHub and continuing to develop it (and for making it in the first place, of course!).
I became interested in it a few months ago, when it was still on SourceForge, and had become convinced that it was stone-dead. I was flabbergasted when I saw "5.0" today!!

---

Now, here's the actual, first, request. It's not very fun, I'm afraid:

Would it be possible to add to the repository the releases before 2009-11?

I suppose that's the date you started to use a VCS (svn), and that's the reason the repository starts there.

However, I imagine you still have copies of the code of at least the major releases before that, right? Apparently at least the 3.0 and the 2.1 versions used to be downloadable from SourceForge; they are not anymore but I imagine you kept copies of at least them.

Why would I want them?

To help studying the code:

Currently there are 136 files just in the Framework part, with very little documentation, so it's very hard to understand even where to start to read the code.

In what's currently the first commit of the repository there were a lot less files (47 in the Framework), but still enough to make getting familiar with the code quite an endeavour.

However I imagine things were a lot simpler in the first releases.

They were for sure very different from the current code (looking at https://sourceforge.net/p/simplyvbunit/news it appears you rewrote everything more than once), but they would most likely help to understand how things started and how they got to the current point, and so to gradually understand the current code.

What's more, the core of the source is probably still where it was in the first versions, so studying them can tell you at the very least where to start from with the current code.

By the way, yes, the lack of documentation is a problem in itself (maybe I'll make a separate Issue about that), but even if the code were extensively documented looking at how it was in the first releases would be helpful in some cases. At the very least, it would be interesting!

How?

You are probably thinking, "this guy doesn't know that you can't change a git repository's history".

It's not like that, I do. However:

1. Git has a feature to indeed change a repository's history, although not really: it's git replace.
   It lets you "cover" individual commits with different ones, so that the commands and tools that support the feature behave as if you replaced the commits, but without changing the hashes of the following commits.
   It's a trick, but it works rather well in my experience.
   This allows to put new commits before the beginning of the current repository, by replacing the first commit of the repository with one identical except for the addition of a reference to another commit (this commit would be the most recent one of the chain of commits you want to add).
   It's not very fun, but not as hard as it might appear either. I could guide you in the process if you decide to take this step.

2. The move to git and github was very recent, and you appear to have made only 9 commits since then. This means that we are still at a time where rewriting the repository would not be unthinkable: there are probably very few people who already cloned it, there are no references to previous hashes in the current commit messages and it would probably not cause significant disruption to the developers (you) to have indeed the history rewritten.
   Given the favourable state of things, I think this option should be given serious consideration: git replace does seem to work well but it's a trick, and using it is likely to bring some problems, for some uses, now or in the future. So as long as it's conceivable to make a complete rewrite instead of using it, it's strongly advisable to consider doing so.
   If you do take this path, remember to put a very prominent note in the README.md warning of the rewrite, with instructions for what to do if you had already cloned the repository.

What?

Even just one old release would help a lot, but if you happen to have more snapshots, possibly even between the public versions ("manual", copy-and-pase, version control, or possibly even commits of a VCS you used only privately, if you did) , it would help a lot to include them as well. The more the better, to understand the evolution of a software project.

Why now?

Well, I ask you now most of all because I just now got to know that the project is still alive, but aside from that we're now very close to the ideal time for doing stuff like this, as I explained above.
So it's worthwhile to give this thing a serious consideration now, before enough people clone or reference the repository that rewriting it becomes inconceivable.

Alternatives

A simple alternative of course would be to simply re-publish the code of the old versions somewhere.

Entirely acceptable, but if we can, including them in the repository itself would add a considerable amount of convenience for the "students"/code archeologist.

Minutiae

If you do end up rewriting the history, it might be helpful (for someone) to add a tag, in the rewritten repository, to what was the first commit in the current history, to help them understand what happened and cope with it.
It might be called "previous_first_commit", with a lengthier explanation in its comment (annotation).

Versions tags

As per Issue #3, if you do this it would be better to add tags for these old versions as well.