Background
I have a clearcase file that has changes on 3 different branches. I am refactoring this file so that, within the same directory, it only exists on one branch. The files on the other branches I will move to their own special directories.
Question
How do I remove the versions of a file on different branches?
A simple cleartool rmname, done in a view set to the relevant branch, should be enough.
See a detailed description of that command in "About cleartool rmname and checkouts"
This is far safer than a cleartool rmelem, which would completely deletes one or more elements.
Related
I'm using add_custom_command() to generate some files. ninja clean removes them, as it should. One of the files is intended as a default/example implementation, to be modified by the user. It is only generated if it does not already exist. I would like for ninja clean not to remove this file.
I have tried a number of things but without success:
add_custom_target(): CMake complains about the missing file unless I name it in BYPRODUCTS, but doing this also leads to removal on clean
set_file_properties(... GENERATED FALSE) doesn't work because CMake complains about the file missing.
set_directory_properties() failed in a similar way: "folder doesn't exist or not yet processed" (it does exist)
I previously generated the example implementation and just let the user copy it or model their code on it. This works, but isn't entirely satisfactory. Is my use-case so unlikely that CMake doesn't support it?
I am afraid you requirment (conceptually, have make create something which make clean does not remove) is rather unusual. I can think of two potential solutions/workarounds.
One, move the file's generation to CMake time. That is, create it using execute_process() instead of add_custom_command(). This may or may not be possible, based on whether the file-generation process (the current custom command) depends on the rest of the build or not.
Two, totally hide the example file's existence from CMake. That is, have the custom command also generate some other file (maybe just a timestamp file) and have its driving custom target depend on that one instead. Do not list the example file as ither the custom command's dependency, output, or byproduct. That way, nothing will depend on it and neither CMake nor Ninja should not care whether it exists or not, so they will not complain or try to clean it up.
If it is an example for the user, it should not be in your build folder, but in the install folder. I don't see why you would need add_custom_command or the other commands you listed.
Therefore, you have to provide install() instructions.
You can then call make install. Cleaning will not remove those and only installing again will overwrite them if necessary.
For those, who come here a long time after the original question was asked (like me), I'll write my solution:
The tool called in add_custom_command generates two files with identical content:
one that is saved in sources, never mentioned anywhere
and one that's marked as byproduct, and then is depended on
So the first one is the file we wanted in the first place.
And the second one is actually used in build process, and gets deleted on clean.
For me the issue is that I actually want to save generated files in VCS so I can track changes. And this approach gives ne what I need.
I have been struggling to make bazaar subtrees work (documentation is sparse as opposite to git submodules).
My repo sample layout is
root (d)
.bzr (d)
MyFolder (d)
MyData2.txt
SubRepo (d)
MyData3.txt
MyData.txt
I have tried the following commands in the bazaar repo (to make a subtree out of a top level folder "SubRepo"):
bzr split SubRepo
bzr join --reference SubRepo
bzr commit SubRepo
Now, I am not sure how to proceed (ie. to list the subtrees in main subtree, commit/push the subtree to a remote repo, etc.)
My understanding is that when finished the subfolder must live in its own repo and it must be possible to populate the "SubRepo" folder from the main repo by pulling from the remote subfolder repo.
I am following instructions from http://wiki.bazaar.canonical.com/NestedTreesDesign#id20
Anyway, If not else, I will post here my findings.
Bazaar nested tree support is unfinished. The URL you're linking (http://wiki.bazaar.canonical.com/NestedTreesDesign#id20) is a design document; it does not describe current behaviour.
bzr split and bzr join will work but are for so-called "by-value" nested trees, e.g. simply merging in the containing tree rather than merely referencing it.
bzr join --reference is partially implemented but does not fully work yet. It does not seem likely this will be available in the near future, as there is nobody actively working on nested tree support. See also this bug report on launchpad: https://bugs.launchpad.net/bzr/+bug/402814
in my previous question on how to avoid merging specific files i received an answer
see
Bazaar merge questions
the solution is running a resolve command that takes the .THIS files for specific files that i dont want to merge. (like *.hex, *.s19...)
My question is how i make resolve command to run on all the files in all directories without making batch file that contains all the directoreis names. (what will work but needs modifications every project)
P.S i know what * is stand for , what is the meaning of ** ?
thanks
If I understand correctly, it means "subtree". In other words, subdirectories and their subdirectories, and their subdirectories, etc. So, "*/.hex" would match all files with the "hex" extension in the current directory and anywhere in the subtree under that.
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.
Is there a way to tell bzr not to create .moved files? I've tried the --overwrite option with a bzr pull, but it still creates the .moved files. I guess I can just make a clean-up script, but I was just wondering if I am missing something.
You have conflicts in some filenames: either you have unversioned foo in your tree and you pull revision where foo becomes versioned, or you have added foo in two different branches independently and therefore each copy of foo got assigned different file-ids. So Bazaar tries to save your files there and avoid overwrite your existing files. In the first case you have harmless backup facility from bzr, and foo.moved can be deleted. But in the second case you have real conflict and you should at least inspect both foo and foo.moved and resolve conflict with bzr resolve foo, then delete foo.moved if needed.
So the strategy to avoid .moved files is pretty much depend on the reason why they are appear in your tree.