We have a ton of branches in our VOB.
Some files change very frequently, and so the version tree is a mess.
Most of the time, I only care about one particular branch and its subbranches.
I know I can collapse certain branches once the VTree is open, but that gets very tedious.
Is there any way to open the VTree with most branches collapsed (hidden) except for the ones I care about?
Even in its latest iteration (ClearCase 9.0), cleartool lsvtree -graph don't offer much in term of filtering.
You do have the -bra/nch branch-pname option though:
Starts the version tree listing at the specified branch.
You can also use an extended name as the pname argument (for example, foo.c##\main\bug405) to start the listing at a particular branch
Combined with the -g/raphical (which starts a Version Tree Browser for each element you specify as an argument), you can launch a VTree (GUI) directly on the right branch.
Another option is to lock -obsolete any branch instances you don't use anymore. They will drop off the graphical vtrees as long as the option to display obsolete versions isn't enabled.
Related
SUMMARY:
I need the most efficient workflow to individually edit over 200 files, and have them automatically disappear from the search results as they are updated.
DETAILS:
I am in the process of adding logging throughout a legacy system, and need to update over 200 files, each with their own custom code. I need to edit them one by one, and would like for the updated files to automatically disappear from my working search results after I have completed each one. The idea is to know how many and which ones still need to be updated as I slowly work through them all.
I already had to do something similar a few months ago, but on a much smaller scale, and I used an old-school HACK to do it. I did a search and replace for my keyword, and intentionally misspelled it. I then used the misspelled keyword for my search, and corrected it when editing each file, hence automatically removing it from the list. It "works", but is obviously a TOTAL HACK.
I recently started using IntelliJ IDEA, and am not yet familiar with the more advanced features like Find in File Scopes, Search Structurally, Search Templates, etc., but I am sure there HAS to be a "correct" way to do this in IntelliJ, and I just don't know how.
I am currently using "Find in Files" to work through the list, and recently found "All Changed Files" in the Scope list, which is actually the EXACT OPPOSITE of what I need. Is there a way to show "All UNCHANGED Files"??? That would work PERFECTLY in a pinch! But really, I would rather learn the CORRECT way to do this in IntelliJ.
Thanks!
I have been working on a big SQL based project that is taking an increasing amount of time and effort to maintain its versions. Lets keep it simple. I have three folders for each version of the code called Ver1, Ver2, and Ver3. All three version folders have the exact same filenames within it, but their content differs from version to version. If I make a change to a particular file in Ver3 that exists in Ver2 and Ver1, how can I use Git not to necessarily make the same changes in those other versions (not always practical due to partial rewrites for performance or logic changes), but to let me know that the other two versions of the file need to be updated in order to catchup to the Ver3? If Git isn't suited for this task, or if you have any experience with a similar issue, I would much appreciate any suggestions.
I try to learn about RPackageTags:
It seems RPackageTags are just something like sub-packages?
Unlike let’s say tags in OS X, one item (here one class) cannot have more than one tag?
A tag is always specific to an RPackage? The tags in Package1-Tag1 and Package2-Tag1 are not the same, i.e. are two different instances of RPackageTag?
There is the possibilty that Package1-Tag1 is just an RPackage and also the possibility that Package1-Tag1 is the combination of RPackage Package1 and RPackageTag Tag1?
Is that right? What is the idea behind the introduction of RPackageTags?
How are RPackageTags related to Monticello packages?
Some answers:
Yes, they are like subpackages
For now, yes. This is because we needed to keep some compatibility between RPackages and System Categories and we decided (for now), that the scheme would be: RPackage+Tag = SystemCategory. This will change in the future, by removing system categories and allowing tags to be like OSX tags.
For now, yes... see point (2) :)
No, you cannot. This is because of organisation issues derived also from the attach RPackage+Tag to a SystemCategory: If you have a package A-B and a Package A with tag B, both would share the SystemCategory A-B... which is seriously bad for the organization of the system.
Of course, as you can see, the real problem here is to have an ancient way of organisation still in system. This will change, in Pharo4 or (most probably) in Pharo5, and for now we need to live with this convenience solution.
Ring package structure was adopted in Pharo 3. Approximately what was known to be an MC package became RPachage, pure-smalltalk categories disappeared and were replaced by RPackageTags. You can think about it as a way to create categorise classes inside your MC package. I don't know what Pharo board will decide in future, but for now you can have only 1 tag per class.
We have a C++Builder XE project (VCL Forms Application) that has a few dozen forms and units in it. Whenever a file belonging to the project is added, deleted, or renamed, the IDE should do two things:
A call to USEFORM macro is added to or altered in the Project Source file (ProjectName.cpp) if the affected unit is a form or frame
A CppCompile element in the project file (ProjectName.cbproj) is added or altered
However instead of just doing the necessary changes, the IDE shuffles some of the existing USEFORMs and CppCompile records, even if they aren't affected by the changes. If I add a Unit (cpp and header file), the USEFORMs are shuffled even when that wouldn't require any changes to the Project Source, only to the cbproj-file.
I don't see a specific pattern on how the new order is formed. If I edit or rename a single unit, about half of the USEFORMs seem to change position and just a couple or none of the CppCompile records. If a change is made to a copy of the project in two different machines, most of the changes seem to be similar, but not all. This indicates that the reordering is not random.
The behaviour causes problems when using Subversion to merge changes, because it forces to manually resolve conflicts inflicted by the changing order.
So the question is: What might be causing the foregoing behaviour and how to get rid of it?
I haven't been able to find a proper solution to the problem, but here's a simple method for making it slightly less annoying:
Adopt a policy of never committing the random IDE-generated changes to the version control repository. Whenever you make changes to code that trigger mixing up the files, revert all unnecessary changes in ProjectName.cpp and ProjectName.cbproj. At this point it is still fairly easy, as you know which parts of the files actually should have changed. That way, the manual labour is carried out when it still requires the minimal amount of work. Additionally, the work has to be carried out only once, in contrast to leaving the changes untouched, in which case the work has to be repeated every time someone merges the changes.
I installed Darcs a few days ago and have a doubt.
I am the only programmer and I usually work on two or three instances of the application, making new feautures. The problems cames because this instances modify the same source code file, so when I finished them and send to main repository they make a conflict.
Is there any way to deal with this? Can I write the same file in multiple instances without making conflict when pushing to main repository?
thanks
First of all when changes occurs at different places of the file there is generally no conflicts when merging. When two patches can be merged without conflicts one says that they commute. In your case it happens that you've modified the same part of the file in two different branches. In this case darcs don't allow you to "push" the second patch that makes the conflict.
There is two ways to resolve such a confilct, but you have to start to locally merge the both patches to get the conflict in your working repo. To do this just pull the patches from the main repository. Then you have to edit the offended file and resolve the conflict.
The first way is simple and the prefered solution, you have to "amend-record" the patch that is not yet on the main repository (look at the usage of the "darcs amend-record" command).
The other solution is to record a resolution patch, by calling "darcs record" and then pushing both the conflicting patch and the resolution patch. This solution tends to complicate the history and can make some later operations longer. However when the branch has been heavily distributed this solution becomes needed.