▁developers , ▁but ▁sharing ▁branches ▁is ▁the ▁more ▁common ▁practice . ▁A ▁branch ▁hierarchy ▁is ▁often ▁useful : ▁an ▁entire ▁development ▁project ▁can ▁share ▁a ▁common ▁development ▁branch , ▁while ▁a ▁smaller ▁team ▁can ▁share ▁a ▁sub - branch , ▁with ▁each ▁developer ▁having ▁his ▁or ▁her ▁own ▁private ▁branch . ▁When ever ▁a ▁change ▁on ▁a ▁branch ▁is ▁de emed ▁stable ▁enough , ▁it ▁can ▁be ▁merged ▁to ▁the ▁parent ▁branch . ▁ ▁The ▁configuration ▁specification ▁▁ ▁Under ▁base ▁Clear Case , ▁each ▁view ▁is ▁controlled ▁by ▁its ▁associated ▁configuration ▁specification , ▁commonly ▁referred ▁to ▁as ▁a ▁config ▁spec . ▁This ▁is ▁a ▁collection ▁of ▁rules ▁( st ored ▁internally ▁in ▁a ▁text ▁file , ▁but ▁compiled ▁before ▁use ) ▁that ▁spec ifies ▁what ▁element ▁versions ▁( files ▁or ▁directories ) ▁are ▁to ▁be ▁displayed ▁in ▁a ▁view . ▁To ▁determine ▁which ▁version , ▁if ▁any , ▁of ▁an ▁element ▁should ▁be ▁visible , ▁Clear Case ▁travers es ▁the ▁configuration ▁specification ▁line - by - line ▁from ▁top ▁to ▁bottom , ▁stopping ▁when ▁a ▁match ▁is ▁found ▁and ▁ign oring ▁any ▁subsequent ▁rules . ▁A ▁configuration ▁specification ▁can ▁also ▁reference ▁other ▁configuration ▁specific ations ▁by ▁means ▁of ▁an ▁' include ' ▁statement . ▁ ▁In ▁the ▁U CM ▁management ▁model , ▁config ▁spec s ▁do ▁not ▁need ▁to ▁be ▁created ▁or ▁maintained ▁manually : ▁they ▁are ▁generated ▁and ▁maintained ▁by ▁Clear Case ▁U CM ▁operations . ▁ ▁Build s ▁▁ ▁The ▁network ed ▁filesystem ▁provided ▁by ▁M V FS ▁allows ▁for ▁build