Slicer3-lib-mirror - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T17:05:54Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Protected "Slicer3-lib-mirror" [edit=sysop:move=sysop]

2008-05-22T16:03:47Z

Protected "Slicer3-lib-mirror" [edit=sysop:move=sysop]

Marianna: Unprotected "Slicer3-lib-mirror"

2008-05-19T16:26:24Z

Unprotected "Slicer3-lib-mirror"

Marianna at 16:26, 19 May 2008

2008-05-19T16:26:21Z

Pieper: /* Experimental/Issues */

2007-07-28T14:22:00Z

Experimental/Issues

Pieper: /* Overview */

2007-07-26T18:53:14Z

Overview

Pieper: /* Experimental */

2007-07-26T18:51:49Z

Experimental

Pieper at 18:43, 26 July 2007

2007-07-26T18:43:40Z

New page

==Overview==
The Slicer3-lib-mirror is an svn repository on na-mic.org to store local copies of support libraries. It is used by the getbuildtest2.tcl script. As of July 2007, it is still experimental but should be functional on all platforms.

==Structure==

The svn repositories are unique in that they contain a cvs checkout of the original library ''including the CVS directories''. This means that if when you check these out with subversion, the local svn copy can be used to to perform a cvs update. The updated code can then be checked back into subversion. This is how new versions of the code are brought into slicer.

==Updating a Library==

For example, to update tcl to a new release:

~/slicer3/latest/Slicer3-lib/tcl/tcl$ cvs -q update -r core-8-4-15 -dP

Then delete the Slicer3-lib/tcl-build directory and re-run getbuildtest2.tcl to test the new libraries. If all goes well, then the updated code can be commited to the Slicer3-lib-mirrors repository.

== Experimental ==

This is experimental because the idea of having a 'live' cvs tree checked into svn may not actually work well in the long term.

← Older revision		Revision as of 17:05, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer3-lib-mirror here]</font></big>	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3-lib-mirror here]</font></big>

← Older revision		Revision as of 16:26, 19 May 2008
Line 1:		Line 1:
−	~~==Overview==~~	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3-lib-mirror here]</font></big>
−	The Slicer3-lib-mirror is an svn repository on na-mic.org to store local copies of support libraries. It is used by the getbuildtest2.tcl script. As of July 2007, it is still experimental but should be functional on all platforms.
−
−	~~Motivation for this is that some tools that are in SourceForge (teem, tcl...) can cause nightly build errors because the site~~'~~s repository goes down fairly frequently. Also, the mirror can contain local changes/patches that have not yet been incorporated in the upstream project.~~
−
−	~~==Structure==~~
−
−	~~The svn repositories are unique in that they contain a cvs checkout of the original library~~ ''~~including the CVS directories~~''~~. This means that if when you check these out with subversion, the local svn copy can be used to~~ to ~~perform a cvs update. The updated code can then be checked back into subversion. This is how new versions of~~ the ~~code are brought into~~ slicer.
−
−	~~==Updating a Library==~~
−
−	~~For example, to update tcl to a new release:~~
−
−	~~~/slicer3/latest/Slicer3-lib/tcl/tcl$ cvs -q update -r core~~-~~8-4-15 -dP~~
−
−	~~Then delete the Slicer3-lib/tcl-build directory and re-run getbuildtest2.tcl to test the new libraries. If all goes well, then the updated code can be commited to the Slicer3-lib-mirrors repository.~~
−
−	=~~= Experimental/Issues ==~~
−
−	~~This~~ is ~~experimental because the idea of having a 'live' cvs tree checked into svn may not actually work well in the long term.~~
−
−	~~For example, new/deleted files and conflicts between local patches and updated versions need to be resolved manually.~~
−
−	~~In addition, some of the upstream repositories may (will?) eventually switch to svn. If and when this happens, we can look as svn mirroring tools. E.g.~~ [http://~~blog~~.~~wordaligned~~.org/~~articles~~/~~2006~~/~~08/12/how~~-to-mirror~~-a-subversion-repository~~] ~~and [http:~~//~~svn.collab.net/repos/svn/trunk/notes/svnsync.txt]~~

← Older revision		Revision as of 14:22, 28 July 2007
Line 22:		Line 22:
	For example, new/deleted files and conflicts between local patches and updated versions need to be resolved manually.		For example, new/deleted files and conflicts between local patches and updated versions need to be resolved manually.

−	In addition, some of the upstream repositories may (will?) eventually switch to svn. If and when this happens, we can look as svn mirroring tools.	+	In addition, some of the upstream repositories may (will?) eventually switch to svn. If and when this happens, we can look as svn mirroring tools. E.g. [http://blog.wordaligned.org/articles/2006/08/12/how-to-mirror-a-subversion-repository] and [http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt]

← Older revision	Revision as of 16:03, 22 May 2008
(No difference)

@@ Line 1: / Line 1: @@
 ==Overview==
 The Slicer3-lib-mirror is an svn repository on na-mic.org to store local copies of support libraries.  It is used by the getbuildtest2.tcl script.  As of July 2007, it is still experimental but should be functional on all platforms.
 ==Structure==

@@ Line 14: / Line 14: @@
 Then delete the Slicer3-lib/tcl-build directory and re-run getbuildtest2.tcl to test the new libraries.  If all goes well, then the updated code can be commited to the Slicer3-lib-mirrors repository.
-== Experimental ==
+== Experimental/Issues ==
 This is experimental because the idea of having a 'live' cvs tree checked into svn may not actually work well in the long term.