wiki-archive/twiki/temp-gjr/BDI/SDD/SubversionTreeSnapshot.txt,v

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%

|<img src="%ATTACHURLPATH%/Rel24.GIF" alt="Rel24.GIF"  >|This is the history of the sdd repository at the state of the release of SDD1.1-RC1.<br/><br/>Red boxes are branches that have been removed. (In SVN, you can run but you can't hide.). <br><br>\
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. <br><br>\
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/. <br><br>\
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. <br><br>\
@


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. <br><br>\
@


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"}%
@