Project:To Do/git

GIT Switch Discussion
So, it looks like Dolphin is switching from svn to git. While this is a purely development decision, it has serious impact on us here at the wiki regarding how we refer to revisions. There is no longer a sequential revision number system that increments with each commit. Love it or not, git is here to stay:

|Forum Topic |Google Code Discussion
 * I specifically asked for a system that continues the existing rev numbers, either by automation or by calling a commit 'revision 77xx'. So far, at least neobrain has expressed his dislike for this idea.
 * This was previously a discussion/flame war about the switch to git. It has since been deleted.

We need to figure out how we're going to deal with not having sequential version numbers. We also need to figure out how we're going to deal with the fact that revision numbers are now very long with no easy way for users to copy/paste the number into a testing or compatibility report.

Based on some light thinking, here are some options:
 * We create/extend a template that will convert from git hex numbers into our own wiki-based rev numbers. This will require a good bit of manual work to update said template, and may possibly get broken as trees are merged and moved around.  I'm not sure I know enough about git's tree and branching system to know if this is a viable option.
 * We stop supporting reports/compatibility for intermediate revs, and focus on the releases / betas / alphas. The devs have indicated that they intend to do more releases in between major versions, so that would certainly help this effort.
 * We convert the existing Template:VersionCompatibility to be a table rather than a bar, with no regard for which release comes before/after other releases.

This is a difficult problem, and one that is either going to require some changes from the devs or some serious rework of the wiki's templates on our part. What are everyone's thoughts?

--Keller999 04:16, 22 August 2011 (CEST)

OK, so some hope, per godisgovernment a restructure is occurring with one of the outcomes being... Embed the original svn revision number in each git commit, so it's easy to find which git commit is equivalent to an old svn commit. ...hopefully, with such in place, we can at least restore the historic linkages. Future linkages to revisions will likely need to use the ugly hashes (until it becomes more clear regarding how version tagging may be handled). Hopefully the promise of more frequent versions will mitigate this to some degree, and enable reliance on version numbers for reporting.

Regarding the Version Compatibility template, it's current format could be preserved by associating revisions with dates and then revising the template to use some date parsing rather than the raw version numbers to scale the entries. Setting up the associations would be a PITA, but I'm guessing it could be extracted from GIT and appropriate wiki content parsed out without too much trouble. However, maintaining such seem problematic, so I'm guessing we'll likely end up with just a shaded table.Kolano 06:29, 22 August 2011 (CEST)