I'm using bazaar with the following shared repository structure on network drive:
proj_name (shared repo **with working tree**)
.bzr
developer a (integrator) (FOLDER)
trunk (branch)
feature a (branch)
feature b (branch)
developer b (FOLDER)
trunk (branch)
feature a (branch)
feature b (branch)
developer c (FOLDER)
trunk (branch)
feature a (branch)
feature b (branch)
formal version (branch)
I want that formal version branch will be branch without working tree, where all the other branches will be with working tree.
Is that possible?
NOTE : I tried to create the formal version branch with bzr push N:\Projects\proj1\formal --no-tree but its still create the working tree
I found two solutions for this probelm:
In case of existing branch with tree you need to use 'bzr remove-tree PATH (Solution from Martin Pool)
In case you want to create branch without tree , the bzr branch --no-tree is what you need (Solution from jelmer)
Notes:
bzr push PATH --no-tree to a PATH that's not exist , will create branch WITH tree.
Once branch is created without tree or remove-path was executed , you can
use push with or without `--no-tree switch and the branch will stay without tree.
The --no-trees is an option of the repository itself.
If you want the formal branch to have another structure, you must have it outside the repository.
Example:
proj_name (FOLDER)
developer a (integrator) (REPO --no-trees)
trunk (branch)
feature a (branch)
feature b (branch)
developer b (REPO --no-trees)
trunk (branch)
feature a (branch)
feature b (branch)
formal version (REPO with tree!)
or you can have a repo at the developper level, and another at formal version.
THis way, you have a different op^tion for each repo.
Related
Is there a command-line tool to automate maintaining a collection of source libraries and applying them to projects?
For gamejams (or possibly also longer-term projects), I don't want to host my own clone of each library I use to be able to modify it (and grant each member of my team permission on each clone). Instead, I want all of my source code inside my project source tree -- which means I can't use git submodules.
So say I have a project "puppypark" and I want to use some libraries "baton" and "windfield".
I'm looking for this kind of workflow:
register libraries
librarian add baton git://lib.com/baton.git
clones to a central repository (e.g., in ~/.librarian/)
add libraries to a project
librarian use baton puppypark ./src/foreign/
creates a branch (off master) for that project in the central repository
merge project changes into central repository
librarian apply puppypark
switches to project's branch and copies changes into clone
merge upstream changes into project
librarian apply baton puppypark
takes the current state of project's branch and copies to project
no actions occur unless the target repository has a clean workspace
actions always result in commit summarizing the action taken
commits should always have a commit id (sha)
This could be independent of my version control system, but if it did it with git, that's great too.
I think this is kinda like Carthage (but for source instead of built libraries and I'm not interested in dependencies). Maybe I can achieve some of this with git-subtree, but I don't understand how. I think this is like loverboy, but I'm interested in a more general solution.
I couldn't find a solution, so I wrote my own: librarian automates copying modules to and from projects. Unlike loverboy, you give it general rules for how to copy modules instead of requiring rules for each module.
Example usage to setup for love2d and import windfield into project "puppypark":
librarian config love --path src/lib/ --root-marker init.lua --rename-single-file-root-marker ".*.lua" --include-pattern ".*.lua|LICENSE.*"
librarian acquire love windfield https://github.com/adnzzzzZ/windfield.git
librarian checkout puppypark windfield
librarian checkin puppypark windfield
We aim at using Tycho+Eclipse PDE to build OSGi bundles in a distributed team.
So far artifacts are built and deployed to a Nexus OSS repository. This has been
augmented with p2 support, "artifacts.xml" and "content.xml" are generated
(or supplied by Tycho) and correctly resolved by Tycho and the p2 Browser.
The missing link is to add the resultant p2 bundle repository to the target platform
definition used by PDE. The PDE target editor apparently only supports features
or "categorized" plugins, no plain bundles.
Tycho's repository plugin and feature-packaging of bundles independently developed by
different partners appears too cumbersome to synchronize. We'd like to adhere to simple
Maven/OBR-like sharing of bundles via a single repository.
Is there a way to enhance the bundle's or repository's p2 metadata in terms of a
generic category as suggested in this blog, e.g. either via the "tycho-p2-publisher:publish-categories" goal or by configuring/extending the "Nexus p2 Repository Plugin" to make them accessible to the PDE UI ?
This questions seems related to this question, with a hint that support for the "iu" syntax is not implemented yet.
Maybe you should try another target editor. There exists a alternative TPD editor/generator from Mikaël Barbero with some useful features:
autocomplition
version management
mergeable structure
...
I have project A, which includes a local fork of project B.
This is, project B's potentially modified sources are included in a subtree of project A.
Project A uses svn, project B uses git.
Using git for my local copy of project A, I want to:
Be able to merge project B's upstream changes into project A.
Be able to contribute back to project B some (not all) of the modifications to project B's fork included in project A.
Do it in such a way that clean individual commits (not squashed) are sent both to project A (via git-svn) and to project B (via git).
I've been trying hard to find a solution mixing git-svn and git-subtree capabilities (git-submodule is out of question as I want a unique source tree). But I can't find a perfect solution.
I need to create bazaar workspace for 4 developers.
Each developer will work on its local computer and will have branch from its local branch to a network location that will be updated each commit (with the help of auto-mirror plugin).
In addition , one branch on network used for formal versions that being "pushed" by the integrator
Currently i'm using shared repository for my workspace (both in local and network) and all is working well.
But i'm still dont understand two things:
What is the differences between shared repository concept to colocated branches and stacked branches. are they better fit for my workspace?
is the only difference between shared repository and feature branches is that feature branches auto create the trunk branch inside the shared repository?
A shared repository is just the core bzr feature used to implement the colocated branches and feature branches workflows. Basically, it's a directory that contains a pool of revisions, with subdirectories for each branch that have metadata pointing to a specific revision in the pool that is the tip for that branch.
The difference between colocated and feature branches is that colocated branches has all the branch metadata in the same directory as the shared repository and working tree, whereas feature branches have separate subdirectories for each branch with their own working trees.
Which one you should use depends on your development environment. If your environment makes it difficult to switch between different directories, e.g. if you have scripts that have paths to your working tree hard-coded, then you should use the colocated branches workflow. If it is better for your environment to have completely separate working directories for each branch, e.g. large amounts of compiled output that take a long time to regenerate, then the feature branches workflow would probably work better for you.
I have two maven projects A and B, both of which I'm actively working on the source code for. Project A depends on B. If I want to build project A, does a snapshot (or release) of B need to exist in the repository? Or will maven check the parent directory of A to see if a project B exists (assuming my directory structure looks something like: projects/A projects/B)? And which would be better practice? thanks.
Jeff
Maven won't look anywhere except the repository hierarchy you specify, by default this is your .m2 directory (local repository) and the Maven Central Repository.
So yes, some version of B must exist in a repository.
You can also investigate project modules, where you have (for example) projects/pom.xml and when it is built, it will also build its children A and B in the correct order given their inter-dependencies - but you shouldn't see this as a solution to the problem you're describing without giving a lot of thought.
To get a good grasp on how the Dependency Mechanism works in maven and how to configure parent-child/submodule/subproject relations read this
Maven is a strange build tool in that it will look to the maven repository / artifactory for jars. As long as someone has built ProjectB and installed it in the artifactory, or as long as you have built ProjectB (with install) it will be available to ProjectA.
This also assumes you have setup the dependancy correctly in the pom file for ProjectA.
I used Maven on one project, and I'll go back to ant for a more standard build tool. It's really an odd duck.