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
Related
How can I show parallel branch lines in IntelliJ git logs?
This is my old project and it shows like that.
In my newer project although I have multiple branches merged to master already, still, that beautiful view isn't there, it's just the straight line appearing.
Is this an IntelliJ bug or I don't get when those lines gets showed?
Judging by the screenshot, the history of your repository is just linear - there are no commits that have more than a single child - that is why no other branches are in the graph.
Branches in git are in fact just a reference to a commit. So several branches can be referencing the same commit without producing any branches in the graph. This seems to be the case.
Intellij has a plugin named GitHub, if you install it (from settings -> plugins)
you will have a 'git' tab at the bottom, inside that tab you will see the GUI you are referring to
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 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.
As my Maven project grows, I'm trying to stay on top of the project structure. So far, I have a nested directory layout with 2-3 levels, where there's a POM on each level with module entries corresponding to the directories at that level. POM inheritance (parent property) does not necessarily follow this, and is not relevant for the purpose of this question.
Now, while the nested structure seems pretty natural to Maven, and it's nice and clean as long as you are on one particular level, I'm starting to get confused by what I look at in my IDE (Eclipse and IntelliJ IDEA).
I had a look at the Apache Felix sources, and they have a pretty complex project in what seems to be a flat directory structure, so I'm wondering if this would be a better way to go.
What are some pros and cons for either approach that you have experienced in practice?
Note that this question (which I found meanwhile) seems to be very similar. I'll leave it to the community to decide whether this should be closed as a duplicate.
I use a kind of mixed approach. Things with distinct lifecycle (from a release and thus VCS point of view) are flat, things with the same lifecycle are nested. And I use svn:externals for the checkout. I wrote about this approach in this previous answer.
I vote for nesting. I'm using IDEA 9 which shows the nesting in the project pane, so the presentation mirrors your logical project structure. (This wasn't the case in 8.1 - it was flattened out.)
I prefer keeping things nested, especially if the names are very similar - makes navigation much easier when using a command prompt. I have a project with names like myapp-layer-component, so they all start with the same prefix, and many have the same -layer-, so using autocomplete on the commandline is next to useless. Separating these out into a nested structure is then much easier because each part of the name (appname, layer or component) is repeated just once at each level in the directory structure.
If building from the command line, it's much easier to build a subset of the project, e.g. if I'm working on the db model, then often I need to build all projects in that area. This is tricky to do when the files are flattened out - the only way I know is to use the -pl argument to maven and specify the proejcts to build. With the nested directories, I just cd to the db directory and run mvn.
For example, instead of
myapp-web-gui1
myapp-web-gui2
myapp-web-base
myapp-svc-clustered
myapp-svc-clustered-integrationtest
myapp-svc-simple
myapp-db-model
myapp-db-hibernate
We have the structure
\myapp
\web
\gui1
pom.xml
\gui2
pom.xml (other poms omitted to keep it short)
\base
\svc
\clustered
\clustered-it
\simple
\db
\model
\hibernate
You could also add nesting for the integration tests, but this seems like driving the point too far.
With nesting, you also get all the benefits of inheritance (and some of it's pains...)
The only issue I've had with this is that the directory name doesn't match the artifact id. (I'm still using full artifactIds.) And so each project must explicitly define SCM paths, since these can no longer be inferred from the parent pom. Of course, each directory can be made the same as the artifactId, and then the SCM details can be inferred from the parent, but I found the long directory names a bit unwieldy.
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.