Dolphin, the GameCube and Wii emulator - Forums

Full Version: Revision page changed - FAQ
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
Quote:You need to understand that the whole GoogleCode page is meant to be a developers' place, so there is really no reason for us to care about complains like "omg I want my rev numbers back!!1".

I respectfully disagree. This change has major implications for the user community, especially the wiki. As the bleeding-edge svn version has been at the very top of the download for some time, I would guess that many users, even newbies, are using the latest code rev on their machines.

Further, Release 3.0 (while a generally excellent rev) is not the best or fastest for every game out there. Until there comes a time when we can say 'Release 5.0 is the absolute best and most compatible at everything', there will be the need to direct users to non-release versions of code. Right now, we do that on the wiki by telling users which range of code versions to use, like this:

[Image: versioncompat.png]

The new git rev numbers are not sequential, so there is no way to know if one release comes before another.

I think an easy solution would be to keep a running rev number that increments with each new git commit. I am not enough of a git expert to know whether this would have to be done manually or could be automated, but keeping the same rev sequencing that the users are used to, and the wiki is already coded for, would really help maintain continuity as you guys shift over to git. Otherwise, I have no idea how we're going to adapt the wiki for revs that are not sequential and are very hard to copy for a compatibility rating.

Please consider doing this (or something similar that will allow rev numbers to continue) so that those of us working on the wiki, and those of us doing your regression testing (as you acknowledged), will be able to continue to do so.

Respectfully,

Keller
Regular users (and the wiki) should only care about the master branch.
We're working on making the git tree a bit better, so that it is very easy to see what commit you are on relative to the last release.
For example, the output of `git describe` could be:
3.0-45-g4887bce
which means release 3.0 plus 45 commits, with the most recent commit being identified by g4887bce.

So, you just end up with counters from the last release, instead of counters from zero.
I recommend using mysysgit or gitextensions(especially the 2nd as it comes with nice gui) over tortoiseGIT if it's as bad(or worse) as their SVN app.
Btw, I think you should get rid of some older branches and merge "develop" with master since it contains an important fix.
(08-21-2011, 10:18 AM)shuffle2 Wrote: [ -> ]Regular users (and the wiki) should only care about the master branch.
We're working on making the git tree a bit better, so that it is very easy to see what commit you are on relative to the last release.
For example, the output of `git describe` could be:
3.0-45-g4887bce
which means release 3.0 plus 45 commits, with the most recent commit being identified by g4887bce.

So, you just end up with counters from the last release, instead of counters from zero.

While this is great, it is totally incompatible with the old system. Right now, we have a whole wiki full of Testing and Compatibility reports based off the old 0 to 76xx system. How can we transition over to using this new one? Will users report their rev as 3.0-45? How does that compare to rev 7234?
We're actually restructuring the entire git repository at the moment. When it is done, everyone will have to re-clone the repository.
This will:
Make "git tags" actually useful, along with `git describe`.
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.
Fix a few people's names/emails in the commit log.
Split off texcache-rewrite and GLSL stuff into branches, effectively reverting texcache-rewrite on the master branch.
Change how the cheats/shaders/translations were merged, so that the logs are not annoying.

So there are a lot of advantages, unfortunately it requires that everyone re-clones the repository.

Will let everyone know when it's time to do that.
(08-21-2011, 10:26 AM)keller999 Wrote: [ -> ]
(08-21-2011, 10:18 AM)shuffle2 Wrote: [ -> ]Regular users (and the wiki) should only care about the master branch.
We're working on making the git tree a bit better, so that it is very easy to see what commit you are on relative to the last release.
For example, the output of `git describe` could be:
3.0-45-g4887bce
which means release 3.0 plus 45 commits, with the most recent commit being identified by g4887bce.

So, you just end up with counters from the last release, instead of counters from zero.

While this is great, it is totally incompatible with the old system. Right now, we have a whole wiki full of Testing and Compatibility reports based off the old 0 to 76xx system. How can we transition over to using this new one? Will users report their rev as 3.0-45? How does that compare to rev 7234?

(08-21-2011, 10:28 AM)shuffle2 Wrote: [ -> ]This will:
Make "git tags" actually useful, along with `git describe`.
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.
Fix a few people's names/emails in the commit log.
Split off texcache-rewrite and GLSL stuff into branches, effectively reverting texcache-rewrite on the master branch.
Change how the cheats/shaders/translations were merged, so that the logs are not annoying.

Perfect, thank you! Will this also be the rev number that is shown in the title bar and about page, since that's where most users will get their number from?

Thanks for getting back to me.

-Keller
the svn rev number will only exist in the git commit logs, like this:

Code:
commit da197c2e4b2677a7cb438e97ffe91af059bb6110
Author: NeoBrainX <NeoBrainX@googlemail.com>
Date:   Sat Aug 6 14:31:40 2011 +0000

    Some cleanups to the internal Wiimote configuration handling. No functional change.
    Patch by lpfaint99.

    git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7691 8ced0084-cf51-0410-be5f-012b33b47a6e
in other words, da197c2e4b2677a7cb438e97ffe91af059bb6110 would equal svn r7691.

You can see this makes it easy to lookup the revison:
(08-21-2011, 10:59 AM)shuffle2 Wrote: [ -> ]the svn rev number will only exist in the git commit logs, like this:

Code:
commit da197c2e4b2677a7cb438e97ffe91af059bb6110
Author: NeoBrainX <NeoBrainX@googlemail.com>
Date:   Sat Aug 6 14:31:40 2011 +0000

    Some cleanups to the internal Wiimote configuration handling. No functional change.
    Patch by lpfaint99.

    git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7691 8ced0084-cf51-0410-be5f-012b33b47a6e
in other words, da197c2e4b2677a7cb438e97ffe91af059bb6110 would equal svn r7691.

You can see this makes it easy to lookup the revison:

Any chance you can make this be the revision that shows up in the statusbar for Dolphin? Right now, it's the extra-long hex number, which is not only difficult to type into a testing report, but is also impossible to copy and paste. And while it may be easy to lookup the revision using a tool, I don't see how the wiki will be able to look it up for templates.

Your thoughts?

-Keller
What about switching to Mercurial instead of Git? That would keep most advantages from Git (decentralized, easy branching) while keeping good Windows support (through TortoiseHG which is more mature than TortoiseGit) as well as numeric revision numbers. It's also supported by Google Code.
Pages: 1 2 3 4 5 6 7 8