I have folder in ClearCase which has two Revision : Rev.1 & Rev.2.
I want to checkout the Folder of revision 1 using C#. I am using ClearCasedll to checkout the file.
But its always checked out only the latest Revision Folder (meaning Rev.2).
You have to specify the full extended pathname of the revision you wish to checkout.
See also "In ClearCase, how can I view old version of a file in a static view, from the command line?" for a practical example of selection of a previous version using extended pathname.
In your case, it might not be just about a file, but a folder content, so I would advise first to setup a (dynamic: it is quicker) view with the right config spec, selecting the right version, with a -mkbranch rule in order to prepare the checkout in its own branch (and then try your C# checkout).
But with UCM, you don't need to specify yourself the config spec if you have a Stream configured properly (ie configure to select the right version you want to checkout).
A checkout is done within the context of a view, and an UCM view is one attached to a stream: That means you will almways get the LATEST of the versions made on the branch named after that stream.
However, should you create a substream, based on the previous baseline (Rev.1), then you could checkout the right version in a new view attached to that substream.
Related
I changed a lot of files in one of my ASP.NET Solutions and checked-in. Afterwards I realized I wanted to role back to my original files. I am aware I could have just went to Source Control explorer and rolled back the changeset but I went about it wrong. Since I took a backup of my entire project directory prior to doing this I figured it would be easy to simply just replace the directory with my backed up files.
After replacing the entire directory with the backup and When I open the solution I get the following message:
One or more source control bindings for this solution are not valid
and are listed below. Source control bindings can be modified by
selecting File, Source Control, Advanced, Change Source Control from
the main menu.
Then all of the .csproj files are listed below.
I followed the instructions that I saw on many websites saying unbind then rebind and it is not doing anything for me.
My first question is why did this happen if it is the same exact set of files that have all of the source control bindings.
My second question is how can I go about getting this backed up solution in source control again?
I expect it to be in source control showing me the pending changes so that when I check-in the latest version in source control will be my replacement version.
Unlike windows file system, you shouldn't simply copy and past the backup files. It will definitely cause source control binding conflicts as you encountered.
You should use rollback entire changeset feature. This will influence your source control in TFS. If you roll back a file to an earlier version, tfs will eliminating the effect of all changesets that occurred after that version. More details please take a look at this tutorial: Roll back changesets
Since you just need to go back the old version files, you could now roll back your changesets to the one you back up the entire project. Check in the roll back operation.
Another way is as below if unbind/re-bind the project is not work:
Unbind project in Change Source Control
Unload project in Solution Explorer
Reload project in Solution Explorer
Note: If you use above option, the TFS consider all project files as newly added files to the solution.
I'm mostly working on my own with Blender. I create a blend file and use it to render and save an image. Then I fiddle some more, render another image hopefully save the Blender file and then repeat. I try to keep the same version and file names for images and blend files but I often get out of sync. What I need to be able to do is browse all the image versions and reliably find the blend file that produced it.
This seems like I could use a version control system such as git, making a commit after each render.
Is there an image browser that can view images in different commits or a git viewer that can show images?
Or is there a better way to do this?
While git keeps the information of all versions around, it doesn't keep all versions in the working tree simultantously.
And its interface is meant to show differences between revisions.
The problem is that unlike text files, there is no good and common definition about what a "diff" between two images should mean. You could try and devise a textconv option for jpg files. But I wonder if that would be useful.
If you want to be able to see different version side-by-side, you should probably use some kind of numbering scheme and a script to help you with that.
Suppose you have a blender file named foo.blend that you are working on. This is your working copy. You should write a script that does two things;
Copy foo.blend to e.g. foo-027.blend, if the last existing version in the same directory is foo-026.blend, unless there is no difference between foo.blend and foo-026.blend.
Render foo-027.blend to e.g. foo-027.jpg using blender in batch rendering mode.
Call this script whenever you want to save a certain version. You also might want to make previous revisions read-only.
Python would be a good candidate to write this script in, since blender supports Python scripting. You might even be able to call it from a menu or shortcut.
With enough storage space Git is okay with binary files. But Git doesn't store files in their native form; instead they are packed in "blobs" of unreadable format. So you will have to checkout older versions to have them in your disposal.
You can have a separate directory to "retrieve" files from older revisions. Say, you've got a repo in your workspace directory.
cd path/to/my/workspace/directory
git --work-tree=/path/to/another/directory checkout <revision> <filenames separated by spaces>
Or from the another/directory:
cd path/to/another/directory
git --git-dir=/path/to/my/workspace/directory checkout <revision>
Now your workspace directory stays untouched, while another/directory has the older version. You can now compare and do whatever you want.
Of course, you can just checkout to older revision in the same directory:
git checkout <revision>
# and come back then:
git checkout master
This answer is inspired with:
git pull while not in a git directory
How do I reconnect my project to my existing GitHub repository
I'm running into an issue where branch merging fails because Crashlytics binaries are changing. I added Crashlytics to the gitignore, but now the framework doesn't show up if I checkout branches anymore.
Is there a way to deal with the merge conflicts or a way to tell git to ignore changes to the file, but keep the file itself?
If you want the file in a fresh clone, or after cleaning a git repository it needs to be tracked by git.
Binary files are not pretty to merge. From you question it sounds like there isn't anything to merge, but the decision is just which file to keep.
One thing you could do is define custom automatic merge behavior for these binaries via .gitattributes and .git/config settings:
Add the following to your .gitattributes (or create a new file with that content in the root of your git repository)
path/to/file merge=nomerge
and place the following into a git configuration file (.git/config, or ~/.gitconfig)
[merge "nomerge"]
name = keep current version
driver = true
This instructs git just ignore the conflict and keep the file from the branch into which you are merging.
The driver = true specifies an external program to use for merging. In this case the program is true which should be available on any unix like system and does nothing successfully.
See the gitattributes manpage section on Defining a custom merge driver on ways to add real custom logic if you need something smarter.
On could do really complex things like always keeping the higher version of the file, if there is any version indicator in file for example.
You should git add the .gitattributes file to the repository. The actual merge driver definition can't be stored in a way that new clones get it automatically out ouf the box. So you need to add this manually into each clone or in the per user config on every computer where you need it.
In TFS I'm performing the following action.
UnShelve Pending Changes--> right click a file in a ShelveSet --> select Compare --> There are three choices:
With Unmodified Version
With Work-space version
With Latest version
What is the difference between 1 and 2 ?
Basically, the options are broken down as follows :
With Unmodified Version - The Shelve File will compare the files with any pending changes to the corresponding files prior to the shelve being created.
With Work-Space Version - Typically this will compare your current code running on your machine to the code at the time that you checked out the file. Basically allowing you to see what changes you have made in the current checkout.
With Latest Version - Compares your code to the most recent code that has been checked into TFS.
So the difference between the first and second options would be that with the Unmodified choice, you would be comparing with any changes that occurred prior to the shelve being created and your work-space choice would display the changes that you had made in the current checkout.
I am working on new project visual studio 2008 and ClearCase 7.01 (base ClearCase) as source control.
I am very new to .Net environment, my questions:
For deployment, how to get the source from clear case?
My idea is to create a branch , apply a label to this and use Nant or Cruise Control for compilation.
For a small work in one source, (change request) do I need to branch all sources and work on that branch?
If branching is not required how do I get all the source for deployment
How to apply labels to all sources?
Is there any way to validate that the label is attached to all objects
Thanks in advance
How many developers working on the same codebase?
I have one main branch.
When code is pushed to a server, I label all the current code in ClearCase, and lock the label.
If I need to fix a problem on a server, but have made significant changes since that label that can't be pushed to the server, I branch from that label, fix the change, push to the server, label what was pushed, and then merge that back to my main branch.
So, development gets one main branch, and emergency bugfixes may get a second (temporary) branch.
The label is enough when pushing to the server. Locking the label, as recommended by Dean J, is a good idea since, contrary to the UCM baselines, a label could be moved from one version to another.
a branch is for isolating a development effort not compatible with the current one. If your change request is within the main development flow, you do not need a branch.
But if it is for a given label, branching from that label allows you to made any fix necessary while still developing on the main branch.
Now, as explained in "What are the basic ClearCase concepts every developer should know?", ClearCase use a cheap branching mechanism. You only specify you will make a branch in case of a modification. But the fact to create a branch does not apply to any source right away.
Your config spec will look something like:
element * CHECKEDOUT
element * .../MY_BRANCH_FOR_FIX/LATEST
element * MY_LABEL -mkbranch MY_BRANCH_FOR_FIX
element /main/0 -mkbranch MY_BRANCH_FOR_FIX
element /main/LATEST
3/
a label is first declared (ct mklbtype), then applied (ct ùklabel).
But you cannot guarantee it will be applied on all files of a given structure (only UCM baselines on a UCM component can have that)
the directory version selected by the view's config spec is used for the recursion.
If your config spec does not select the right version, or no version at all for a specific element, it will not get a label.
Checked-out versions are not eligible for a label either.
So you need to have a dynamic view you only use for that (no fear of missed checked-out versions, since you only use it to mklabel), with a valid config spec.