Re: [Zope-dev] A Tale of Two Repositories
Hi Tres, Tres Seaver wrote:
The CMF projects are in this state because one of the main developers is unwilling to participate in the project if it moves entirely to Github[2], but is willing to continue if a proposal is in place to maintain a second public repository, against which his contributions would be made[3]. This proposal aims to satisfy that request by hosting the second, synchronized repository for each project using the new Launchpad Git hosting option[4].
thanks for working on this issue. I'm not very happy about the proposed solution because it makes the GitHub repository the primary repository and the canonical location for bug reports. But compromises never make everybody happy. I'm happy about your proposal because it looks like a practicable solution everybody can live with.
1) Create a Git repository from its Subversion history, and push that repository to Github; this step will use the same scripts used for other ZF repositories. E.g., the branches, tags, and trunk for ``Products.CMFCore`` will be hosted on Github at https://github.com/zopefoundation/Products.CMFCore
There is one problem with the existing procedure: author information is lost for contributers without GitHub account. I don't know if this is a bug in the scripts or if the GitHub universe is a closed universe that has no provisions for handling information about people existing outside. Would be nice if this could be resolved. I consider it an unfriendly act to remove my name from all my contributions just because I'm no customer of GitHub Inc. And it makes history information less useful. Please note https://github.com/zopefoundation/Products.GenericSetup already exists, but is not in sync with the version in the Subversion repository. And please don't forget the dev buildouts in http://svn.zope.org/CMF/. Cheers, Yuppie
yuppie schreef op 15-05-15 om 12:11:
There is one problem with the existing procedure: author information is lost for contributers without GitHub account. I don't know if this is a bug in the scripts or if the GitHub universe is a closed universe that has no provisions for handling information about people existing outside.
Would be nice if this could be resolved. I consider it an unfriendly act to remove my name from all my contributions just because I'm no customer of GitHub Inc. And it makes history information less useful.
AFAIK this has got nothing to do with not having a github account, although I guess that if there is a match between an original svn account and a github username, github might use it. But the procedure should be able to accept an authors.txt file or similar that contains a mapping from zope svn committer name to email address and maybe full name. I have done several moves from svn.plone.org to github and from an internal company svn to bitbucket git and have used such a file there, with names of colleagues and Plone committers. -- Maurits van Rees: http://maurits.vanrees.org/ Zest Software: http://zestsoftware.nl
On 05/15/2015 06:11 AM, yuppie wrote:
Hi Tres,
Tres Seaver wrote:
The CMF projects are in this state because one of the main developers is unwilling to participate in the project if it moves entirely to Github[2], but is willing to continue if a proposal is in place to maintain a second public repository, against which his contributions would be made[3]. This proposal aims to satisfy that request by hosting the second, synchronized repository for each project using the new Launchpad Git hosting option[4].
thanks for working on this issue. I'm not very happy about the proposed solution because it makes the GitHub repository the primary repository and the canonical location for bug reports. But compromises never make everybody happy.
We could choose to leave bug reporting associated with the Launchpad project. That would make integration with the Plone projects somewhat more difficult, but not impossible For the repository: the key element of DVCS is that the "authoritative" repository is the one on the maintainers' hard drive (from which she makes releases). As it happens, the "merge pull request" functionality on Github makes an attractive shortcut, particularly for minor typo fixes. Wiring up Travis or other CI makes it plausible to merge even more substantive changes from the UI.
I'm happy about your proposal because it looks like a practicable solution everybody can live with.
1) Create a Git repository from its Subversion history, and push that repository to Github; this step will use the same scripts used for other ZF repositories. E.g., the branches, tags, and trunk for ``Products.CMFCore`` will be hosted on Github at https://github.com/zopefoundation/Products.CMFCore
There is one problem with the existing procedure: author information is lost for contributers without GitHub account. I don't know if this is a bug in the scripts or if the GitHub universe is a closed universe that has no provisions for handling information about people existing outside.
Would be nice if this could be resolved. I consider it an unfriendly act to remove my name from all my contributions just because I'm no customer of GitHub Inc. And it makes history information less useful.
The conversion script takes a 'users.txt' file which has SVN username -> e-mail address mappings: the git commits then reflect those mappings. After conversion, the onus will be on contributors to ensure that they configure Git to know their e-mail addresses.
Please note https://github.com/zopefoundation/Products.GenericSetup already exists, but is not in sync with the version in the Subversion repository.
I would plan to wipe out that repository and recreate it from SVN.
And please don't forget the dev buildouts in http://svn.zope.org/CMF/.
Ugh. I'll have to think harder about those. Likely that becomes a separate repository, as well. Tres. -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
participants (3)
-
Maurits van Rees -
Tres Seaver -
yuppie