Normally, the first committed version should start from 1. Version 0 is identical with branch point. But now I got a only version 0, and this prevent me to checkin any other version coz it warned me that the branch already created.
As explained in "Before adding files and directories to source control", the version 0 is a placeholder marking the start for all versions in a given branch:
You can end up with only the version 0 when you undo-checkout a file you just checked out in a new branch (in that case, only a version 0 for the newly created branch remains).
Regarding branches, you can have error like "element already has a branch of type branch", but only when there is an issue with the server and client time (clock) being not in sync.
ClearCase creates version 0 when you create an element (or a branch), which is usually checked out automatically. Version 0 is always either empty, or same as the branched version, as you noted. There shouldn't be any problem simply checking in version 1 on top of it.
Note that branches are created when you check out, not when you check in, so you shouldn't get any warnings on check-in. If you post the exact command line and warnings/errors, we'll probably be able to help you out more.
It could perhaps be that you've created a new element on your branch, and you're missing "/main/0 -mkbranch" in your config spec.
HTH.
Related
screenshot
I've just started learning C, so I've been practicing some basic codes.
I pressed F7 to initiate the build, but everything I get is the message like this-
build started...
===========Build: 0 succeeded, 0 failed, 1 up-to date, 0 skipped=========
I waited for over ten minutes and nothing would happen.
I made a new solution with the exact same code, but then it worked without problem.
what would be the problem...?
I wonder if you make any changes to your project Properties such as so that it cannot generate the executable program.
First, right-click on your C++ project Properties-->Configuration Properties-->General--> change Output Directories to $(SolutionDir)$(Configuration)\.
also change Intermediate Directories to $(Configuration)\.
change Target Name to $(ProjectName).
Besides, enter Linker-->General
change Output File to $(OutDir)$(TargetName)$(TargetExt)
After that, delete any Debug or Release,x64 folder under the solution folder and project folder.
Test it again.
In a software I have to tweak, the man file is located under doc/ along with a simple Makefile.am file:
man_MANS = software.1
EXTRA_DIST = $(man_MANS)
Upon installation, I expect make install to copy the manual under /usr/local/share/man/, but the script - instead - will try to install the man under /usr/local/share/man/man1 - which does not exist - throwing an error and stopping the process.
I would expect a similar behavior if I assigned software.1 to man1_MANS, though.
What is going on ? How is this possible that automake does not create non-existing folders ?
man_MANS will try to figure out in which section to put the manual depending on the extension you gave it, so it is correct in this case that it would install into ${mandir}/man1.
Since you say that MKDIR_P is empty in your output, try to ensure that AC_PROG_MKDIR_P is being called in your configure.ac (it should be automatically called by AM_INIT_AUTOMAKE but since you said it's old it might have some issues).
/vobs/trms/NVaR/DSR/simulationEngine/common##/main/2/nVARUTL.cxx##/main/nz_mig/1
Can someone explain the meaning of the above line?
Jim
This is an extended pathname which references:
the version 1 of nVARUTL.cxx in branch main/nz_mig,
itself accessible in the version 2 of the folder common in branch main
See more at "pathnames_ccase".
The ## references the element (common or nVARUTL.cxx), followed by their versions (branches/version).
element-pname##version-selector
Since the path starts with /vobs, it means you are accessing that version through a view set (cleartool setview) on Unix.
See as an example "About the version-extended path"
Note that each elements are selected by their own versions.
So your config spec shows only the versions of nVARUTL.cxx: /main/nz_mig/1, with branch nz_mig coming from main/14:
This has nothing to do with the version of the parent folder common.
That parent folder 'common' is selected by the version /main/2.
On this example, how are merges back to “main” from “windows” and “test” branches normally handled (red lines)?
For instance, developer under “windows” branch fixes a bug by setting A=1, and then tests the fix under “windows” and calls it “done”, so he merges “windows” back to “main” as “main/8” that’s not a problem thus far.
But then, say that developer under “test” branch changes A to “A=0” to fix the bug he is working on.
What happens when “test/4” is merged back to “main”?
Now “main/9” shows “A=0”, overwriting the fix done by “windows/1”.
Then say that the developer who worked on the fix under “windows” now needs to work on another fix and creates “windows_2”. He will be thinking that A is still “A=1”, because that’s how he left it. The developer might go through a painful process to discover that now “A=0”.
How are these types of changes handled, so changes do not get reversed from one merge to the next when branches are created in parallel from the main “trunk”?
Any info will be greatly appreciated.
Thank you very much.
What happens when “test/4” is merged back to “main”?
This is a non-trivial merge, because the*same* line for "A=" has been modified twice, compared with the common ancestor. This is a clear conflict during the merge, and it won't be an automatic one.
So the developer merging back test branch will have to choose between test and windows line, and hopefully, will check with the developer from the windows branch.
From the merge page:
When two or more contributors differ from the base contributor, Diff Merge detects the conflict, and prompts you to resolve it. It displays all contributor differences and you can accept or reject each one.
[changed 10] | [changed to 10 file 2]---
A; | A=1;
-|-
[changed 10] | [changed to 10 file 3]---
A; | A=0
|-
Do you want the CHANGE made in file 2? [yes]
no
Do you want the CHANGE made in file 3? [yes]
yes
Applying CHANGE from file 3 [line 10]
============
But the true answer is communication: if the same file needs modifications (especially in the same lines), there should be some way of managing and coordinating those types of development efforts.
ClearCase also proposed locks on checkout (cleartool checkout -reserved) which would prevent test to be checked out while windows version is checked out. That can also prompt the developer on test to check with his/her colleague, and be aware of the nature of the fix being done.
I compiled libAPR sources and ran successfully all tests provided by Apache.
However when I link my program to libapr.so the same functionality is not present.
For instance, apr_pollset_add primitive doesn't work. It returns always 1 (when it should return 0) and doesn't work (in the source test works like a charm).
I modified all the code of APRlib related to that primitive so it would just return -1. When I run the Apache tests, they present expected behaviour (return -1), however once again when I call the primitive from .so libs it is always returning 1.
I am almost sure the lib has just a wrapper on that function wich returns always 1.
Any clue on what is happening?
So finally I found the problem.
I had libapr already installed in my system, so whenever I would use -libapr-1, it would link my program to the previously installed version of libapr. That was the reason it was not responding to my code modifications.
Regarding apr_pollset_add primitve, it is working well. The error is returned by the system when apr calls poll_ctl, because I was adding a regular file descriptor which is not accepted.