For a feature I have checked out the files on X branch. After some implementation, I realized that I should have branched to Y. I would like to migrate my changes to the correct branch. The only solution which I know is to back-up my changes, undo checkout and branch to Y and restore my changes.
Is there any other easy way?
Clearcase version is 7.1.1.2 for Windows XP
You can simply change the config spec of your view (in order to make sure any checkout would be done in the new branch)
First undo checkout all your files, with a -keep in order to preserve your changes.
Then update the config spec.
That will update your view (reload it if it is a snapshot view), but won't touch/erase any local modification you currently have (ie the files you had checked out in the previous branch).
You can then checkout again those files, and check them in.
After creating branch Y, you could always merge directly from X to Y. You might want to have branch Y branch off at the same point as branch X.
You would still have branch X though, you can delete it though.
Should you want to use the back-up-approach, I found WinMerge's folder-compare utility to be fastest. The MergeManager as described above should do the same trick, though.
Related
I'm trying to implement a simple checkout operation between 2 branches. The code executes without errors.
git_libgit2_init();
git_object *treeish = NULL;
git_checkout_options opts;
opts.checkout_strategy = GIT_CHECKOUT_SAFE;
/* branchName in this case is "master" */
handleError(git_revparse_single(&treeish, repo, branchName));
handleError(git_checkout_tree(repo, treeish, &opts));
git_object_free(treeish);
git_libgit2_shutdown();
However, the branch does not change when I check it using git status.
I've checked the 101 examples of libgit2 and it says:
git_checkout_options isn’t actually very optional. The defaults won’t
be useful outside of a small number of cases. The best example of this
is checkout_strategy; the default value does nothing to the work tree.
So if you want your checkout to check files out, choose an appropriate
strategy.
NONE is the equivalent of a dry run; no files will be checked out.
SAFE is similar to git checkout; unmodified files are updated, and modified files are left alone. If a file was present in the old HEAD
but is missing, it’s considered deleted, and won’t be created.
RECREATE_MISSING is similar to git checkout-index, or what happens after a clone. Unmodified files are updated, and missing files are
created, but files with modifications are left alone.
FORCE is similar to git checkout --force; all modifications are overwritten, and all missing files are created.
In my case I'm testing it with a very small repo without uncommited changes and without any conflicts between these 2 branches.
What am I doing wrong? I expected this code to do something like git checkout master
The git checkout command is exceptionally overloaded. It deals with both putting files on disk (checking out) and switching branches. In particular, git checkout <branch> will update the working directory to match the contents of the given branch and switch to it.
The libgit2 APIs do not conflate these two operations. git_checkout_* functions will only check files out on disk.
The documentation should clarify this:
In libgit2, checkout is used to update the working directory and index
to match a target tree. Unlike git checkout, it does not move the HEAD
commit for you - use git_repository_set_head or the like to do that.
So what you have written (above) will update the working directory to match the contents of the branch. After that, you will need to update your branch to the branch you want to switch to.
You can do this with git_repository_set_head to update HEAD to point to the given branch, once the files have been checked out. Be sure to specify the fully-qualified branch name (eg, refs/heads/master).
git_object *treeish = NULL;
git_checkout_options opts = GIT_CHECKOUT_OPTIONS_INIT;
opts.checkout_strategy = GIT_CHECKOUT_SAFE;
git_libgit2_init();
handleError(git_revparse_single(&treeish, repo, "master"));
handleError(git_checkout_tree(repo, treeish, &opts));
handleError(git_repository_set_head(g_repo, "refs/heads/master"));
git_object_free(treeish);
git_libgit2_shutdown();
I need to remove the code changes of an activity from the child stream, which is shared among two projects. Wanted to remove code changes from Project A but I need to secure not to lose the changes in Project B
Can someone suggest me the possible solution and the next steps to be taken care to get rid of this issue.
See "Reverse Change set of an activity in Clearcase": you can use ccperl cset.pl -undo, or do for each file in an activity a negative or subtractive merge.
In both case, the goal is to create a new activity whose change set will represent the negative image of the existing activity.
You can then do what you want/need with it, like deliver it to another stream where the first activity was already delivered.
Is it possible to access environment variables in the config spec in clearcase.
I have this code:
element /folder/... /main/current_branch/LATEST
I wish to set my development up so as that I can update the branch by simply setting some envvars. I would like somthing like this to work is it possible?
element /folder/... /main/$current_branch/LATEST
where $current_branch should return the current branch set in that environment variable.
AFAIK, that is not possible.
The way I handle that is by having templates that I fill in (automatically). But I also use separate views; views are disposable and I rebuild my views routinely (every week, every couple of weeks, sometimes a few times in a day if I need to be sure of the cleanliness of the builds).
I'd show you my scripts but there are a large number of them, and they're fairly intricately intertwined with each other and with the working environment we have (multiple but overlapping VOBs for each of a number of major versions of a number of products, with some parts of the config spec provided by CM and custom preambles to identify what I'm working working on). We've been using ClearCase for about 18 years now.
The net result is a config spec for a bug fix branch that looks like:
# #(#)$Id:243260.jleffler.toru.cs,v 1.1 2011/08/30 15:23:02 jleffler Exp $
#
# Config Spec for Bug 243260 - Blah, blah, blah, blah
element * CHECKEDOUT
element * .../TEMP.243260.jleffler/LATEST
mkbranch -override TEMP.243260.jleffler
#time 26-Jul-2009.00:00:00UTC-08:00
element /vobs/main_vob/... /main/LATEST
element /vobs/other_vob/... dist.1.00 -nocheckout
include /atria/cspecs/product/1.23/product-1.23.4
#include /atria/cspecs/product/1.16/product-1.16.8
element * /main/LATEST
The bit between the commented out time stamp and the catch-all rule is provided by CM. The bit above the time stamp is custom to the branch (TEMP.243260.jleffler — which identifies it as a temporary branch, the bug fix which it is for, and who is doing the work). The template actually lists about 10 different config specs from CM, and I just delete the ones that aren't relevant. The view name is based on the bug number, my login, and the machine where it's created (toru). I've disguised most of the rest, but it is based on a bug cspec that I created earlier today. My bug.view script took the bug number, a description, the path for the view working storage, and the VOBs where I needed the branch created and went off and set everything up automatically. (And I'm still archaic enough to use RCS to keep my cspecs under control.)
Some of my views last a long time (by name). For example, the current release reference view will survive for the 5+ years that the release will be supported. It'll be rebuilt hundreds of times over that period, but the name remains the same: prod-1.23-ref.jleffler.toru. So the cspec for that will change over time, as different work is needed, but the basic cspec is three lines — CHECKEDOUT, include standard CM provided configuration file, and LATEST.
No, I never saw a config spec based on environment variable.
I looked at config_spec man page, writing config spec and "How config spec works": none refer to that possibility.
For dynamic view, I saw script modifying the config spec dynamically, based on an environment variable, using cleartool setcs (since the refresh would be near instantaneous with a dynamic view).
Note: don't forget that your current_branch might not always derive directly from /main. I prefer using the syntax:
element /folder/... .../my_branch/LATEST
in order to select my_branch, without depending on its direct "parent" branch (even though, in base ClearCase, there is no real "parent" branch).
I am using ClearCase 7.1.2 and am working on a project. At some point long before I came along there was a branch (lets call it 'pilot') which eventually became the production code while the main tree was left behind. At this point I need to make a branch off of pilot to implement a new feature but am running into a problem.
I have made my branch and all seems to go well when committing changes to existing files but when I do a mkelem the new file ends up on main. I want it on pilot. What would the config spec look like for this or what combination of commands can I piece together to make this a reality?
Right now my config spec looks something like this (going from memory):
elements * CHECKEDOUT
elements * main/0 -mkbranch pilot
elements * main/pilot
elements * main/LATEST
I'll update once I can see what I have going on there.
You will find examples on the config_spec man page, as well as Config spec rules for elements in subbranches.
What you need to do is first put a label on pilot branch (ie, on all the element present in your view on pilot branch), in order to make new versions from a fixed point in time.
Then:
elements * CHECKEDOUT
elements * .../my_feature_branch/LATEST
elements * LABEL_ON_PILOT -mkbranch my_feature_branch
elements * main/LATEST -mkbranch my_feature_branch
Trying to make branch from the "LATEST" versions of another branch is really not recommended: you simply don't know from what you are working on on your new branch.
I think I'd be expecting to see a cspec like this:
elements * CHECKEDOUT
elements * .../my_feature_branch/LATEST
elements * .../pilot/LATEST -mkbranch my_feature_branch
elements * /main/LATEST -mkbranch my_feature_branch
The -mkbranch on the last line answers your question. Line 2 ensures you use your feature branch when it exists. The change on line 3 should work better than your line 2 (unless CC 7.1.2 has some new abbreviations which allows your old version to work; I seem to be using 7.0.x).
Treat this answer of mine with some caution - see the answer by VonC for an alternative way of doing this. Clearly, there is some issue which VonC sees with this approach. However, the team I work on has been doing precisely this for many years (since about 1994) without running into the issues which have VonC so up in arms. In addition, it takes about 12 hours to apply a full label to the set of VOBs which make up our product set (somewhere around a dozen large multi-site VOBs, at a guess). I checked the time with our CC guru, and he commented that we won't be migrating to UCM any time soon, in part because of this labelling issue.
So, best modern practice with small VOBs may use a label created specifically as a starting point for a feature branch, but not all systems use them. Empirically, the label is not necessary. I'm not sure what other 'best practices' (or 'worst practices that compensate for the lack of best practices') we have that prevent us running into problems.
I've previously documented my opinions on Clearcase as a source control system, but unfortunately I am still using it. So I turn to you guys to help me alleviate one of my frustrations.
We have just moved from a one-branch-per-developer system, to a one-branch-per-task in an attempt to improve some of the issues that we've been having with determining why certain files were changed. Generally I am happy with the solution, but there is one major issue. We are using simple scripts to start and end tasks which create a new branch named with the username and task number and then updates the local snapshot view to have a config spec similar to the following:
element * CHECKEDOUT
element * .../martin_2322/LATEST
element * /main/LATEST -mkbranch martin_2322
load /Project/Application
Let's say that my project has two coupled files A.cs and B.cs. For my first task I make changes to A on the branch. Then I need to stop working on task 2322 for whatever reason and start work on task 2345 (task 2322 is not finished, so I don't merge it back into main).
I create a new task branch 2345, edit both A.cs and B.cs and merge the results back into main. Now I go back to work on 2322, so I change my config spec back to one defined above. At this point I see the A.cs file from the task branch (as I edited it earlier, so I get the version local to that branch) and the latest version of B.cs from main. Since I don't have the changes made to A.cs on the 2345 branch the build breaks. What I need instead is to be able to pick up task 2322 from where I left off and see it with the old version of A.cs - the one that was latest in main when the branch was created.
The way I see it I have a few options to fix this:
Change the config spec so that it gets files from main at the right date. This is easy enough to do if I know the date and don't mind setting it by hand, but I can't figure out how to automate this into our task switching scripts. Is there anyway to get the creation date of a branch?
Create a label for each branch on main. Theoretically simple to do, but the labelling system in our install of CC is already collapsing under the weight of a few hundred labels, so I don't know if it will cope with one per developer per branch (notice that the task in my example is 2322 and we're only about an quarter of the way through the project)
Merge out from main into the task branch. Once again should work, but then long running branches won't just contain the files changed for that task, but all files that needed to be merged across to get unrelated things working. This makes them as complicated as the branch-per-developer approach. I want to see which files were changed to complete a specific task.
I hope I'm just missing something here and there is a way of setting my config spec so that it retrieves the expected files from main without clunky workarounds. So, how are you guys branching in Clearcase?
A few comments:
a branch per task is the right granularity for modifying a set of file within a "unit of work". Provided the "task" is not too narrow, otherwise you end up with a gazillon of branches (and their associated merges)
when you create a config spec for a branch, you apparently forget the line for new elements (the one you "add to source control")
Plus you may consider branching for a fix starting point, which would solve the "old version of A.cs - the one that was latest in main when the branch was created" bit.
I know you have too much labels already, but you could have a script to "close" a task which would (amongst other things) delete that starting label, avoiding label cluttering.
Here the config spec I would use:
element * CHECKEDOUT
element * .../martin_2322/LATEST
element * STARTING_LABEL_2322 -mkbranch martin_2322
# selection rule for new "added to source control" file
element * /main/0 -mkbranch martin_2322
load /Project/Application
I would find this much more easier than computing the date of a branch.
do not forget you can merge back your task to main, and merge some your files from your finished task branch to the your new current task branch as well, if you need to retrofit some your fixes back to that current task as well.
You can get the creation date for a branch by using the describe command in cleartool.
cleartool describe -fmt "%d" -type martin_2322
This will printout the date and time that the branch was created. You can use this to implement your first option. For more information, you could read the following cleartool man pages, but hopefully the above command is all you need.
cleartool man describe
cleartool man fmt_ccase
We use Clearcase, and we find that creating a branch for a release is often much easier than doing it by task. If you do create it by task, then I'd have a 'main branch' for that release, and branch the tasks off that branch, and then merge them back in when finished to merge them back to the trunk.