Details
-
Suggestion
-
Resolution: Unresolved
-
None
-
7
-
Description
We are doing what the SVN red book calls a complex tag which is simply multiple files at different revisions. The tags are a representation of a potentially shipping build. I do not believe that it is an uncommon method for larger development teams working on the same product. The reason we do complex tagging is because we do not stop development for everyone when there is a test failure in a build - people that do not have test failures are free to continue development and check in new code (however this bumps up the revision number - which is a singular entity). When we have test failures and get new code to fix the issue, we do not re-get everything - just the code that fixes the issue. Once we have everything working for a build, we check that in as a tag, but since it may contain multiple revisions, it is not what the red book calls a simple tag, but rather a complex tag.
A complex tag will look like:
------------------------------------------------------------------------ r10000 | name | 2009-11-16 22:43:38 -0500 (Mon, 16 Nov 2009) | 1 line Changed paths: A /tags/TAGNAME (from /trunk/PRODUCTNAME:21836) R /tags/TAGNAME/Assemblys/Conversions/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Conversions/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Conversions/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Conversions/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Conversions/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Conversions/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath.Web/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath.Web/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath/Properties/AssemblyInfo.cs:21897) R /tags/TAGNAME/Assemblys/Diagnostics/Somepath.Forms/Properties/AssemblyInfo.cs (from /trunk/PRODUCTNAME/Assemblys/Diagnostics/Somepath.Forms/Properties/AssemblyInfo.cs:21897) ...
Due to the way fisheye normally does not fetch diffs for tags (as fetching a diff for an entire tag is time consuming and the information is already in the index), fisheye will not fetch a tag for the entire changeset but instead fetch a tag for each of the files that are replaced as part of the complex tag. If the number of these files is large, the fetching of the diffs take longer, causing the index to take a much longer time, than those that tag as per a simple tag.
Attachments
Issue Links
- mentioned in
-
Page Loading...