element * CHECKEDOUT
element /test_ari/karthik/... ... /karthik_omna/LATEST
element /test_ari/karthik/... /main/2 -mkbranch karthik_omna
element * /main/LATEST
I have written the above code and it worked so right.I am so happy for that.But i want to clear somethings from u guys. What does that 3 dots mean in this syntax
/test_ari/karthik/...
and the other 3 dots means
... /karthik_omna/LATEST
And last question but it got great importance. Why should we always use * CHECKEDOUT in the beginning? what happens if we dont use it?
/test_ari/karthik/...
It means that the selection rule which follows (i.e .../karthik_omna/LATEST) will apply to the karthik directory, and to all the subdirectories and files, recursively.
If the selection path had been /test_ari/karthik/* (star instead of three dots), the selection rule would have applied to the subdirectories and files, but not to the karthik directory itself
.../karthik_omna/LATEST
This is a selection rule instructing ClearCase to select the LATEST version of the branch karthik_omna, without worrying on top of what other branch karthik_omna has been created.
If the selection rule had been (for example) /main/karthik_omna/LATEST, it would have selected the LATEST version of that branch only if said branch was created on top of 'main'.
Contrary to the previous '...', there is no '*' for a selection rule.
(*/karthik_omna/LATEST doesn't exist)
As I explained in "How to create a branch", selection rules are read in order and the first one that fits make ClearCase apply it (and ignore the others) for a particular file or directory.
This is why you will always find:
element * CHECKEDOUT
as the first rule, because when you notify ClearCase of your intention to modify that file, it (the file) acquires a special version called CHECKEDOUT which needs to be selected in order for you to be able to modify and then check-in that file.
If that rule was too far down below, ClearCase might select another version, and you wouldn't be able to check-in anything since that file would not be considered checked-out in your view.
Related
I have a question about the Meld visual diff and merge tool, which is probably a simple misunderstanding.
But how do I adopt lines that were removed in the $REMOTE?
Please see the screenshot below for an example. I have changed the order of the imports and created a merge conflict, so now I want to pull the first change from the right, but then also the second change that would remove those lines that now already exist at top of the imports. I could remove them manually of course, but surely there is an easier way?
Or am I wrong with my assumption, that the middle pane is the result that gets written to $MERGED?
Edit: In this contrived example, I actually have a Delete action that I can use to remove those lines. But in a real-world merge I'm trying to do with meld the Delete action is greyed out, as is the Pull from Right action.
Any idea why Meld wouldn't allow me to Delete those lines that will be made obsolete by a Pull from Right above them?
I found out that holding the Shift key allows me to remove individual changes.
I am using Eclipse.
It happens a lot when we develop code like this (assume it is developed sequentially, from top to bottom):
Part 1 (*)
Part 2
Part 3
Part 4 (*)
Part 5
But we just figured out that parts 1 and 4 (marked with (*)) are wrong and the others are just fine. The question is that how we can undo just those two parts (1 and 4) without undoing the rest?
If we could undo selectively, it was great. Note that simply reverting the code to the version 1 loses parts 2, 3 and 5 which are correct parts and should remain in the code. Also note that usually these parts are mixed in one or two code blocks (not in separate blocks).
Example:
Part 1: Add method f1(x, y) and move some code from main() to f1() --> incorrect (should be reverted)
Part 2: Add method f2(a, b, c, d) --> correct (should remain)
Part 3: Change another part of main() implementation --> correct (should remain)
Part 4: Change f2 signature to f2(s, n) --> incorrect (should be reverted)
Part 5: Change body of f2 --> correct (should remain)
The current approach I use is:
Keeping a copy of the latest version somewhere (e.g., in a temporary
text file), then undo to before part 1, and add those correct parts
from the temporary text file to the source code.
Manual comparison of different versions, and resolving conflicts.
Does anybody think of easier, yet more automatic way of selecting which change to undo and which one to keep?
Eclipse keeps a history of your changes for a few days (configured in the Preferences in 'General > Workspace > Local History'). You can right click on a file and select 'Compare With > Local History' to see the differences between two version of your file. You can copy changes from the old version to the current version.
For the longer term you should use a version control system such as SVN or GIT. There are Eclipse plugins for these which let you do similar 'Compare With' operations - but covering the entire history of the file (provided you commit your changes regularily).
I just found this paper:
Supporting Selective Undo in a Code Editor which will be presented in ICSE 2015 conference.
The authors show the history of changes graphically, so you can choose which changes to undo (and which one to keep).
Azurite (can be download and installed from here) is the name of their implemented Eclipse plugin that supports selective undo and lots of other simple features that are useful for developers.
I know I can have anchors to a certain line, but if the source changes that line might become irrelevant. Example:
...source.php#L33 < line 33 may become line 40 later :(
Is there some way to tell GitHub to link to a certain function or property from the source, without specifying the line?
(The source is written in PHP code.)
AFAIK, no, but you can link to a certain revision of the file, and thus, you can know for sure that line will always point at the start of the function.
The URL looks like /{user}/{repo}/blob/{hash}/{file}#L{line}
To get it, click "Commits", select the last commit, click "Browse code", and find your file and line as usual.
documentation
Yes you can. Newer browsers support highlighting a portion of text and scrolling to it.
Example: common.c#:~:text=static%20ssize_t%20led_current_store
All you have to do is to add this to the end of your URL:
#:~:text=function_name
Some browsers do not support this, though: https://caniuse.com/url-scroll-to-text-fragment
Enjoy!
In a branch of code I have changed all of the code from obj.varname to obj("varname") and when I compare the code I would like to ignore these differences since varname is the same.
I have a regular expression that I think I need but unfortunately can't get the comparison to be ignored using Beyond Compare from Scooter
^obj\("\w*"\)|obj\.\w*$
I am following this tutorial http://www.scootersoftware.com/support.php?zz=kb_unimportantv3
So my question: is this even possible with beyond compare? If yes, please share a solution including either instructions or post your screenshots.
Beyond Compare 3's Professional edition supports this through its Text Replacements feature. If you've already purchased a Standard edition license you need to revert to trial mode to test it: http://www.scootersoftware.com/suppo...?zz=kb_evalpro
Load your two files in the Text Compare.
Open the Session Settings dialog from the the Session menu, and on the Replacements tab click New to create a new replacement.
In the Text to find edit, use (\w+)\.(\w+)
In the Replace with edit, use $1("$2")
Check the Regular expression checkbox.
The alternative would be to mark any instance of obj.varname and obj("varname") as unimportant. The basic steps would be this:
Load your two files in the Text Compare.
Open the Session Settings dialog from the Session menu, and on the Importance tab click the Edit Grammar... button.
In the next dialog click the New... button below the top listbox.
Change the Element name field to something useful (say, "PropertyAccess").
Change the Category* to List.
In the Text in list* edit, add these two lines:
obj.varname
obj("varname")
Click OK to close the Grammar Item dialog and then click OK again to close the Text Format* grammar item.
Uncheck "PropertyAccess" (or whatever you named it) in the Grammar elements listbox in the Session Settings dialog, then click OK to close it.
This approach isn't as flexible or clean. In the steps above you're matching specific, hardcoded object and variable names, so obj.varname is unimportant but obj.othervar isn't, even if it's aligned against obj("othervar"). If text on both sides is unimportant the difference will be unimportant; if one side is important it will be an important difference. So, with the above steps, obj.varname and obj("varname") will be unimportant everywhere, but it will work correctly since they'll either be matched to other cases that also match those definitions (and thus unimportant) or will be matched to something else that doesn't match that definition, which will be important and will make the difference important.
You can use regular expressions to match more general text categories, but you probably don't want to. For example, if you wanted to match all text that followed that pattern you could use these two lines instead:
\w+\.\w+
\w+\("\w+"\)
And then check the Regular expressions checkbox in the Grammar Item dialog so they're matched that way.
The upside/downside to that is that any text that matches those patterns is then unimportant. abc.newvar vs. def.varname would be considered an unimportant difference because both sides match the unimportant definition. That's good for things like comments or whitespace changes, but probably isn't what you want to do here.
When comparing two files, for example during a commit, Eclipse shows the original version on the right and modified on the left:
However, I would prefer to see the original version on the left and modified on the right. Is it possible?
Eclipse Neon.2 (4.6.2) has a button to swap the views:
You can either swap the views for every compare, as one answer suggests:
Or you can make the swapped order be the default for all compares:
Windows --> Preferences --> General --> Compare/Patch
Select the Text Compare tab, and mark the check-box of Swap left and right
I think it's just depending of which file you're selecting first. I mean, choose a file, and select compare to .. and choose another one. Next choose the second one and compare to the first one, they'll swap in your window :)
This behaviour is influenced by what exactly is compared. When comparing two local files the view is influenced by the first & second selection. If using e.g. GIT the left hand side will always be what is present locally, the currently checked-out branch or local changes - so changing the branch will influence the view. When using SVN it is mostly the same, so left hand locally, right hand remotly.