Branch only on specific extensions in clearcase

Go To


I am attempting to write a configspec which will only branch on certain file types (I.E. Docs can be painful so we wish to avoid those).

Right now I have the following extensions: *.txt and *.pl (for example)

I have tried:

element * CHECKEDOUT
element -directory * \main\LATEST
element '{*.txt||*.pl}'  \main\BLARG\LATEST
element '{*.txt||*.pl}'  \main\LATEST -mkbranch BLARG

And some variations using parentheses, and whatnot.

I am just perplexed, I did find that in certain contexts you can use the comparison operators similar to c++ but can't get this to work.

(looking at the query language section from here:

I should be able to use: query && query

Is it possible to only allow branching on specific filetypes by use of a configspec, and if so, any hints/tips/something to get me headed in the right direction?

EDIT: Reading from the link I sent (one of the pages on that site anyways), you can set it up using something to the effect of

element * CHECKEDOUT
element -directory * \main\LATEST
element *.[hc]  \main\BLARG\LATEST
element *.[hc]  \main\LATEST -mkbranch BLARG

This should match any h and c files that you are looking at and allow to branch based on those.

element * CHECKEDOUT
element -directory * \main\LATEST
element *.txt  \main\BLARG\LATEST
element *.txt  \main\LATEST -mkbranch BLARG

That will work and only matches .txt files, which is great, I was just hoping that it would match for additional sets, maybe I could add an additional line or two and maybe that would accomplish what I'm attempting to do.

element * CHECKEDOUT
element -directory * \main\LATEST
element *.txt  \main\BLARG\LATEST
element *.pl  \main\BLARG\LATEST
element *.txt  \main\LATEST -mkbranch BLARG
element *.pl  \main\LATEST -mkbranch BLARG

Our team only branches on certain sets of files for a variety of reasons, one being that in some cases it's difficult to merge (Note .doc files). I was going to write up a configspec that would automatically branch what our team designates as "branchable", but otherwise just checkout main.

I hope my issue is clearer, and I think that it's not quite what you're talking about in your initial answer VonC (I think), please let me know if your answer still holds.

2012-04-04 19:49
by onaclov2000


No, it doesn't seem to be easily possible (unless you list each type you want to branch), and for a reason.
The idea behind branching is to isolate the history for a group of files (not for some specific parts of said group).
That idea has been reinforced with UCM and its notion of UCM component (a coherent set of files, which branches as a all, and which is labelled as a all unit).
See more on "component" in the article "Best practices for using composite baselines in UCM".

UCM component

So trying very hard to bend the tool in order to achieve that one selective versionning organization might not be the right thing to do.

Isolating those file in their own "component", and then using them through symlinks back into your original tree structure is one possible solution (there might be other) which is at least better (and which is reminiscent of the notion of submodules or sub-forests used by other (D)VCS)

Plus, if you branch for the reason it is "difficult" to merge:


I realize you are branching for other reasons that might be valid, but again, I like my branching policy simple, manageable and scalable.

2012-04-04 20:45
by VonC
I am guessing that I wasn't very clear on the matter. I'll try to revise a little - onaclov2000 2012-04-04 20:50
@onaclov2000 I think you were pretty clear. My answer stands: don't do that. Isolate the problematic files in their own component, with different merge policy coherent for that group of file - VonC 2012-04-04 21:19
I guess I'm not sure how the component idea relates to what I'm trying to do, it appears that when you use "components" and you check out a "component" it will check out all associated files within the component (that's what I gathered from the link you included). When I check out a single txt file I want the configspec to say it's ok to check that out on a branch (part of my change), but for the same change set, assuming I need to check out a .doc file, I want it to branch from the main line. It seems like these are two different concepts per se.... Could you elaborate? or possibly more link - onaclov2000 2012-04-04 21:40
When I checkout for a change I don't always checkout the same "set" of files. Does that make any difference - onaclov2000 2012-04-04 21:41
@onaclov2000: component are not about "checkout all the file (at the same time), but about "checkout any files of said component in the same way, ie using the same branch. Or labelling all the files the same way (with one label for all the files of a component). Trying to manage different branches within one group of file is simply too complex (I never saw it working in the long term) - VonC 2012-04-04 22:14
@onaclov2000 the difference between my group of files ("component") and your group of files is that yours is a mixed group of files, with some you want to treat a certain way (ie branch differently) and others you treat another way. This doesn't scale well, especially when you managing several releases in parallel (with several branches per releases), and is generally to "fragile" (one mishap on the config spec and you end up with versions on the wrong branch). Using the same policy for all the files within a root directory (which is how a component is defined) is easier - VonC 2012-04-04 22:22
hmmm You might have much to teach me. I guess we've been using it quite a bit differently here. I am always interested in learning further. If you have time sometime, maybe we can chat about this - onaclov2000 2012-04-04 22:35
let us continue this discussion in chatVonC 2012-04-05 03:53
Conceptually this is the best choice for how to develop - onaclov2000 2012-05-11 13:50