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.
Related
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.
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 am attempting to manage a repository's index vs. its HEAD tree using libgit2 (via Objective-Git, but I'm increasingly finding myself heading down the vanilla libgit2 rabbit hole), and am wondering what exactly the flags_extended field's bitmasks on git_index_entry struct actually mean. Additionally, when are these flags set? I've been digging through the libgit2 source, but cannot seem to find where flags_extended comes into play.
The reason I ask:
I have a simple test repository with one commit containing some simple test files. The working copy has one tracked file with a minor change and one untracked file, both of which have been staged externally (git add . on the commandline). In my application, I need to "unstage" the files, so I fetch their respective git_index_entry structs. I was expecting the flags_extended to have GIT_IDXENTRY_UPDATED set for the modified file and GIT_IDXENTRY_ADDED set for the previously untracked file, but in fact both flags_extended fields are empty, which is what prompted this question (the only thing set is the GIT_IDX_ENTRY_NAMEMASK in the flags field).
I can certainly fetch the HEAD tree and compare the entries with the entries in the index, but I was hoping that libgit2 was already providing that info via the flags_extended.
I was expecting the flags_extended to have GIT_IDXENTRY_UPDATED set for the modified file and GIT_IDXENTRY_ADDED set for the previously untracked file.
No, these flags are fundamentally internal to libgit2. They are used to maintain the information about index entries in-memory after loading the index from disk. They are to prevent and/or detect internal data races, they are not for determining the status of your repository.
If you want to compare the HEAD to the index, load the HEAD tree and then use git_diff_tree_to_index.
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
This is to avoid having some <<< or some >>> in that file if there are conflicts.
If there is a conflict, I just want a message telling me there is a conflict and bazaar should not mess with the file.
With subversion, you can modify the svn:mime-type property. But I don't know if Bazaar have this feature.
The reference says that there is no explicit way of telling so far:
Bazaar currently relies of [sic] content analysis to detect binary files for commands like diff. In the future, a binary = true rule may be added but it is not supported yet.
It is annoying, but you still have the .BASE, .OTHER and .THIS files which are unchanged, you just replace the altered file with the one you need.
Can be scripted, I suppose.