With ClearCase, you create views with cleartool mkview, and delete them with cleartool rmview. Similarly, you create branch types with:
cleartool mkbrtype -c "some comment" my_brance_type
... but there is no cleartool rmbrtype which would be the opposite command. How do you remove a branch type in CMake?
The unintuitive command for removing a branch type is:
ct rmtype -rmall brtype:my_branch_type
See the detailed documentation about this on IBM's website.
Note: The -rmall is often (always?) necessary even if you don't have any objects with revisions of that branch type. (At least with ClearCase v8.0.0.x.)
Warning: a cleartool rmtype won't succeed if you have any instance of the type you want to remove.
Even with -rmall, it can still fail if the instance you remove (here a branch based on a brtype) has hyperlink and other UCM metadata which would be dangling if the branch disappear.
Related
I faced with the problem of writing my vcs current branch name each time I have written 'todo' comment.
Recently I learned about Intellij's 'Live Templates' which is quite comfortable to use. I tried to apply it to my problem but there's no templates to take out a branch name.
So the question is could I actually take out the name of my branch to code comments somehow?
It is possible to use the groovyScript predefined function and a script to extract the branch name. For example create the following live template:
$COMMENT$ todo [$BRANCH$]: $END$
with abbreviation "todo" and description "Inserts todo comment with branch name". Click Edit variables and give the variables the following definitions:
COMMENT:
lineCommentStart()
BRANCH (updated for 2020.2 and newer)
groovyScript("com.intellij.dvcs.repo.VcsRepositoryManager.getInstance(_editor.project).getRepositoryForFileQuick(com.intellij.openapi.fileEditor.FileDocumentManager.getInstance().getFile(_editor.document)).getCurrentBranchName()")
Skip if defined checked for both variables. The Groovy script is (unfortunately) all one line. Set applicable contexts to Everywhere.
With this live template it is now possible to type todoTab somewhere in a source file and a line comment with the branch name will be inserted. This will insert the proper line comment depending on the language of the file, or nothing in case of languages without a line comment like HTML. And should extract the branch name no matter the type of version control used (I tested with Git).
For live templates you can use predefined functions. Unfortunately there is no function to detect the current VCS branch.
But you can create a template to make work a little easier:
// TODO [$branch_name$]: $comment$
With this template, you still have to fill branch name, but you should not type symbols like [ and caret will be placed automatically.
You can also create a feature request for a new predefined function.
I have a trunk branch "A", and a testing branch "B".
"B" is branched from "A".
Now I want to merge "B" into "A", and did a "bzr merge -pull ${HOME}/B" under "A".
Then I realize that if now I do a "bzr info" under "A", I will find a new "submit branch B".
This sounds bad to me because all the committed changes in "A" will go to "B".
So my question is:
1. Is "bzr merge -pull ${HOME}/B" under "A" a good way to do what I want?
2. How to remove the "submit branch B" under "A"?
The submit branch is primarily used as a default for bzr send and bzr bundle. This should not create any problems for you (if you do use these commands, you can override the submit branch on the command line). It is also the default location for future merges if for some reason you do not specify one. The "submit" in "submit branch" refers to submitting changes for review, not to commits.
Most other commands should not be affected. Commits will go to the original branch unless you've made it a bound branch via bzr bind or bzr checkout, and those will go to the bound location, not the submit branch; pushes will go to the default push location, which is also different.
You can use bzr merge --no-remember to not set the submit branch (or edit .bzr/branch/branch.conf to remove the path afterwards). Similarly, you can use --remember to override an existing submit branch location.
Is that possible to get hierarchy of branches?
I have to know the father of a given branch
I have to know the children of a given branch
How do I get it by cleartool?
I prefer not to be based on a view config-spec
Thank you!
With base ClearCase, you cannot know the parent of a branch, because it can vary from file to file: a file can start branch 'B2' from '/main/LATEST', another can start the same branch from '/main/B1/LATEST'.
For ClearCase UCM, you can determine the parent of a branch by querying the ancestors of a Stream (since the branch is name after the stream):
cleartool lsstream -anc myStream#pvob
That is possible because branches are linked to Streams, which are organized following a strict hierarchy a Parent Stream / Children Streams.
Note that describing a stream (cleartool describe, using fmt_ccase) only gives you access to the children streams: hence the lsstream -ancestor, in order to display its parent.
Is it possible for me to declare a dependency using a dynamic revision while restricting the status of the retrieved artifact? For example, I want to define a version range, something like "[1.0,1.1[", but I don't want artifacts with a status of integration, only milestone or release. So I want version 1.0.5 if it has a status of "release" even if there's a version 1.0.6 with a status of "integration."
I know about latest.status, but that's not really what I want: I need to define an upper and lower limit on the revision.
Maybe the solution is to define your own version-matcher see http://ant.apache.org/ivy/history/latest-milestone/settings/version-matchers.html
I used it (in ivysettings.xml) to make this:
<!-- Matcher for build with given build number
It assumes the version number is on the form
#.#__.# where the lastet '.#' is the build number. -->
<version-matchers usedefaults="true">
<pattern-vm>
<match revision="build_number" pattern="[\d\.]+\.${buildnumber}" args="buildnumber" matcher="regexp"/>
</pattern-vm>
</version-matchers>
You can call it in you build script by setting the revision attribute like 'revision="build_number(${prop.buildnumber})"'
Thanks for asking this question, rsteele. I had a similar question and here is the solution I am using. It works if your range corresponds to sub-revisions:
The easiest way to present this is with an example:
<dependency org="com.acme" name="wigdet" branch="1" rev="latest.milestone">
1/ivy-1.0.xml: status="integration"
1/ivy-1.1.xml: status="milestone"
1/ivy-1.2.xml: status="integration"
The dependency resolves to 1.1.
This works for me but I am not entirely happy with it and I hope someone can point out a better way or poke holes in it:
branch seems appropriate because com.acme actually has a branch in version control which corresponds to version 1.
on the other hand branch seems inappropriate because "1" is part of the revision, and perhaps branch is more useful in other ways.
this doesn't solve the more general problem posed by rsteele.
I'm using cvs2svn to convert my repository. I've done it with success in one repository, and now my new problem is a second repository.
In my new conversion, I want to convert only the HEAD and one branch. cvs2svn only have "exclude" function for branches, but not "include". I have many many branches and excluding each and every one of them will take A LOT of work....
is there any way to convert only the trunk (HEAD) and only one branch?
thanks,
Oded
If you only want to retain the one branch and no tags, then this is easy. The first rule that matches a symbol is used, so specify the branch that you want to be included then exclude everything else:
cvs2svn --force-branch=mybranch --exclude='.*' ...
If you want to include not only the branch but also as many tags as possible, then it is a little bit trickier. Not only don't you necessarily know the names of all of the tags, but you also cannot include tags that are dependent on excluded branches. In this case, it is easiest to work with the --write-symbol-info and --symbol-hints options:
cvs2svn --write-symbol-info=symbol-info.out --passes=1:3 ...
This will create a file called "symbol-info.out" containing information about all CVS symbols. In your editor, open this file, find all of the lines corresponding to branches that you want to exclude, and change the third column of those lines to the word "exclude". Make sure that the third column of the line for the branch that you want to include contains the word "branch" and its fourth column is the path where you want it to end up.
Now run cvs2svn again, starting at pass 3, and using the edited symbol-info file as a symbol hints file:
cvs2svn --symbol-hints=symbol-info.out --passes=3 ...
you will get a lot of errors like:
ERROR: ExcludedSymbol('FOO_BRANCH') cannot be excluded because the following symbols depend on it:
BAR_TAG
BAZ_TAG
Now go back into the editor and change the listed tags (BAR_TAG and BAZ_TAG in the example) to be excluded too, then try running pass3 again. This procedure might need to be iterated a couple of times, but it should not be cumbersome because pass3 runs very quickly.
When you have gotten pass3 to complete without errors, run the rest of the conversion:
cvs2svn --symbol-hints=symbol-info.out --passes=4: ...
One problem is that cvs2svn not only needs to determine whether to include a branch or not, but (simultaneously) whether a symbol is a branch or a tag in the first place. So if you want to include that one branch, and also some tags, it's more difficult than just saying "include only that branch" - doing so would kill all tags.
IOW, cvs2svn doesn't really support that. You can work around by editing its source code. In cvs2svn_lib.symbol_strategy.BranchIfCommits, change the case where it returns Branch(symbol) to
if symbol.name == 'my_branch':
return Branch(symbol)
else:
return ExcludedSymbol(symbol)
IIUC, BranchIfCommits should be used by default.
Personally, I would use a different strategy:
1. convert the repository once, with all branches.
2. do a "svn ls" on branches, and redirect that into a file.
3. edit the file to construct an exclude regex out of it, of the form `b1|b2|...|bn`
I wouldn't call that a LOT of work...