PMS moves to GitHub!

[SubJunk]

I've now spent about 10h to get a basic understanding of git and maven with the help of the people here; I think this is quite a lot of time that could have been used to do something else. Is everyone willing to take that time?

Yeah that's my main concern with it too. I've resolved a lot of the problems I had, but I still need to learn more, and meanwhile I could have spent - and could spend - my time working on the actual program instead of these types of things that don't matter much to me.
Plus I think it's nice how in SVN you can just refer to your revision number and it's all sequential, it's a user-friendly system, whereas with Git you have to refer to these alphanumeric combinations that don't mean anything at a glance. Sure Git is "better" for people who care about that kind of thing but what about people who just care about making a good program? There will always be the "better" and newer thing to use but what matters is your code, not the programs you use around your code, in my opinion.
Another plus in the SVN column is its integration with Google Code. I think it's really user-friendly and developer-friendly to have it all on Google Code like it currently is and to split it by still using Google Code for issue tracking but using GitHub for the code doesn't seem like a good idea to me.

[SharkHunter]

ure Git is "better" for people who care about that kind of thing but what about people who just care about making a good program? There will always be the "better" and newer thing to use but what matters is your code, not the programs you use around your code, in my opinion.

We are only in it for the code!

[taconaut]

Tree management will be no different form svn everybody who works with this needs from time to time synch our own repos with the "central" repo to kep up. svn and git are equally good/bad at doing this just a matter of taste.

I hope you're wrong about that. I see the benefit in the move to GitHub in an easier way to maintain different builds (forks) having a large common code-base, but having been customized.

I've just updated the base code in pms-mlx (https://github.com/taconaut/pms-mlx/com ... 41b6edd960) running these commands from github help (http://help.github.com/fork-a-repo/):

Code: Select all

git remote add upstream git://github.com/ps3mediaserver/ps3mediaserver.git
git fetch upstream
git merge upstream/master

After having resolved two conflicting files (Build.java which was justified and RendererConfigurationTest.java which wasn't) I was able to push the changes and everything seems fine.

[SharkHunter]

Sure if you only have a small number of commits that are not related to the code you modified then life is simple (but that it is in svn as well). But if you have what occurred in PMS the end of the summer or so where you have 100 commit to fetch from the remote repo then you're bound to have loads of conflicts. Git doesn't help you to stay on track with the repo you still have to resolve all the conflicts just like svn. It is not harder compared to the task you did in svn. I use Tortise (spelling??) and just right click and say merge (from rev xxxx) and then resolve conflicts. If you fork the code work for awhile and then refecth and you'll have conflicts which has to be addressed. svn and git will give you the same amount here the only thing that will make a difference is how often you as a programmer resync with the repo.

I agree it's easier to fork on Git than on SVN but it is not a reason for a move. How many forks of PMS does exists to make this a real problem? Are there going to be zillions of new forks? Compared to how many "forks" we today have in svn that has to move?

Like I said I use git (and svn and clearcase and cvs etc.) and they are basically all the same. The big issues are outside of the program and more about how people uses them.

Then again maybe I have an excuse to learn maven. Even tough make systems are like medicine , something you have to take but it's taste like shit each time....

[taconaut]

That's how our two builds differ. I try to modify only the minimal amount of code in the pms base code for pms-mlx to work; trying to avoid precisely these merge nightmares. The changes I do are in my code (net.pms.medialibrary package). To maintain my build I now see a clear advantage with git.
With SVN I used to export the source when a new release came out, dropped it into my code and adapted the things that had to be. Now I can do a merge and everything is set.
This is the first time I see a clear benefit using git! Raptor had to give quite some arguments to get me going.
Just tried to merge the changes posted previously into another branch having a differetn folder structure and it worked (https://github.com/taconaut/pms-mlx/tre ... _structure)

[SharkHunter]

I also try to modify a minimum, but that minimum will have conflicts. Since I handle them today I can handle them in git since they'll be the same. I have more issues with the problem of trying out new binaries for the tools (mencoder etc.) since they will now be handled via maven and fetch and magically installed somehow. Plus the fact that I can't install all my extra stuff (rtmpdump,perl python etc) along with the rest of the stuff since binaries don't fit on github....

[taconaut]

I'm no expert but think it should be easily feasible as well. Maven copies the files located in src\main\external-resources while packaging. AFAICT you can replace the things you need in there before releasing and do a 'package' instead of a 'clean package'. Raptor probably knows more about this.

[Raptor399]

I think the discussion makes the move seem like a bigger thing than it really is.
We think there's a lot more to gain by sharing the code this way, which justifies the pain of moving.
Others may think we're wrong. The future will tell who was right.

For now: know that you're not on your own.
If we can help in any way, let us know.

[SharkHunter]

I have no problem with github (I said didn't I?) except that all the extra stuff that SHB includes can't be stored there. So if I should continue I must at least make learn maven good enough to be able to build in perl,python,rtmpdump,curl etc. from some other place. Since I most likely would like to know which version of said program went in to which SHB bundle I would like to keep the binaries under revision control. This can't be done on GitHub if you don't pay. This means that I have to keep the PMS code in github and then the programs at google code which means I'll need to update at least two repos.
I'm not saying this is not something I can't manage I'm just saying it will take me some time to get this to work (once I done it once there is no extra work to be done).

The bottom line is this will take some effort to do, and since I find these kind of issues boring, I don't have the energy/interest/time to do it right now. If this was 'fun' I would do it straight away now it will take some time.

[Raptor399]

This means that I have to keep the PMS code in github and then the programs at google code which means I'll need to update at least two repos.

As taconaut explained: look at the pom.xml and you'll see that is exactly what we do right now: the binaries reside at Google Code and the source at GitHub.
Won't be hard to adjust for your situation, methinks.