Jump to content


Best typemap compression practices for Spec depot

spec depot typemap best practices

  • Please log in to reply
1 reply to this topic

#1 Scott Gilliland

Scott Gilliland

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 21 February 2019 - 05:38 PM

Hello All,

Performed a quick search to see if this discussion had already been had and didn't see anything, so I'm creating a new topic. Apologies if this has already been covered. A quick question for admins regarding their spec depots and compression through the type map spec definition: do you use compression in your spec depot, and do you compress all or just some of it?

I'm interested in whether or not compression of the spec depot is done by most or considered a best practice, or if only some //spec types are compressed, or no compression is used. We have not been running compression (text+C in typemap definition for the //spec depot) but have recently turned it on for our client specs due to large revision counts now being encountered due to Jenkins builds. I know that we could exclude certain wildcard matches from being versioned at all, or limited with the +S flag, but our users have a wide variety of Jenkins client names making catching them with wildcard use problematic. To my knowledge regular expressions cannot be used in typemap definitions. So, we initiated compression of client specs as a first step our mitigation process. The question now becomes, if we're compressing clients should we simply compress every spec?

Interested in thoughts and my thanks to anyone willing to share their thoughts on this.

Regards,
Scott

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 764 posts

Posted 22 February 2019 - 12:49 AM

IMO the easiest thing is to use +C for all spec depots.  The main reason to use text+C vs the default "text" is that the default mode for text is RCS delta storage, which is generally pretty space-efficient (especially for things like source code which tend to have relatively small individual changes) but doesn't scale well on files with thousands of revisions.  With text+C each revision is stored independently, which eliminates the problem of having to compute an increasingly long series of deltas every time the spec is updated.





Also tagged with one or more of these keywords: spec depot, typemap, best practices

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users