Using timestamps in place of labels on the main branch is perfectly reasonable, given that that branch always meets the limitations required for such a strategy to work. Labelling in this way also has the benefit of completing in small, constant time, which is a desireable feature when applying labels to a very large number of versions.
For branches other than main, it is necessary to track the sprout points from ancestor branches and write appropriate config specs. This is a pain to implement, but doable.
----------
The CEO of my employer requires me to include the following notice in my
signature:
* This message is intended only for the use of the Addressee and may contain
information that is PRIVILEGED and CONFIDENTIAL. If you are not the
intended recipient, dissemination of this communication is prohibited. If
you have received this communication in error, please erase all copies of
the message and its attachments and notify us immediately.
---
Paul M. Sander +1 650 261 5174 | To the medieval era's literate few..., the
BroadVision, Inc. | turn of the millenium held a particular alure.
585 Broadway | After all, with the stroke of a quill, the
Redwood City, CA 94063 USA | world went from DCCCCLXXXXVIIIJ to...M.
| -- Rachel Emma Silverman, Wall St. Journal
> -----Original Message-----
> From: Paul D. Smith [mailto:pausmith@nortelnetworks.com
> Sent: Tuesday, July 03, 2001 12:56 PM
> To: cciug
> Subject: Re: [cciug] How to speed up Labelling 25,000 elements
>
>
>
> %% David Stevens <david.stevens@motorola.com> writes:
>
> ds> At last years conference one of the speakers advocated not
> ds> labeling anything at all! Instead he would create the
> label type
> ds> and use the date and time of the creation in config specs rather
> ds> than the label itself.
>
> My $0.02:
>
> This is a limiting approach: it _only_ works if what you're doing is
> applying a label to all the versions on a branch as of a certain time.
>
> Personally I think that any CM practice that relies on
> timestamps is not
> as robust or flexible as it should be--it forces you to require that
> there is some single point in time where every element has a
> version on
> your branch that is correct and valid with every other element's
> version.
>
> This, IMO, is a very tall, and quite unnecessary, order.
>
> --
> --------------------------------------------------------------
> -----------------
> Paul D. Smith <psmith@baynetworks.com> HASMAT--HA
> Software Methods & Tools
> "Please remain calm...I may be mad, but I am a
> professional." --Mad Scientist
> --------------------------------------------------------------
> -----------------
> These are my opinions---Nortel Networks takes no
> responsibility for them.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> can also
> unsubscribe
>
> http://clearcase.rational.com/cciug/mailing_list.html
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 22:03:49 EDT