URGENT - GOOGLE CODE Project repo : will be closed (1 Viewer)

[azzuro]

Hello, i have received an email from Google this night, about his "Google Code Repo project"

Google decide to close him,
http://google-opensource.blogspot.nl/2015/03/farewell-to-google-code.html

Dates ;

• March 12, 2015 - New project creation disabled.
• August 24, 2015 - The site goes read-only. You can still checkout/view project source, issues, and wikis.
• January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.

3 Options are available for you : ​

1. Move to a new repo :

Github :
Github include a tool for easily import folder from existing svn repo. nothing to do on your own local system.
https://import.github.com/new/

BitBucket

2. Move to MediaPortal SVN
This is not the best way, due to use Svn, and "commits" are common for all plugins ...
http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/18_Contribute/4_Development/Subversion_(SVN)
https://svn.code.sf.net/p/mp-plugins/code/trunk/
http://sourceforge.net/p/mp-plugins/code/HEAD/tree/

3. Upload Source archive
On your own plugin thread, add the source archives to your 1# post.

[USERGROUP=39][USERGROUP=39]@Developers[/USERGROUP][/USERGROUP] / [USERGROUP=63][USERGROUP=63]@Plugin and Skin Creator[/USERGROUP][/USERGROUP] / [USERGROUP=40][USERGROUP=40]@Testers[/USERGROUP][/USERGROUP] / [USERGROUP=88][USERGROUP=88]@PublicRelations[/USERGROUP][/USERGROUP]

 

[yoavain]

As a plugin developer and mainly a plugin maintainer I think the best option is a central location for all plugins.
I picked up a few abandoned plugin projects. In some of them it was very hard to locate latest code. Developer could not reached, or did not commit latest changes, etc. In most cases I had to create my own repository by taking the latest available code, just to get full access to maintain these projects.

However, I do understand these are open-source projects, that are developed by programmers on their free time. Each has his preferences of an SCM. I don't think that we should force anyone to learn and use a specific system or use a specific repository.

I do think we should encourage developers to write an informative plugin/skin first post that include:
1. A link to their repository. (no matter where it is)
2. An explanation of how to build the project, (including creating the installer). This can either be a "For build instruction, check the README.txt in the trunk", a page in the MP wiki, a link to a thread in the forum, etc.
3. Contact information. You should be able to contact the developer. I used to give a link to the issue tracker in Google code. This should be enough as long as you're actually developing on maintaining.

We should also encourage developers to commit all their changes, i.e. if someone releases a new version of a plugin, it should reflect latest code (or a tag) in their repository, otherwise, this is not an open-source project.
We should also encourage developers to be responsible and when they leave a project, try to find someone who is willing to continue the project. (This is a tough one, I know...)

 

[Edalex]

The main problem for me if GitHUb could support SVN repo as good as googlecode?
I HATE git itself.
@yoavain I never had problems with decompiling plugin dll and receiving latest sources from this operation

 

[azzuro]

edalex, why you don't like Git ?

 

[Edalex]

For producing a headache

 

[yoavain]

I've decided to move all my projects to GitHub.
In order to do this, I had to change stuff related to auto-versioning the builds.
Since I'm not a Git pro, I'm not sure if there's any convention for that. You might find the following useful.

First, I'll start with what I used until now:

In my AssemblyInfo.cs I had:

[assembly: AssemblyVersion("1.4.0.$WCREV$")]
[assembly: AssemblyFileVersion("1.4.0.$WCREV$")]

In the project file (.csproj) I had:

<PropertyGroup>
    <PreBuildEvent>subwcrev ..\..\.. ..\..\Properties\AssemblyInfo.cs ..\..\Properties\AssemblyInfo.cs</PreBuildEvent>
</PropertyGroup>
<PropertyGroup>
    <PostBuildEvent>svn revert ..\..\Properties\AssemblyInfo.cs
</PropertyGroup>

I also had a build.bat running the MSBUILD.exe command with the solution file.
For example:

"%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBUILD.exe" /target:Rebuild /property:Configuration=RELEASE /fl /flp:logfile=FanartHandler.log;verbosity=diagnostic FanartHandler.sln

The solution I found for GIT is as follows:

1. Remove the subwcrev from PreBuildEvent
2. Remove the svn revert from the PostBuildEvent
3. Edit the build.bat
   • Add the following before the MSBUILD.exe command
     

     setlocal enabledelayedexpansion
     for /f "tokens=*" %%a in ('git rev-list HEAD --count') do set REVISION=%%a 
     set REVISION=%REVISION: =%
     "scripts\Tools\sed.exe" -i "s/\$WCREV\$/%REVISION%/g" FanartHandler\Properties\AssemblyInfo.cs
     for /f "tokens=*" %%a in ('git rev-list HEAD --count') do set REVISION=%%a 
     set REVISION=%REVISION: =%
     "scripts\Tools\sed.exe" -i "s/\$WCREV\$/%REVISION%/g" FanartHandler\Properties\AssemblyInfo.cs

1. • Add the following after the MSBUILD.exe command
     

     git checkout FanartHandler\Properties\AssemblyInfo.cs

 

[Edalex]

@yoavain FYI you can interact with gihub repo as it was svn. So you will get revision numbers not commit's sha hash

 

[yoavain]

Didn't know that @Edalex. I just used the migration tool Google offered, and the project became a GIT project.

EDIT: I now see what you mean...
Anyway, the scripts will only work only in one case. If I keep the changes, it will only work for GIT. If I revert - it will only work for SVN...

 

[Edalex]

I successfully did checkout and commit with tortoisesvn. I suggest you to test it too.

 

[yoavain]

I could do this:
Remove the stuff from the csproj file and create one script for GIT and one script for SVN...
I'll think about it.........