GitSuperRepo - Revision history

Barry.wardell: /* Documents */

2011-06-27T15:51:23Z

‎Documents

Barry.wardell at 08:33, 27 June 2011

2011-06-27T08:33:42Z

Hinder: /* Planned work */

2011-06-24T05:19:07Z

‎Planned work

Hinder at 03:35, 24 June 2011

2011-06-24T03:35:28Z

Hinder at 03:07, 24 June 2011

2011-06-24T03:07:33Z

Hinder at 03:04, 24 June 2011

2011-06-24T03:04:19Z

Hinder at 02:55, 24 June 2011

2011-06-24T02:55:58Z

Hinder at 02:53, 24 June 2011

2011-06-24T02:53:53Z

Hinder at 02:49, 24 June 2011

2011-06-24T02:49:58Z

Hinder at 02:44, 24 June 2011

2011-06-24T02:44:55Z

@@ Line 9: / Line 9: @@
 * [[GitSuperRepoRationale|Rationale]]
 * [[GitSuperRepoUsersGuide|User's guide]]
-* [[GitSuperRepoServerGuide|Server administrator's guide]]
+* [[GitSuperRepoAdminGuide|Server administrator's guide]]
 * [[GitSuperRepoUnsorted|Unsorted information]]

←Older revision		Revision as of 08:33, 27 June 2011
Line 1:		Line 1:
		+	[[Category:GitSuperRepo]]
		+
	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 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.

@@ Line 17: / Line 17: @@
 ==Planned work==
 * Integrate with build-and-test system so that there is always a branch which passes build-and-test
@@ Line 22: / Line 26: @@
 * 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

@@ Line 8: / Line 8: @@
 * [[GitSuperRepoUsersGuide|User's guide]]
 * [[GitSuperRepoServerGuide|Server administrator's guide]]
 ==Progress==

←Older revision		Revision as of 03:07, 24 June 2011
Line 1:		Line 1:
−	~~=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 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.
−
−	~~=Current Status=~~

	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. 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.

@@ Line 1: / Line 1: @@
 =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.
-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.
+=Current Status=
 * [[GitSuperRepoRationale|Rationale]]
@@ Line 11: / Line 13: @@
 * [[GitSuperRepoServerGuide|Server administrator's guide]]
-=Current Status=
+==Progress==
-* We have set up a repository which implements most of the above
+* Repository is updated from the source repositories every hour
-* It is updated from the source repositories every hour
+==Planned work==
-* 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

←Older revision		Revision as of 02:53, 24 June 2011
Line 6:		Line 6:

	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.		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.
		+
		+	* [[GitSuperRepoRationale\|Rationale]]
		+	* [[GitSuperRepoUsersGuide\|User's guide]]
		+	* [[GitSuperRepoServerGuide\|Server administrator's guide]]

	=Rationale=		=Rationale=

←Older revision		Revision as of 02:49, 24 June 2011
Line 1:		Line 1:
	(draft)		(draft)
		+
		+	=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.
		+
		+	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.

	=Rationale=		=Rationale=

@@ Line 1: / Line 1: @@
 (draft)
 ==Background==
@@ Line 55: / Line 59: @@
 * Users have all the benefits of distributed revision control, and the entire version history of all components (including SVN ones) at their fingertips in their local repository copies.
-==Current Status==
+=Current Status=
 * We have set up a repository which implements most of the above
@@ Line 66: / Line 70: @@
 * Interacting with the repository could be made easier by a couple of small user-friendly scripts