New source location

• May 28, 2012 - 16:28

If anyone else that compiles their own MS nightly version was wondering what happened to all the updates since R5663, the source has moved. See the following link from Lasconic for the lowdown:

http://musescore-developer.685061.n2.nabble.com/MuseScore-development-i…

One part of the email that I don't understand is this:

"We used to talk about a commit as a "revision", and note a revision like rXXXX. This is no more possible with Git. In the issue tracker and to communicate between us, we will use the short SHA1 signature of a commit instead."

Checking out the code using SVN only shows the revision, and presently it is at revision 11. Viewing the source on Github only shows the SHA1 code, no revision value. This is a big disconnect between the two main ways of dealing with the source code so how is this going to be resolved?

Is the nightly download provided by David going to have some SHA1 code attached to the end of the filename so it is known?

What about us self-compilers?

Where are typical users and/or testers going to get this SHA1 code from to put in their postings to identify the version they are using?

Comments

• May 29, 2012 - 00:33

Hi, thanks for reposting my post here ! We still have to deal with the "closing" of the SVN repository.

There are no revision number in Git (as far as I know) like there is on SVN. Each commit is indentified by its SHA1 hash. It's often shorten to 10 digits. As a nightly user, you will find this short hash in the name of the installer and in the About Box, just like the rXXXX we used to have. As a self compiler, you can get the hash of the version you are compiling by running make version; make revision. (or on Windows, make -f Makefile.mingw version). The nightlies on Mac are also tagged with the date and time of build.

Reply

• May 29, 2012 - 03:45

Regarding the revisioning, right now I use Tortoise SVN and execute "subwcrev.exe %SOURCEPATH%" which returns 11, so there appears to be some form of revisioning support somewhere in GIT. However, all my reading says otherwise and you can only use the hash value unless you intentionally tag your checkins with some form of versioning.

I'm not a professional programmer and do not use version control for my projects. Since the hash value is not a simple linearly increasing value like SVN was, this change is going to make things much more complex for the average tester here. Instead of being able to say "I use revision X" and we are now at revision X+5 and to go to that version, we are now faced with a 4-byte hex value of seemingly random properties. I can't see how this is an improvement for the user/tester base.

Reply

• May 30, 2012 - 15:32

Adjusting to the new source (GIT) and revision value will take time, but I like how everything is now integrated into MS. Under the HELP menu is a "Report a bug" option which launches a "create new issue" on the MS website, and includes the SHA-1 revision of MS that you are using in the posting. Clever!

I am absolutely impressed with the compactness of the cleaned-up source code and the speed of the compile. A full checkout to a new compilation folder took under a minute and a full compile was only 11 minutes, compared to about 45 before. (How did you do that?)

One thing that needs updating on the Windows compile page is the necessity of a GIT client to checkout the source code. TortoiseSVN still sort-of works but doesn't support the SHA revision. I am presently using msysgit 1.7.10. I also installed the TortoiseGIT gui but I think its not needed.

Any other nightly tester and self-compiler up and running on the new git source yet? How has your adjustment been to the changes?

Reply

• May 30, 2012 - 16:32

The compilation is quicker because we dropped the support of plugins for the moment. More precisely, plugins that need access to Qt to popup a window, or access the network will not work. We are evaluating other ways to make this feature and make the plugin framework better without having to compile the Qt bindings, which was huge and hard to maintain for the future versions of Qt.

Reply

• May 30, 2012 - 16:41

Glad you like "report a bug". We will probably work on it a bit more to include automatically your OS and version. Moreover there is also a new button in the about box to copy paste the revision number (more precisely a code that will be changed to a link if you post it on musescore.org)

I can understand that a increasing revision number is nicer for testers and users. The SHA is useful for developers. I will try to investigate a way to include both in the about box. Something like rXXXX.SHA.

Reply

• May 31, 2012 - 12:15

If we can't have revision numbers, I think I'd be happy with a date if the builds are nightly, literally. If it's for every commit, then we can put a time - if possible.

Reply

Do you still have an unanswered question? Please log in first to post your question.