Original codebase mismatch (related to #51)

[RattleSN4K3]

By investigating the issue about #51, I've checked some code and was missing a specific code part. Therefore I began checking the legacy source code on SVN and wonder why the missing part was there (in mostly all revisions).

This repo was created from the trunk codebase with the commit message (of c4fc4aaf35a1c6469f747f50afcbac10be9e3342) stating:

codebase of USDX V1.2 trunk (alpha)

moving from sourceforge to github....

So I wonder, what kind of trunk it is based on... which revision. From the source, the last known proper SVN commit ID is 3152 (with the trunk actually being continued up to 3196).

Are all changes from 3152 up to 3196 (excluding branch/tag revisions) merged into Github? What kind of codebase is the initial project source based on since the c4fc4aaf35a1c6469f747f50afcbac10be9e3342 and 3152 are vastly different.

The latest (logged) change is: UScreenSong.pas 3152

However, there is a mismatch. If the latest used trunk revision would be 3152, most of these files should stay lower 3152 or should be different. But there are a lot of files using a different (stated) version. It seems like the used codebase for git/Github wasn't a clean trunk version but a locally changed and patched version.

In most cases (haven't got the time to check all), changes made after 3152 are merged but the SVN ID is not updated. And the initial trunk codebase still has newer additions. This makes following the history a lot worse (the reason what source control is good for).

That said, back to why #51 brought me here writing this text, I cannot locate why the specific code is missing from the git/Github repo. The latest SVN trunk (3196) does have it (tracing it back, it existed from rev 1 on) but Github initially has it removed.

Am I correct that this Github repo is based on several changes from another 3rd party mod where features eventually got removed?

Really bad to have no continous history with such a huch gap.

[AlexanderS]

I noticed that history gap, too. But @basisbit said, that it would be impossible to merge the WorldPartyMod with the trunk version of the ultrastardx-svn in smaller commits, so that it would be reviewable. I would definitely prefer a joined history without a big first commit.

The version in this repo differs a lot from the trunk svn version (only for src/):

385 files changed, 87370 insertions(+), 12969 deletions(-)

[RattleSN4K3]

The WorldPartyMod (or what ever version is the initial commit) doesn't need to be split into commits (if it's to difficult, which I think it is if there's no repo/source control). The initial commit (c4fc4aa) should have been rev#3196 (UltraStar-Deluxe/mirror@feec493) instead. And the changes could be another commit (like "Merged WorldPartyMod").

If i'm correct, the whole repo could be re-created. And instead of committing c4fc4aa, commit UltraStar-Deluxe/mirror@feec493 instead first, and then c4fc4aa (similar to rebasing). The commit ids are hashed by the content (not sure if the resulting file or only the difference), therefore any following commit keeps the IDs as well. In that case the repo has to be forcibly pushed to Github thouhh. Not sure how well that would turn out related to comments, issues, pull requests (log), etc.. Could be tested in another repo, without touching anything of this project/repo. It would result into a small work but not that much as this repo is only at ~290 commits.

Related to #51, here's the specific change (and any related code line) which creates the problem with the "import screen". UGraphic.pas #L763 @feec493

[AlexanderS]

The IDs of all commits will change. The commit hash also includes all previous commits, author info, commiter info and message (see here) . If you change the starting point, all following commits will change.

[RattleSN4K3]

The IDs of all commits will change

Thought so but wasn't sure. The hash includes the parent hash which is likely to change (due to content), time could be tricked - otherwise after the WorldPartyMod merging, all content would be the same and thus the hashes of all files, but sadly with the addition of the parent hash, there's no way to get into that chain resulting into the same hashes after c4fc4aa. This is a reason to consider doing something like that early on. Is it better to have an continous history or possibly broken PRs/comments on here? Don't know, without much into looking how well it would work, I personally would go for a consistent history.

[basisbit]

the USDX World Party code was based on the sourceforge code from some commit back in 2010. When I finally got my hands on some code of some world party version, it was in a state where it was not possible to publish it anywhere. We discussed this issue quite a bit back then in #ultrastardx@QuakeNet and the result was that it would not have made any sense to start off with the last commit of the sourceforge repo as first commit of the github repo just to then replace everything by one huge commit. After that decision, I worked on going through each file using visual diff tools to manually merge the different versions (you could call them totally different "branches" - USDX 1.1 from sourceforge svn, USDX WP, ignored patches and community based patchworks), rewrote lots of horrible code, replaced stuff that was definitely infringing copyright of others, replaced the tntUnicodeUtils and bunch of other stuff.

[RattleSN4K3]

I've diffed both versions 3196 and c4fc4aa and the changes are only small, it would have been a lot better to know why a specific change was made. With c4fc4aa being the first commit and no connection to the SVN repo, it's the end of route where you could properly do revision control. You don't know whether a change was done by the party mod or the original repo.

I may create a repo (not sure where) which would allow having a proper diff to look at. SVN@3196 < X < Git_c4fc4aa

Gonna check what's the best location. It could work as branch tho and you'd be able to diff against that branch easily. Or a different repo (or in mirror). Not going to do anything before trying it. Hope it'll work.

[basisbit]

I've diffed both versions 3196 and c4fc4aa and the changes are only small,[...]

check again.

You don't know whether a change was done by the party mod or the original repo.

You don't know this anyways, as development was sort of parallel for a few years.

[RattleSN4K3]

check again.

I still have it opened. What are you trying to say? Small is relative. For me the changes aren't. It's only the diff and not if either version works and the required fixes for it.

Changed files (ignoring CR/LF mismatch, SVN meta data, including binary files): 169 Removed files/folders: 677 New files/folders: 703 Identical (ignored/including CR/LF mismatch, SVN meta, binary): 831

The original SVN repo as tree, UltraStar-Deluxe/mirror@feec493, is required to properly diff against the working dir.

[basisbit]

that comparison is not fair as this change was done about 5 months after the merging and bunch of changes were ported to the sourceforge repository already at that time.

[RattleSN4K3]

What comparison? I was not comparing something against current working tree. I was stating what the gap is all about - "last svn repo" with "first git repo" (and trying to ignore files with wrong SVN meta data, the LF/CR mismatch [SVN is mostly CRLF; GIT mostly LF]).

What change do you mean, c4fc4aa? Why does the time matter?

[basisbit]

"closing" this issue here in the issue tracker so it doesn't just fill up the issue list. I still don't know how to handle with this issue as we didn't agree on a solution so far. Backlog label is attached so that the issue doesn't get lost.