Sourceforge subversion problem

[TurboPT]

Pull request created, but I do not have write access to merge it, though.

[afcouling]

Thanks Paul.
I've also made a Pull Request.

Phil may wish to review all PRs himself, or perhaps delegate, by promoting some contributors to organisation members, with particular permissions:

https://help.github.com/articles/access-...on-github/
https://help.github.com/articles/permiss...anization/
https://help.github.com/articles/reposit...anization/

Andy.

[TurboPT]

From this point, going forward, there is no longer any need to submit pull requests to webERP-svn, as all pulls should now be applied to webERP-team/webERP.

Is this correct?

[TimSchofield]

Well webERP svn is my personal repository. It makes no odds where the pull request is sent in the end all developers will want to pull all (most??) Commits anyway. For instance earlier I pulled Andys work on petty cash directly from his repository to mine.

[TurboPT]

I had not yet received Phil's repository invite, which is why I could not merge earlier.

Now having accepted the invite, I have merged my and Andy's pull requests to webERP-team/webERP.

[afcouling]

From this point, going forward, there is no longer any need to submit pull requests to webERP-svn, as all pulls should now be applied to webERP-team/webERP.

Is this correct?

I would agree with this notion, but understand what Tim is saying.

They may be an instance in which someone may want to contribute to Tims webERP-svn repo with a pull request, in the future.

However if someone wishes to contribute to the official webERP project, they should send a pull request to webERP-team/webERP.

Andy.

[TimSchofield]

Well with Git there is no central repository with official gatekeepers deciding who can and cannot commit. For instance Andy if you had been doing your petty cash work now you could create a branch in your local repository to do it. If you wanted to work with another developer on that feature you simply share that branch with that developer and you push and pull code between you. When the feature is complete you merge it back to your main branch, delete your feature branch and share the code publicly.

[afcouling]

Well with Git there is no central repository with official gatekeepers deciding who can and cannot commit. For instance Andy if you had been doing your petty cash work now you could create a branch in your local repository to do it. If you wanted to work with another developer on that feature you simply share that branch with that developer and you push and pull code between you. When the feature is complete you merge it back to your main branch, delete your feature branch and share the code publicly.

This is truly mind expanding!
Thank you Tim.

[TimSchofield]

One of the many neat things about Git are hooks. If you look inside your .git folder you will find one called hooks. These are scripts that are run before or after different Git commands. For instance I have scripts that run before a commit that format the code according to code layout guidelines and that check for syntax errors and other things, aborting the commit if there is a problem.

I am happy to share some or all of this if people contact me by email

---

This is truly mind expanding!
Thank you Tim.

I think people need to approach Git with an open mind, and just see how powerful it is. It is not a replacement for SVN, it is a completely different tool, with very different functionality. If you find yourself thinking "it would be really good if..." then you generally end up finding it is perfectly possible.

Tim

[afcouling]

Thanks Tim.
I'll try to master the basics first of all.

I've realised that the $Id: comments at the top of all/most webERP scripts, driven by keyword substitution, will not work on GitHub. I little reading revealed that Git and GitHub do not offer an equivalent function.

Andy.