On Fri, 29 Sep 2000, Marc Girod wrote:
> Hello,
>
> Continuing --temporarily I hope-- in private. I posted the first of my
> mails, did you notice?
I CC-ed my last response (and this one) to cciug.
> >>>>> "CG" == Christian Goetze <cg@digisle.net> writes:
>
> Thanks for this correction.
> I know about the textual/compiled forms of the CS, but I have been
> fooled by the fact the cs is implicitly reevaluated if you do the
> rename in the same view.
>
> $ ct lsvtree bar
> bar@@/main
> bar@@/main/1
> bar@@/main/foo
> bar@@/main/foo/1
> $ ct catcs
> element * CHECKEDOUT
> element * .../foo/LATEST
> element * /main/LATEST
> $ ct ls bar
> bar@@/main/foo/1 Rule: .../foo/LATEST
> $ ct rename brtype:foo foo-004
> Renamed branch type from "foo" to "foo-004".
> $ ct ls bar
> bar@@/main/1 Rule: /main/LATEST
>
> I had never checked renaming in a different view and getting:
>
> $ ct ls bar
> bar@@/main/foo-004/1 Rule: .../foo/LATEST
>
> This is quite a pain. I guess I have to get used to the idea of
> looping through all the views doing a ct setcs -current...
It's not a pain, it's a feature and you can take advantage of it.
> CG> o branch and label types are connected by hyperlinks
>
> I have such hyperlinks too, but after the publication, to access the
> information gathered with the branch type.
>
> CG> A delivery using your idea would involve renaming the current
> CG> integration branch into some generated name and renaming the
> CG> development branch into the integration branch's name and adding
> CG> the hyperlink. Note that this operation doesn't disturb anybody's
> CG> views (yet). A delivery will also reset the config spec of the
> CG> integration view corresponding to the integration branch
>
> If you wish, but isn't it simpler _not_ to have an "integration branch
> in advance", so that you don't need to modify anybody's config spec
> (but to do the setcs -current, I admit it now)?
But I don't want to change other people's views just because I delivered.
I use the integration branch (i.e. the former development branch of the
developer who did the last delivery) simply because it's already there.
Now the real problem (besides the long version extended pathnames) is that
config specs will grow very large. I guess one could regularly scan
through developer's views locating the latest "old" integration branch
that isn't referenced anywhere anymore and label that with a floating
label.
> CG> Some other developer's rebase will regenerate the config spec
> CG> using the rules above and initiate a findmerge -ftag
> CG> integrationview. (having to use ftag instead of fversion seems to
> CG> me like a big drawback. TANSTAAFL - delivery is faster, but rebase
> CG> will be a lot slower).
>
> I must be too deep in my world... Why not -fver with the (floating)
> label having been moved over the new integration?
See below. I think this is the point where we disagree fundamentally.
> I.e. the situation was (with your RFE) and from the point of view of
> joo, given that sue will publish:
>
> lsvtree:
> ...
> foo@@/int-027/1 # labelled INT, as well as INT_1.49
> foo@@/joe/5
> foo@@/sue/6
>
> config spec:
>
> element * CHECKEDOUT
> element * .../joe/LATEST
> element * INT -mkbranch joe
> element * /main/LATEST -mkbranch joe
>
> Sue publishes, the tree becomes:
>
> ...
> foo@@/int-027/1 # labelled INT_1.49
> foo@@/joe/5
> foo@@/int-028/6 # labelled INT, as well as INT_1.50
>
> The cs remains the same (with setcs -current), and the rebase goes:
>
> ct findmerge . -fve INT -merge
>
> CG> Another nice effect is that I no longer need to use time rules to
> CG> limit visibility of newer deliveries. They will simply be in a
> CG> branch not selected by the current compiled config spec.
This is an important point. I repeat:
> CG> As a developer, you never want anything to change unless you
> CG> initiated that change. If something breaks, you need to know that
> CG> it is because of something you did, not because of some
> CG> externality. Magically updating files without giving the developer
> CG> any chance to control this is always bad.
>
> Yes. With using labels, my developers may protect themselves by
> temporarily replacing the INT line in their cs with something like
> (OK, with guards for sub-directory trees):
>
> element * INT_1.49 -nocheckout
If developers need to hack their config spec just to get a feature that is
more or less a prerequisite to doing good parallel development, then all
the work put into developing process wrappers is for nought.
My first priority in my process wrappers is to avoid the need for
developers to even know about config specs. I want to be able to say:
"developer, use this view to do task X, use rebase to synch up, and
deliver to deliver". No intricate ClearCase knowledge beyond co and ci is
required.
> CG> Anyway, if you use the technique I described above, you don't need
> CG> any labels at all.
I don't like labels. The take too long to apply, and they tempt people
into doing bad things, like "fixing" a build problem by moving the label
backwards to a previous version. Labels are confort food for those who
don't trust Clearcase yet (a little harsh). There is a legitimate need for
labels (for example the one I described above, collapsing a long sequence
of branch rules that is no longer needed into one label rule), but people
tend to use them all over the place.
> I still only confusely guess that we have dual systems, which are
> equivalent modulo some systematic transformation.
I guess the main difference is when we do the "collapsing" I described
above. You do it immediatly, I only do it for obsolete branches. Doing it
immediatly has the unfortunate side effect of ramming deliveries down
everybody else's throat unless they take evasive action (for which a
separate label is required), but does have the advantage of keeping config
specs short. My config specs could grow very long, especially if people
don't rebase very often.
Anyway, I consider this discussion to be rather theoretical, since the
cascading branch problem just kills it. In an active development shop,
you'll easily get 10 deliveries a day or more, which means that after a
year, you may have version extended paths that go down thousands of
directories. Even if it doesn't crash anything, It's gonna slow you down
like hell.
All things considered, I think I'll just take the hit on the copy merge.
It's a one time hit per delivery anyway. If Rational ever chooses to
implement my RFE, or chooses to implement -mkbranch rules with an absolute
branch path (e.g. element * /main/LATEST -mkbranch /branch/userid/bugid),
then I may reconsider. Don't hold your breath, though...
-- cg- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:57 EDT