I guess I must have missed this...
-- cg---------- Forwarded message ---------- Date: Wed, 27 Sep 2000 18:02:24 +0000 (GMT) From: Christian Goetze <cg@digisle.net> To: Marc Girod <girod@stybba.ntc.nokia.com> Subject: Re: Cascading branches (was Re: [cciug] Testing an idea)
On Wed, 27 Sep 2000, Marc Girod wrote:
> >>>>> "CG" == Christian Goetze <cg@digisle.net> writes: > > CG> On 26 Sep 2000, Marc Girod wrote: > >> Thanks for your reply, Christian, > > I am sorry, I iintended my reply to go to the list... I hope this is > the only stupid mistake I did with it. > > I'll repost there... Would you please do so as well. > > Now, temporary in private. > > CG> My change model (and I assume it's similar to many others) goes like > CG> this: > > CG> ------X--- integration branch -------------------------------------> > CG> \ \ / > CG> initial mkbranch synch merge (rebase) copy merge (deliver) > CG> \ \ / > CG> `---development branch--------------------Y-------> > > Well so far, mine is slightly different. First, I use main as ultimate > integration branch (e.g. for intersite communication), with possibly > several levels of integration (depending on the projects). > > Then, I tend to obsolete the branches past the merges, in order to > share the contents of main (or of the next integration level) with > others. > > ------X--- intg ---------------------------------------> > \ \ / \ / > initial rebase deliver \ / > \ \ / \ / > `---devlt----Y `----Z > > > CG> So, what you are saying is that the final copy merge is trivial, > CG> and we would be better off if we could somehow recast the > CG> development branch at that stage into the new integration branch, > CG> either be renaming the development branch or by moving the initial > CG> branch point label X to Y. By doing this, we could skip the > CG> deliver step. > > Do the deliver through rename, which is far faster, thus safer (no > interferences) is fully reversible. > > CG> Hmm.... I actually like this idea. It would work great if the > CG> -mkbranch rule could be made to start the branch at "/", instead > CG> of as a sub branch of the old integration branch... > > But then, you need to update /, thus to merge, and you are back to > square one.
That is correct if I wanted to implement this behaviour with Clearcase as is. I was wishing there was a way to make it better (but there currently isn't).
Currently, the version extended name space does not describe the version tree completely. It is not possible to determine the branch point just by looking at the directory structure in the version extended name space. Additional info from the db is needed.
I have an RFE for ClearCase where I'm suggesting that "once per element" branches are treated just like "once per element" labels and therefore get the shortcut link from /. If that RFE was implemented, then one could access these branches as "element@@/branch" instead of having to run a find query using -version(.../branch/LATEST). Config spec rules would also look simpler.
As I have posted earlier, I actually believe that sub-branches don't serve a process purpose, and I'd rather use them to partition a flat name space than for process purposes (i.e. I'd like to be able to say -mkbranch /site/project/major/minor/developer/activity instead of having to rely on cascades. Curently, I simply ignore cascades and say -mkbranch site_project_major_minor_developer_activity).
All this to say: "no, I don't want to merge into yet another branch". > CG> I think it would be doable by renaming the old integration branch > CG> "out of the way" and renaming the development branch into the new > CG> integration branch. This has the advantage of not disturbing other > CG> developers until they do a "rebase" - which would, among other > CG> things, do a setcs -current and pick up the name change at that > CG> point (I think the compiled config spec will keep the reference to > CG> the old integration branch). > > No, it won't. The config spec rules are textual. The matches are based > on names. Now, you may have an option to replace my floating label > with an .../int/LATEST in the config specs, which may be equivalent. > Is it what you meant?
Sorry, but that's not how it works. There are two forms of the config spec. One is the textual representation, and one is the compiled form. The "setcs" command and its relatives transform the textual representation into the compiled representation. The compiled representation does _not_ use the actual names, but object ids. You can change the names of branches any way you want and not immediatly break anybody's views. Only when they later do a new "setcs" will they notice a problem. This is the reason why you can use UNIX views on NT, why things like "-time now" work etc...
My idea was to take advantage of this behaviour, allowing me to stealthily swap out integration branches. The "setcs -current" would be part of my rebase implementation". Of course, if developers hack their config specs often on their own, they need to be aware of these things.
In my world, I have a config spec generator that does all of this, and it works as follows:
o branch and label types are connected by hyperlinks o the initial branch name corresponds to the view name o the config spec generator will traverse the hyperlinks, generating a branch rule for every branch type and a label rule for every label type it finds en route. o a branch rule is "element * .../branch/LATEST -mkbranch devbranch" o a label rule is "element * label -mkbranch devbranch"
A delivery using your idea would involve renaming the current integration branch into some generated name and renaming the development branch into the integration branch's name and adding the hyperlink. Note that this operation doesn't disturb anybody's views (yet). A delivery will also reset the config spec of the integration view corresponding to the integration branch
Some other developer's rebase will regenerate the config spec using the rules above and initiate a findmerge -ftag integrationview. (having to use ftag instead of fversion seems to me like a big drawback. TANSTAAFL - delivery is faster, but rebase will be a lot slower).
Another nice effect is that I no longer need to use time rules to limit visibility of newer deliveries. They will simply be in a branch not selected by the current compiled config spec.
> CG> Moving the label from X to Y would disturb other developers and > CG> make things appear "magically". > > Er? This is a contract. If they want to protect themselves from the > chanegs of the floating label, they have the option of selecting an > underlying fixed label (but they know then they loose the transparent > compatibility). > > Anyway, I'd rather --as a developer-- select the floating labels > though which I accept controlled changes, that give a blank check > through "setcs -current"...
No you don't :)
As a developer, you never want anything to change unless you initiated that change. If something breaks, you need to know that it is because of something you did, not because of some externality. Magically updating files without giving the developer any chance to control this is always bad.
Anyway, if you use the technique I described above, you don't need any labels at all.
> CG> Another drawback that I see is that you have to use other means > CG> than findmerge to verify that the assumption that the delivery > CG> will only contain copy merges is correct. If you don't do that > CG> verification, you run a grave risk of clobbering changes. > > Er... I am not sure to understand. You mean: how to ensure that the > rebase has indeed been done in case of conflicting parallel > developments? The equivalent check is before moving by floating label, > to make sure that it is moved from a base version. > > Something like the following. I take the floating label to be moved as > "INT", and the branch to be published as "fix". I hope you like the > Posix shell syntax: > > for v in $(cleartool find . -ver 'version(.../fix/0)' -print | \ > xargs cleartool des -fmt "%En@@%PVn\n") > do > if [ -z "$(cleartool des -fmt "%l\n" $v | grep '\(INT\)')" ] > then echo $v > fi > done
That's too strict. I think all you need to do is to check that a findmerge -ftag integrationview -print doesn't produce any output (you of course optimize this by adding a -element 'brtype(devbranch)').
The bottom line looks somewhat like this:
Delivery by renaming:
(+) no copy merge / no duplicate versions (+) no floating label / time rules (+) easy to revers (-) creates very long version extended names (-) rebase requires -ftag (much slower) (-) delivery still needs a findmerge -print to verify compliance (-) takes even more faith in the system to understand
"Normal" delivery
(+) easy to understand (+) allows findmerge -fver (-) harder to reverse (-) creates logical duplicates of versions -- cg
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:57 EDT