Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sourceforge subversion problem
02-27-2018, 09:24 AM, (This post was last modified: 02-27-2018, 09:37 AM by TurboPT.)
#21
RE: Sourceforge subversion problem
(02-27-2018, 06:00 AM)phil Wrote: We've waited long enough ... we reckon a move to git is the way to go ... I have some learning to do.
Same here, so we both have a "learning curve"...

=====

Tim, as far as the history between webERP-svn to a new file in the webERP repo, is there a way to compare files between the two, or is it a matter of getting the same file from both and then comparing some other way?

Reply
02-27-2018, 10:43 AM,
#22
RE: Sourceforge subversion problem
Sounds good Tim... will wait for your advice on how to proceed - looks like the webERP user is already taken ...
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
02-27-2018, 11:20 AM, (This post was last modified: 02-27-2018, 11:20 AM by TurboPT.)
#23
RE: Sourceforge subversion problem
(02-27-2018, 08:19 AM)falkoner Wrote: I have most of the history of the project reconstructed in a git repository here: https://github.com/timschofield/webERP-svn

Tim, would it help if I can possibly generate any patches to some of those files?
Reply
02-27-2018, 11:33 AM, (This post was last modified: 02-27-2018, 11:36 AM by TurboPT.)
#24
RE: Sourceforge subversion problem
(02-27-2018, 10:43 AM)phil Wrote: ... looks like the webERP user is already taken ...

Could you potentially use user 'daintree' instead? ... that is the project lead name at SF.
Reply
02-27-2018, 01:01 PM,
#25
RE: Sourceforge subversion problem
What about?
  • web_erp
  • web-erp
  • myweberp
  • my-weberp
  • team-weberp
  • weberp-zone
  • weberp-git
https://www.linkedin.com/in/andrewcouling
Reply
02-27-2018, 01:23 PM,
#26
RE: Sourceforge subversion problem
I thought:

webERP-team

I've created the user so we can upload the repository once Tim gives us the nod. I will distribute the password to the admins.
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
02-27-2018, 07:25 PM,
#27
RE: Sourceforge subversion problem
Git doesn't have a central shared repository as subversion does, each developer maintains their own fork of the code, and then code is shared between the forks. You most definitely should not be sharing a user name/password combination.

It is probably best to have a repository that is used for releases, but nobody commits directly to that repository, each developer instead issues what github calls pull requests to that repository, and then a select group can review and accept/reject those pull requests.

There are multiple possible work flows that you can have, one such is the work flow used by the PHP project that migrated from subversion to git a while back. You can find details online, but basically they use https://github.com/php/php-src as their release repository, at the time of writing there are 4661 forks, each of which will issue pull requests to this repository, but they can of course pull code between them.

I was sceptical of Git at first but the more I used it the more I realised it's power which is why most projects have migrated to it.

Paul: Most of the patches apply without a problem, but I am going through each one individually to make sure there are no problems as we don't want to mess this up. Commit 7944 (https://sourceforge.net/p/web-erp/code/7944) is the hardest so far as you can see it is very large, and there are several corrupt files in it. On some of the commits with corrupt files I have manually created the diff, but on others such as 7944 it is just too hard, so it is probably best to complete this exercise, then run a diff between this repository and your expected one, analyse the differences, and then do any remaining commits.
Reply
02-27-2018, 10:15 PM,
#28
RE: Sourceforge subversion problem
Ok, I have finished this, and the completed repository is at https://github.com/timschofield/webERP-svn

I need people to check that this code is as expected, should be fairly easy to run a diff between the 2. I know that some small changes that were in the corrupt commits are not in there, but they should be minimal and easily corrected.

I am attaching an archive of all the patches I have applied after commit 7925 so that there is a historical record so that when Phil accuses me of trying to sabotage his project there is evidence of what I have done.


.gz   patches.tar.gz (Size: 85.83 KB / Downloads: 1)

We need as many eyes on this as we can so that we are happy we have a correct starting point.

Thanks
Tim
Reply
02-28-2018, 12:35 AM,
#29
RE: Sourceforge subversion problem
(02-27-2018, 07:25 PM)falkoner Wrote: There are multiple possible work flows that you can have, one such is the work flow used by the PHP project that migrated from subversion to git a while back. You can find details online, but basically they use https://github.com/php/php-src as their release repository, at the time of writing there are 4661 forks, each of which will issue pull requests to this repository, but they can of course pull code between them

Hi Tim,

I just checked out the PHP GitHub account.
It appears they have a branch for each version being developed, and merge the 'version' branches back into the master branch just before/after publishing releases.
I guess this results in the master branch always containing the current release.
Would you endorse this approach?

For the other Git novices like me, here's a useful article about Git branches and forks:
https://blog.scottlowe.org/2015/01/27/us...-workflow/

Andy.
https://www.linkedin.com/in/andrewcouling
Reply
02-28-2018, 01:09 AM,
#30
RE: Sourceforge subversion problem
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.

Tim.

Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)