webERP Forum

Full Version: Sourceforge subversion problem
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11
I have two patches to add to Tim's patch list. (in post #28)

These are two files that I could not commit to SVN.

PO_SelectPurchOrder.php (from 7944 => 7979)
TestPlanResults.php (from 7927 => (7944 + 7979))
(02-28-2018, 01:09 AM)falkoner Wrote: [ -> ]Hi Andy, there are many different Git work flows I mentioned the PHP one just as an example.

Anybody who has ever done a branch/merge in subversion will be absolutely amazed at how well Git does it. It turns a nightmare into a pleasure Smile Really there needs to be a discussion on what is wanted from the move to Git.


Hi Tim,

This article poses some questions regarding workflows, which may shape the discussion which you suggest:

I quite like the look of this workflow model:

Thanks Paul I will apply these shortly
Based on Tim's #27 post, it seems that this would (potentially) be the simplified process?
(please clarify/correct if I'm wrong somewhere)

The 'master' could be Phil's webERP-team repository (no shared password to anyone)
This master would be used for 'releases'.

Then me, Andy, Exson (and others) would all 'fork' the webERP-team (and then clone) to each one's own Git account.
At this point, everyone's fork is an independent copy, any changes would not interfere with the master. Code between the 'forks' could be shared, of course.

When there is something to commit back to the webERP-team master (for future releases), would then require a pull request to submit updates.


I also found this info with a minor graphical image that might help visualize as well?
Hi Paul,

Thanks for sharing that link.

How I understand it is:

Within the repository (webERP-team), you can have many different 'branches' if you wish.
The primary/default branch is know as 'master'.

I have read in a few places that it is best practice to keep your current stable version in the 'master' branch.

This is from the GitHub help docs:

Quote:There's only one rule: anything in the master branch is always deployable.
Because of this, it's extremely important that your new branch is created off of master when working on a feature or a fix.

Some of the basic workflow models I have researched use only the 'master' branch (for current release) and a 'develop' branch as a central place for developers to commit their bug fixes & new features to (via pull requests from their own forks).

When releasing a new version, one merges the 'develop' branch into the 'master', creating the 'snapshot'. Then development for the next version then continues in the 'develop' branch.

Regarding forks, yes we will all need to maintain our own forks, and clone locally. I believe it is possible to sync a fork with its 'upstream origin'.

I found this quite helpful:

I had envisaged the scenario as per Paul's posting #34 - where the admins can pull changes in to webERP-team/webERP/master and development is actually carried out on our individual branches off webERP-team/webERP/master - this sounds like by 2 cells could cope with that.
It is quite important to ensure we have the most efficient work flow as it would be miserable for all to add complexity/time to what has been a very simple process to date.
I have reading to do ... but little time
Paul, I have applied the TestPlanResults.php patch, but the other one doesn't seem to apply properly. Did you produce the patch file against the latest in the Git repository?

Phil, contributing should be easier with Git as nobody needs to worry about their access being removed due to personal vendettas, and code is more likely to get accepted on the merits of the code than anything else. However it does also give the potential to enhance other aspects of the project. For instance keeping a stable branch (which would make users lives so much better, and also reduce the number of bug reports to these forums) will be so much easier. Creating feature branches for experimental features and merging them back in which no sane person looked forward to on subversion, suddenly becomes very easy.

The only thing I would suggest is that if a release repository is kept, nobody commits directly to it, rather everybody does pull requests, that way it is easy for everybody to follow what is happening.

Tim, I created both patches from my local SVN copy.

The patch contents for PO_SelectPurchOrder appear to be correct, having the sorting-related changes. (<thead>, <tbody>).
(whereas the other file had both striped_row and sorting-related changes)

How would I create a patch from the Git copy, if that might be a better way?
(is there an error with the patch?)


I believe I see what might be the issue. For the PO_SelectPurchOrder file in the 7944.patch that you have, this file's changes are missing within that patch.
Even though my local copy "thinks" that the file version is at 7944, this is evidently not the case?

Let me see if getting the file from your weberp-svn to make a patch makes a difference.


If I compare my local copy against 7751 (which was the version before 7944), I can see the differences that I applied with 7944 and with 7979, but I don't know a way to get a diff of this comparison. The weberp-svn copy has neither of those (7944 or 7979) changes. The patch provided earlier assumes that the 7944 'striped_row' changes are present, based on line 32 in the patch where a 'striped_row' code entry is shown as "already present" in the patch (not in a +/- range), and this is likely the patch complaint? (I'm guessing)

Is there some other way to get this info? I can do a manual merge, if necessary, the changes are not that bad. (the diff shows 10 changes) I could also merge in two stages: what would have been in 7944, and then another for the 7979.
Hi Paul, the diff should effectively be a guide for how to move from the Git repository on my github site to your file.

Thinking about it, rather than do a patch fork my repository to your github site, and clone it to your hard disk. Apply any changes to this copy, and then push the changes back to your github repository. Then send me a pull request and I can apply it to my repository. Does this make sense?

Ok, I'll fork, clone and apply the changes.

That'll be a good exercise. Let see how it goes...
Pages: 1 2 3 4 5 6 7 8 9 10 11