Difference between revisions of "Project:To Do/git"

From Dolphin Emulator Wiki
Jump to: navigation, search
(New Rev Formatting)
(New Rev Formatting)
Line 40: Line 40:
  
 
I haven't been able to work out means to do the sort of text parsing that would been needed for that nicely, though a setup with the base rev and increment specified as separate parameters would probably work.[[User:Kolano|Kolano]] 15:53, 23 August 2011 (CEST)
 
I haven't been able to work out means to do the sort of text parsing that would been needed for that nicely, though a setup with the base rev and increment specified as separate parameters would probably work.[[User:Kolano|Kolano]] 15:53, 23 August 2011 (CEST)
 +
 +
 +
Right now the best thing is to wait until builds are steadily being built again at this wiki home site, and after that use the new (semi-official) convention, whatever it's going to be, unless one of you guys is mamario and can tell us beforehand what's it going to be. [[User:Otomo|Otomo]] 09:31, 27 August 2011 (CEST)

Revision as of 06:31, 27 August 2011

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:

Topic

  • 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.

Code Discussion

  • 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)

New Rev Formatting

Okay, I think I get what they're talking about with the new rev formatting, and I think it's something we can work with. I just compiled brand-new Dolphin, and this is what is in my title bar:

Dolphin [HEAD] 3.0-59

From my understanding, what this means is that this is the 59th build of Dolphin 3.0 in HEAD. First, I think that all of our reports should be based out of the head, or mainline trunk of Dolphin. Side-trunks can be mentioned in the Problems section or whatnot, but it opens up a whole different can of worms to track multiple trunks.

However, the 3.0-59 part I think we can work with. So, I think we can treat it as 3.0 (which is rev 7617) plus 59 is rev 7676. Now, we should definitely give the user the ability to enter "3.0-64", but as far as Template:VersionRevision, I think it could be treated for logic purposes as 7676. This would allow us to continue using the VersionCompatibility bar chart, and would let the users enter what they're seeing in the titlebar of Dolphin.

If we can agree that this is a good way to handle it, and if the devs keep to this numbering system, I'll start work in Template:VersionRevision/sandbox to get the logic setup. I tell ya, I'm having to learn more and more wiki-foo every day I work on this. =P

Your thoughts?

--Keller999 12:15, 23 August 2011 (CEST)

I haven't been able to work out means to do the sort of text parsing that would been needed for that nicely, though a setup with the base rev and increment specified as separate parameters would probably work.Kolano 15:53, 23 August 2011 (CEST)


Right now the best thing is to wait until builds are steadily being built again at this wiki home site, and after that use the new (semi-official) convention, whatever it's going to be, unless one of you guys is mamario and can tell us beforehand what's it going to be. Otomo 09:31, 27 August 2011 (CEST)