Sourceforge subversion problem

[afcouling]

Perhaps I'm incorrect...

Rather than forking https://github.com/timschofield/webERP-svn, would it be better to duplicate?

https://help.github.com/articles/duplica...epository/

Andy.

[TimSchofield]

I want to ensure that all the changes over the past ~3 months are present. I was surprised to find that the EDIMessageFormat file had issues.

Yes it went wrong on commit 7944 https://sourceforge.net/p/web-erp/code/7944/#diff-20

Did you say that the TestPlanResults patch was ok? I don't see the expected changes from the patch unless the file needs a commit?
(If necessary, I can commit the changes as I've been doing with the other files)

In patch 7927 you should see the TestPlanResults.php recreated for the $db removal. This was the commit where it went wrong. However the patches I did were only intended to re-create the subversion commits, so later things such as the striped rows that would have included TestPlanResults.php don't as they were never part of subversion. Clear as mud?

---

I'm still getting used to Git terminology...

Rather than clone, wouldn't it be a fork of https://github.com/timschofield/webERP-svn into https://github.com/webERP-team/webERP ??

Tim, does a fork retain the version history of its parent?

Andy.

Andy, rather misleadingly github (which is not Git, just a project hosting site that uses Git) uses different terminology to Git in places. Clicking the fork button creates a complete copy including all history into your own github repository. This is an exact duplicate of the repository I created. You then clone that repository to your local machine, and this local copy will also include all history. So then you commit changes to your local repository, and then push those changes to github. Then using github you share that code using pull requests.

Tim

---

Perhaps I'm incorrect...

Rather than forking https://github.com/timschofield/webERP-svn, would it be better to duplicate?

https://help.github.com/articles/duplica...epository/

Andy.

No, forking (in github terminology) is the correct way to do it.

[TurboPT]

Tim, ok on the TestPlanResults. That would be correct that I was not able to commit the row/sort changes.

I've merged the pull request.

I'm finding some other small "surprises", hopefully I can get these completed today.

[TimSchofield]

Can you send me pull requests for stuff that you do?

[TurboPT]

Yes I will, I have already planned to do that.

Since there is STILL trouble at SF, I downloaded your SVN copy to compare against my copy of all the changes since December.

I was a little nervous, at first, as the diff reports that there are 600+ differences!
However, the vast majority of these (so far) are due to:

1. The SVN $Id$ line at the top of most files.
   
2. Differences with spaces and/or tabs. (I'm ignoring these)
   

[TimSchofield]

Git is also sensitive to line endings. I ran dos2unix to change any CRLF line endings to LF. Most code editors have the facility to define what line endings to use so it would be good if people could set their editors to use Unix line endings. However your different may highlight this change.

Rather than get nervous just ask

[TurboPT]

I've only crossed two or three files with line-end differences, so far.

Those usually appear with the message: "...files have equal text, but are not binary equal" from the diff tool.

I was only nervous as to what might have actually NOT been covered by all the SVN commits.

[TurboPT]

Tim, is there a way to "get the clean copy" (remove any previous commits) of a file in GitHub?

I may have messed up commits on one file. I tried some reverts, but I'm not sure the how the one file might be after update.
If necessary, I can re-commit to the one file after the next pull.

I tried Googling a way to remove commits to a fresh copy, but no definitive way that I've been able to find.

After getting past these last changes, that should be all to finally match the SVN at version 7979.

[TimSchofield]

To remove the last commit from your local repository simply run the
git reset --hard HEAD^
command. Be warned this removes any local changes you haven't committed as well. If you have already pushed to github, then I don't think there is a good way of removing it, simply do another commit reversing it and push that as well.

Tim

[TurboPT]

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?