head 1.5; access; symbols; locks; strict; comment @# @; 1.5 date 2009.11.25.03.14.38; author GarryJolleyRogers; state Exp; branches; next 1.4; 1.4 date 2009.11.20.02.45.32; author LeeBelbin; state Exp; branches; next 1.3; 1.3 date 2007.03.06.17.30.00; author TWikiGuest; state Exp; branches; next 1.2; 1.2 date 2006.05.15.07.48.39; author GregorHagedorn; state Exp; branches; next 1.1; 1.1 date 2006.05.14.00.20.56; author BobMorris; state Exp; branches; next ; desc @none @ 1.5 log @none @ text @%META:TOPICINFO{author="GarryJolleyRogers" date="1259118878" format="1.1" version="1.5"}% %META:TOPICPARENT{name="SubversionRepository"}% ---+!! %TOPIC% |Rel24.GIF|This is the history of the sdd repository at the state of the release of SDD1.1-RC1.

Red boxes are branches that have been removed. (In SVN, you can run but you can't hide.).

\ SVN branching occurs only when a new branch is made, so in this view, intermediate revisions exist that did not cause a branch. These may still participate in the construction of a branch though. For example, Revision 24 is the final revision of /releases/SDD1.1-RC, but it contains a file modified in Revision 22. It is the intention to never have more than one branch of a given released version: anything else would (and did) represent an error in the release process, including the existence of the releases named foo2. So I deleted the erroneous releases. Thus, the graph itself gives no insight into which revisions of the trunk participated in the release. However, the SDD release process creates a !ReleaseNotes file distributed with the release (but not kept in the repository) which tells the latest revision of the tree having modified files that participated in the release.

\ Because _any_ change that happens in the repository causes a new revision, there may be files not participating in a particular branch, e.g. something in releases/.

\ Explicitly creating a new branch, as is our policy when a new release is made, also creates a new revision. So a release will _always_ have a higher revision than any file participating in it. | %META:FILEATTACHMENT{name="Rel24.GIF" attachment="Rel24.GIF" attr="h" comment="" date="1147564146" path="Rel24.GIF" size="27685" stream="Rel24.GIF" user="Main.BobMorris" version="2"}% %META:TOPICMOVED{by="GregorHagedorn" date="1147679319" from="SDD.SvnTreeSnapshot" to="SDD.SubversionTreeSnapshot"}% @ 1.4 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="LeeBelbin" date="1258685132" format="1.1" reprev="1.4" version="1.4"}% d6 1 a6 1 SVN branching occurs only when a new branch is made, so in this view, intermediate revisions exist that did not cause a branch. These may still participate in the construction of a branch though. For example, Revision 24 is the final revision of /releases/SDD1.1-RC, but it contains a file modified in Revision 22. It is the intention to never have more than one branch of a given released version: anything else would (and did) represent an error in the release process, including the existence of the releases named foo2. So I deleted the erroneous releases. Thus, the graph itself gives no insight into which revisions of the trunk participated in the release. However, the BDI.SDD release process creates a !ReleaseNotes file distributed with the release (but not kept in the repository) which tells the latest revision of the tree having modified files that participated in the release.

\ @ 1.3 log @Added topic name via script @ text @d1 2 a4 2 %META:TOPICINFO{author="GregorHagedorn" date="1147679319" format="1.1" version="1.2"}% %META:TOPICPARENT{name="SubversionRepository"}% d6 1 a6 1 SVN branching occurs only when a new branch is made, so in this view, intermediate revisions exist that did not cause a branch. These may still participate in the construction of a branch though. For example, Revision 24 is the final revision of /releases/SDD1.1-RC, but it contains a file modified in Revision 22. It is the intention to never have more than one branch of a given released version: anything else would (and did) represent an error in the release process, including the existence of the releases named foo2. So I deleted the erroneous releases. Thus, the graph itself gives no insight into which revisions of the trunk participated in the release. However, the SDD release process creates a !ReleaseNotes file distributed with the release (but not kept in the repository) which tells the latest revision of the tree having modified files that participated in the release.

\ @ 1.2 log @rename @ text @d1 2 @ 1.1 log @rename @ text @d1 2 a2 2 %META:TOPICINFO{author="BobMorris" date="1147566056" format="1.1" version="1.1"}% %META:TOPICPARENT{name="SddSvnRepository"}% d9 2 a10 2 %META:FILEATTACHMENT{name="Rel24.GIF" attachment="Rel24.GIF" attr="" comment="" date="1147564146" path="Rel24.GIF" size="27685" stream="Rel24.GIF" user="Main.BobMorris" version="2"}% %META:TOPICMOVED{by="BobMorris" date="1147566056" from="SDD.SvnTreeExample" to="SDD.SvnTreeSnapshot"}% @