We are moving our code from CVS to ClearCase in order to consolidate our history in only one vcs system following the guidelines provided here http://www.ibm.com/developerworks/forums/message.jspa?messageID=13728313.
At first glance everything looked fine. All versions of all files appear to have been migrated, all branches and tags from CVS exist in ClearCase.
However not all files have branches created correctly (in my opinion). The example file.bat
has the following history (hope the ascii drawing is understandable).
1.1
1.2 --- SOME_TAG
1.3 --- SOME_OTHER_TAG
|---- BRANCH_1
1.4 --- BRANCH_2
|- 1.4.2.1
|- 1.4.2.2
Now, both SOME_TAG and SOME_OTHER_TAG is created and applied correctly in ClearCase. BRANCH_2 is created from CVS version 1.4 with version 0 on the branch having the same creation date/time as the CVS version 1.4. Which is good. Version 1.4.2.1 and 1.4.2.2 is created as version 1 and 2 respectively on BRANCH_2.
The problem is BRANCH_1 which is not created. As a minimum I would have liked to have the branch possibly only with version 0 on it.
I can see from the output of clearexport_cvs that the issue stems from here. The BRANCH_1 tag is not included in the output from clearexport_cvs command, only SOME_OTHER_TAG.
Any good ideas as how to rectify this? I couldn't find any options or switches on the clearexport_cvs command which seemed to help me.
It is important that we keep the original timestamp from CVS in order to be able to get the correct sourcecode for old builds. We used Parabuild so the only reference to CVS we have per build is similar to this "cvs update -P -A -d -D "2012-12-20 13:31:42 GMT" -r BRANCH_1"
Kind regards
Peter
If the clearexport_cvs doesn't work completely, and since there is no way to export only one branch, It is best to try fixing the import incrementally, and do a clearfsimport on a a dedicated ClearCase branch.
That would allow you to "patch" the history import with a few selected revisions from the CVS repo, but this isn't an automated process (unless you script the update of a CVS workspace, a bit like I did for Subversion).
Related
Background
In clearcase, I have a dev version tree for a file that looks like this:
(1)
|
(2)
|
(3)
When I run a certain program, it hangs up on an error that is in version (1) of the file. It will not look at other versions because my program is tied to a certain label. Therefore, I want to make an unreserved checkout of version (1) and fix the error.
Problem
When I run the command ct co -unreserved -nmaster -nc filename, it checks out the file in version 3 not version 1.
Question
How do I checkout version (1) of the file and make changes in that version?
You can checkout a version which is not selected by the config spec of your view, using cleartool checkout
Check out an old version of the file hello.h, using an extended path name to indicate the version. (Before you check in your revised version, you must perform a merge.)
cleartoolt checkout -un -nm -c "attempt fix of old bug" -version hello.h##\main\1
With -nmaster, checks out the branch even if the current replica does not master the branch. Do not use this option if you cannot merge versions of the element.
It would work for files (not directories) in dynamic or snapshot view.
I'm using FossilSCM as my only solution for control version and tickets. So far, so good. Its self contained and minimalist approach suit my needs. But I would like to start to make some analysis on the projects history and development and a good soruce for that are the projects timelines. I could go with some html parsing trying to convert the Fossil timeline output to something else, but I would like if there is any option to export that info in other structured format (e.g JSON or similar). Web search has not produce any useful finding on that issue. Any pointers to a solution?
Thanks,
Offray
Have you tried fossil json timeline branch trunk?
fossil help json
Usage: fossil json SUBCOMMAND ?OPTIONS?
In CLI mode, the -R REPO common option is supported. Due to limitations
in the argument dispatching code, any -FLAGS must come after the final
sub- (or subsub-) command.
The commands include:
anonymousPassword
artifact
branch
cap
config
diff
dir
g
login
logout
query
rebuild
report
resultCodes
stat
tag
timeline
user
version (alias: HAI)
whoami
wiki
Run 'fossil json' without any subcommand to see the full list (but be
aware that some listed might not yet be fully implemented).
Compile json when you build from source:
./configure --json
The key for having this working is to enable json support in fossil by compiling it from sources. Current version have it disabled, so looking for any clue on it in command line help got me nothing originally. Thanks to user 2612611 for the initial clue about it. Here is the procedure I followed:
Go to https://www.fossil-scm.org/download.html and download the source tarball package.
Uncompress the previous package.
Go to the folder where you uncompressed the package (lets call it /uncompress-folder
Run ./configure --json
Run make.
Optional: Put your newly created fossil binary in your path or where the last one was installed (something like sudo mv /uncompress-folder/fossil /usr/bin/fossil.
Open the fossil repository that you want to export its history and launch the fossil web interface (fossil ui).
Go to http://localhost:8080/json/timeline/checkin?limit=0 ,where http://localhost:8080 is your local machine interface for fossil ui, and json/timeline/checkin?limit=0 is the json API call saying: json export of timeline (/json/timeline) chekins (/checkin) for all history (?limit=0). If instead of the 0 at the end of the url you put another integer you will have the last n checkins.
From command prompt you should be able to get the same result by running fossil json timeline checkin --limit=0 > timeline.json stored on the file timeline.json, instead of the web browser but in local test it didn't work.
API is still a moving target, but you can find documentation on this excellent project at [1] and a demo interface to test the parameters at [2]
[1] https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view?pli=1#
[2] http://fossil.wanderinghorse.net/repos/fossil-sgb/json/
One says an hijacked file is a file where the "Read Only" flag has been removed.
I tried to remove the "Read Only" flag (Windows) and ClearCase does not recognize it as hijacked. Then I tried to touch the file using Cygwin without actually changing any mode flags. This time ClearCase warns me, we've got hijacked!
It seems ClearCase only look at the timestamp of files not their content and not their read-only flags. This mechanism has a very bad side effects when working in parallel with git. For example, if I do this:
git checkout bar
git checkout master
It would be the same as:
touch foo
Thus, ClearCase will think foo was hijacked which is not the case. For huge projects, this would be very dramatic and unfortunately I always use git to quickly switch to back and forth in my snapshot view.
What would be a good solution in my case?
EDIT
A much more dangerous example would this one:
stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
echo "ClearCase will not see this" >> foo
source restore_timestamp
rm restore_timestamp
When I work in parallel between ClearCase and Git, I don't touch to the git repo within ClearCase: I clone it elsewhere and work from there.
Actually, I don't create a git repo in the ClearCase view directly: I create it outside, adding in it all the file from the ClearCase view (using just for the initial add: git add --work-tree=/path/to/CC/view)
When it is time to synchronize the ClearCase snapshot view with the git working tree, a do a clearfsimport (as in this answer) from that working tree to the ClearCase view: obnly the modified files are checked out/updated and checked in.
That way, I completely bypass the "hijacked/not hijacked" issue.
I am trying to upgrade the commons-lang-2.0.jar to commons-lang-2.4.jar. When trying to add the 2.4 jar to the source control Clear Case is throwing the following error:
An element with this name (commons-lang-2.4.jar) has ALREADY been created in ClearCase for
this directory [lib], may be in a different version history of this directory that the one
you are seeing.
Review the version history of this directory [lib] to find it.
I feel this is because commons-lang-2.0 jar is existing in the lib folder and before adding 2.4 i need to remove 2.0. Can someone tell me if I am right? If so How can i remove 2.0 jar and replace it with 2.4?
That looks like a warning about "evil twins", in which your file commons-lang-2.4.jar was added, then removed from lib (and you would add it again, creating a new element with the same name, but a completely separate history: evil twin)
See also "Evil twin problem and subtractive merge".
See "About Evil twin" to try and find which version of lib already contains your file commons-lang-2.4.jar.
Once you have found the right version of lib, you can merge it to your current version of lib, restoring the deleted commons-lang-2.4.jar.
I have a repository for one of my projects that has a nested repository using the svn:externals property to update files from an external library. The problem is that I need to comment out one of the function declarations from one of the headers in this library, and carry around the modified header with the root repository.
Is there a way that this could be done, so that when the library is updated, it overrides that specific file with my version of it?
What you want sounds like a "vendor branch" scenario to me.
current repository
root
|-- myproject
|
-- mycode
|
-- library -> svn:externals to a remote svn or your own libraryproject
suggested repository
root
|-- myproject
|
-- mycode
|
-- library -> copied/branched from ^/vendor/library/current (modified at this location as much as you like)
|
-- vendor
|
--library
|
--current
|
--imported-version-1.0
|
--imported-version-1.1
How to create the layout
Create ^/vendor/library/current and DOWNLOAD the original unmodified library code into it.
svn commit ^/vendor/library/current
svn cp ^/vendor/library/current ^/vendor/library/imported-version-1.0 (tag the import)
svn cp ^/vendor/library/current ^/myproject/library (branch the code into your project)
modify ^/myproject/library and commit
How to update the library without losing your modifications
Download the latest original release of the library into ^/vendor/library/current OVERWRITING files.
svn commit ^/vendor/library/current (checks in the difference between the two library releases)
svn cp ^/vendor/library/current ^/vendor/library/imported-version-1.1 (tag the change)
cd /your-local-workspace/myproject/library (will be merge target)
svn merge ^/vendor/library/current (get all CHANGES from the upstream branch and apply them to your modified library)
svn commit
profit
Instead of branching "current" directly into your project you could branch to a "my-modified-libs" directory and make use of it via externals. This would be advised if you have multiple projects that need the same modified version of a library.
Keep in mind that vendor branches will have problems dealing with renames and deletes as those can not be tracked by overwriting. Cross-repository merging is a different and rather young topic for SVN.
If you try it out, give us feedback how it went :)
Christoph
There isn't a built in feature to help you with this.
The general practice way of dealing with this would be: Make a branch of the library you're using then make the changes you need there and use the newly created branch as the external for the root project. In my experience I've found this to be a simple and effective solution to the problem you describe.