On Thu, 3 Feb 2000, John Lawlor wrote:
> We are in the early stages of ClearCase and don't really use branches until
> now.
>
> One of the development groups wants to create a branch for doing NT
> development work only and then merge it back in a few weeks (another story).
> The development group each use their own views.
>
> What is the best way to manage this branch?. All I have come up with so far
> is,
> 1. Declare a branch type 'nt_development'
> 2. Do a Cleartool mkbranch nt_development.
>
> These raise a few questions,
> Can I branch the whole project or can I only do one file at a time?
> If I get the developers to setup the views with these rules:
> element * CHECKEDOUT
> element * /main/nt_development/LATEST
> element * /MAIN/1 -mkbranch nt_development
> that will branch each file version onto this branch, but will I have to
> merge the files back in 1 by 1?
>
> What is the best/smoothest way to get through this?
Short answer: RTFM :):) - also read the post script at the end of this
mail...
Most shops will set up to create branches on demand, leaving elements that
are identical on the main branch. After all, this is what config specs are
for - they give you something like a search path for versions.
Then, consider actually creating two branches: One, say, for
unix_development and one for nt_development (also consider calling them nt
and unix for short, since you might end up typing this a lot).
The main branch would contain the "common" trunc, and the variant branches
unix and nt would contain the platform specific changes - we'll see later
why this is useful.
The config spec of a view using the variant branch should look like this:
element * CHECKEDOUT
element * .../nt/LATEST
element * /main/LATEST -mkbranch nt
The "..." wildcard matches any path. In this particular case, you could
simply say /main/nt/LATEST, but as your knowledge of clearcase deepends,
you will very quickly discover other good uses for branches, and getting
into the habit of writing config specs this way will focus your attention
onto the essential, but enough zen for now.
Now please go to the reference manual and read up on the cleartool
findmerge command. It is absolutly essential for you to understand this
command, as it is the heart of any serious clearcase work.
Still reading? Go get that manual....
Ok, you now know findmerge, at least in principle. Now we can discuss
change process. Above I mentioned creating also a unix branch. This is
why:
You now have three branches to work with: main
/\
unix nt
You should also create three views, with the following config specs:
View "main":
element * CHECKEDOUT
element * /main/LATEST
View "nt"
element * CHECKEDOUT
element * .../nt/LATEST
element * /main/LATEST -mkbranch nt
View "unix"
element * CHECKEDOUT
element * .../unix/LATEST
element * /main/LATEST -mkbranch unix
Now, when making changes, you really have three kinds:
1) Changes that affect both platforms in the same way
2) Changes that affect only unix
3) Changes that affect only nt
You should be able to partition your work into these three classes.
Perform class (1) kind of work in the "main" view, class (2) in the "unix"
view, class (3) in the "nt" view.
On a regular basis, or everytime you're done with some task in class (1),
you should merge that change into the respective branches, using the
findmerge command. Most likely, it will look something like this:
# set to the variant branch view - e.g. "nt":
cleartool setview nt
# first merge directories (we cannot use -avobs since the order of
# merges is random, and we require that the order be recursive traversal,
# as we would otherwise miss some merge candidates...
cleartool findmerge /vob/*/.\
-type d\ # only consider directories
-element 'brtype(nt)'\ # only consider elements that actually
-merge # have an nt branch
# Then merge files, using an almost identical command
cleartool findmerge /vob/*/.\
-type f\ # only consider files
-element 'brtype(nt)'\ # only consider elements that actually
-merge # have an nt branch
Hope this sets you straight...
-- cgP.S. If this is some coding project in C/C++, I'd actually prefer using the classic #ifdef method (or the method of selectivly compiling certain files via a Makefile) to using this branching strategy, as human nature and general lazyness will invariably cause the code to fork substantially.
Also, if ever you need to compile this code outside of clearcase, you now have to build two source distributions.
otoh, if you're very disciplined and want to hide unix stuff from nt (and vice versa), go right ahead... -- cg
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:00 EDT