Dear colleagues, We have reached the crossroads regarding svn and git. The histories have diverged due to recent commits on both. For technical reasons, there is no straightforward method of merging them in a clean manner.
Therefore, we suggest that the svn repository be officially switched to read-only and all further work be committed to git on SF. If there are no objections we will completely disable the SF Subversion repository in a few weeks, eventually leaving only the git repositories. We understand that there are still open issues regarding the nightly builds for freebsd and the replication of the www mirrors. Future efforts should be put on resolving these issues rather than coming up with a workaround to maintain both svn and git simultaneously. *** Official repositories: Main repository on SourceForge: git://openxpki.git.sourceforge.net/gitroot/openxpki/openxpki On GitHub: git://github.com/openxpki/openxpki.git Secondary (developer) repositories exist on GitHub. *** Some notes on branch usage and development policy: In the past, there was no formal release process. Commits have been made directly to the head of SVN, partly because of the way SVN worked, perhaps partly because of the way the developers worked. Here in Frankfurt, we have a few customer modifications that we would like to push upstream to the project. Since our commits involve more than just a couple of lines of code, we would like to leverage Git to assist in the release process. Specifically, we would like to suggest the following branch layout for using the Git repository: We would like to utilize the following branch layout in the official repos: master The stable, production branch containing officially-released versions develop The unstable, development branch that may or may not work In addition, active work in the Frankfurt team(s) will be done in the following branches that may or may not be published on SF and/or GitHub. (They are more likely to show up in the individual developer repositories.) feature/<name> Development commits regarding a specific commit -- branch gets merged to develop release/<version> Last-minute fixes for a pending official release -- branch gets merged to master hotfix/<name> Bug fix needed outside of regular development workflow -- merged to master For some nice insight into the branching and naming philosophy used here please see git-flow (https://github.com/nvie/gitflow) With best regards, Scott and Martin ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
