Difference between revisions of "GitSuperRepo"

From Einstein Toolkit Documentation
Jump to: navigation, search
(Documents)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
(draft)
+
[[Category:GitSuperRepo]]
  
=Git Super-Repository=
+
The current method for checking out and updating components of the Einstein Toolkit has several shortcomings.  We propose an additional layer of management around a Cactus tree achieved by storing it in a Git repository.  This provides a uniform version control interface to the code with all the version control information from the source repositories available.  It also allows the entire Cactus tree to be treated as a single repository, and allows "versions" of the code to be identified by a single Git revision.
  
The current method for checking out and updating components of the Einstein Toolkit has several shortcomings.  We propose an additional layer of management around a Cactus tree achieved by storing it in a Git repositoryThis provides a uniform version control interface to the code with all the version control information from the source repositories available.  It also allows the entire Cactus tree to be treated as a single repository, and allows "versions" of the code to be identified by a single Git revision.
+
This project is still in the early stages.  We (Barry Wardell and Ian Hinder) are developing a set of techniques and tools which enable what we consider to be better workflows for using Cactus.  As we use these ourselves, we will learn about what works and what doesn't, and hopefully will be able to provide recommended workflows for end-users.
  
This project is still in the early stages of development and testing.  We are providing a set of techniques and tools which enable what we consider to be better workflows for using Cactus.  As we use these ourselves, we will learn about what works and what doesn't, and hopefully will eventually be able to provide recommended workflows for end-users.
+
==Documents==
  
 
* [[GitSuperRepoRationale|Rationale]]
 
* [[GitSuperRepoRationale|Rationale]]
 
* [[GitSuperRepoUsersGuide|User's guide]]
 
* [[GitSuperRepoUsersGuide|User's guide]]
* [[GitSuperRepoServerGuide|Server administrator's guide]]
+
* [[GitSuperRepoAdminGuide|Server administrator's guide]]
 +
* [[GitSuperRepoUnsorted|Unsorted information]]
 +
 
 +
==Progress==
 +
 
 +
* We have set up a repository which implements most of what is described in the [[GitSuperRepoRationale|Rationale]].
 +
 
 +
* Repository is updated from the source repositories every hour
  
=Current Status=
+
==Planned work==
  
* We have set up a repository which implements most of the above
+
* Figure out some good scripts or git aliases for making working with the submodules more straightforward.
  
* It is updated from the source repositories every hour
+
* Set up a public "einsteintoolkit" repository
  
* Not currently integrated with build and test
+
* Integrate with build-and-test system so that there is always a branch which passes build-and-test
  
* Version information not currently written into simulation output
+
* Implement a technique for storing version control information (revision plus differences) into simulation output
  
* Interacting with the repository could be made easier by a couple of small user-friendly scripts
+
* Update the group repository based on commit emails or an RSS feed rather than hourly

Latest revision as of 15:51, 27 June 2011


The current method for checking out and updating components of the Einstein Toolkit has several shortcomings. We propose an additional layer of management around a Cactus tree achieved by storing it in a Git repository. This provides a uniform version control interface to the code with all the version control information from the source repositories available. It also allows the entire Cactus tree to be treated as a single repository, and allows "versions" of the code to be identified by a single Git revision.

This project is still in the early stages. We (Barry Wardell and Ian Hinder) are developing a set of techniques and tools which enable what we consider to be better workflows for using Cactus. As we use these ourselves, we will learn about what works and what doesn't, and hopefully will be able to provide recommended workflows for end-users.

Documents

Progress

  • We have set up a repository which implements most of what is described in the Rationale.
  • Repository is updated from the source repositories every hour

Planned work

  • Figure out some good scripts or git aliases for making working with the submodules more straightforward.
  • Set up a public "einsteintoolkit" repository
  • Integrate with build-and-test system so that there is always a branch which passes build-and-test
  • Implement a technique for storing version control information (revision plus differences) into simulation output
  • Update the group repository based on commit emails or an RSS feed rather than hourly