Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sourceforge subversion problem
03-02-2018, 08:59 AM,
#61
RE: Sourceforge subversion problem
My understanding is we would each work on our own forks committing changes in our personal repositories until we have working code and then do pull requests to the webERP-team webERP repository for the working code/bug fixes so the webERP/master would only ever have solid code in it.
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
03-02-2018, 09:11 AM, (This post was last modified: 03-02-2018, 09:24 AM by afcouling.)
#62
RE: Sourceforge subversion problem
(03-02-2018, 08:56 AM)TurboPT Wrote: Ok, another pull submitted.

From here, Phil would fork your webERP-svn to webERP-team, and then others such as me, Andy, Exson, etc would then all fork webERP-team and clone to each one's own repository ... is this the general idea?

Then webERP-svn will exist as the "historical SVN reference", as new development commits would be applied to webERP-team?

Hi Paul,

This is as I understand it.

Andy.
(03-02-2018, 08:59 AM)phil Wrote: My understanding is we would each work on our own forks committing changes in our personal repositories until we have working code and then do pull requests to the webERP-team webERP repository for the working code/bug fixes so the webERP/master would only ever have solid code in it.

Hi Phil,

We seem to be aligned on the process.

I believe we can use the 'Release' functionality on GitHub to create release 'snapshots' from the webERP-team/master branch.
https://help.github.com/articles/about-releases/

Until now, when you have created releases, have you simply taken the code from the svn 'trunk' and zipped it up? Or are modifications (or other processes) required to make the code in 'trunk' release-able?

Andy.





https://www.linkedin.com/in/andrewcouling
Reply
03-02-2018, 10:08 AM, (This post was last modified: 03-02-2018, 10:42 AM by TurboPT.)
#63
RE: Sourceforge subversion problem
(03-02-2018, 08:59 AM)phil Wrote: My understanding is we would each work on our own forks committing changes in our personal repositories until we have working code and then do pull requests to the webERP-team webERP repository for the working code/bug fixes so the webERP/master would only ever have solid code in it.
That is correct, Phil. That is what I meant, though it might not have been read that way? I believe we're saying the same thing...

So, what I envision is this: (just more clarification, hopefully -- and that I don't have any of the concepts "backwards"...)
  1. After Tim gets the next pull of mine, that can be the "historical SVN copy" that matches the SVN 7979 version from SF. (I have a fork/clone of this repository as well)
  2. Then the webERP-svn is forked and cloned to the webERP-team. (To match the latest trunk SVN?)
  3. Then me, Andy, Exson, (you, and others), from our own repository locations, would each fork and clone the webERP-team
  4. We all work within our own forked areas, created at step 3. When there are changes to apply to the (HEAD/master/tip/trunk), we would each have to submit pull requests to the webERP-team from our own forks.
As far as a 'stable' branch, this could be a branch on webERP-team? (I'm not sure if there would need to be another fork, per say?)

Tim briefly mentions the 'stable' handling (items 4-6) in this post.
Note, though, that at the time that post was written, there is mention of SVN there (items 1-3), which we won't have to worry about anymore.
Reply
03-02-2018, 10:23 AM,
#64
RE: Sourceforge subversion problem
(03-02-2018, 10:08 AM)TurboPT Wrote: As far as a 'stable' branch, this could be a branch on webERP-team? (I'm not sure if there would need to be another fork, per say?)

I have seen a few projects on GitHub who keep their stable code (current release) in the master branch, and accept pull requests from developers into a branch called develop (not another fork).

Other projects have branches for every single release.

Perhaps we should start simple, with just the master branch, and see how it goes. We can always branch off for development or releases at a later date.

Andy.
https://www.linkedin.com/in/andrewcouling
Reply
03-02-2018, 10:38 AM, (This post was last modified: 03-02-2018, 04:12 PM by TurboPT.)
#65
RE: Sourceforge subversion problem
Yes, Andy I agree that we should start with a master at least.
(I know that another release is desired soon, so we need to at least get past that hurdle)

Once we get that "rolling", I believe the other aspects will become more clear as usage is gained.

I don't believe it would be too hard to do a 'stable' branch of some sort thereafter.
Reply
03-02-2018, 05:59 PM,
#66
RE: Sourceforge subversion problem
OK - I forked Tim's weberp-svn repository into webERP-team/webERP repository
I've also forked this into phildaintree/webERP repository and cloned that to my local development machine.
So I will be developing in this fork and push back to webERP-team/webERP as and when there is anything of use to push back.

It seems a bit more convoluted at the moment - hope it gets easier!!
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
03-02-2018, 08:18 PM,
#67
RE: Sourceforge subversion problem
I think it needs a change of mindset to understand how a distributed version control system works rather than how a centralised system like svn works. Anybody who fancies can fork any repository that they want, and can create any branches on that fork that they like. On my local repository I always have several branches on the go at any one time. I have branches for new features I am working on, and branches for bug fixes I am working on. When one of these is completed I merge it back into the main branch, and push it to github, and then other pull that code from github if they want my feature/bug fix.

If someone, or even several people want to maintain a stable branch they can, basically the idea is that the best code always wins, ie the most stable "stable branch" will become the most popular.
Reply
03-02-2018, 10:14 PM,
#68
RE: Sourceforge subversion problem
webERP-team/webERP currently displayes the message '28 commits behind timschofield:master'.
Was timschofield/webERP-svn forked into webERP-team/webERP too early?
Can the 28 commits be pulled into webERP-team/webERP?

Andy.

https://www.linkedin.com/in/andrewcouling
Reply
03-02-2018, 10:21 PM,
#69
RE: Sourceforge subversion problem
They are the 28 commits Paul sent to me in a pull request. They can be pulled into that repository either from Paul's or my repository.

Tim
Reply
03-03-2018, 01:11 AM,
#70
RE: Sourceforge subversion problem
Paul,

Could you send a pull request to webERP-team/webERP for the '28 commits' ?

Andy.
https://www.linkedin.com/in/andrewcouling
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)